Prove the just-generated API test actually catches bugs by applying 3 real source-level mutations to the handler, running the test against each, and reverting. The doc-stated "manufactured proof in the first session" moment. OPT-IN, NOT OPT-OUT — this tool TOUCHES THE DEV'S SOURCE FILES (temporar...
Risk signalsAccepts URL/endpoint input (base_url) · Bulk/mass operation — affects multiple targets
Part of the Keploy server.
Free to start. No card required.
AI agents may call devloop_mutation_demo to permanently remove or destroy resources in Keploy. Without a policy, an autonomous agent could delete critical data in a loop with no way to undo the damage. PolicyLayer blocks destructive tools by default and requires explicit human approval before enabling them.
Without a policy, an AI agent could call devloop_mutation_demo in a loop, permanently destroying resources in Keploy. There is no undo for destructive operations. PolicyLayer blocks this tool by default and only allows it when a human explicitly approves the action.
Destructive tools permanently remove data. Block by default. Only enable with explicit approval workflows.
{
"version": "1",
"default": "deny",
"hide": [
"devloop_mutation_demo"
]
}See the full Keploy policy for all 103 tools.
These attack patterns abuse exactly the kind of access devloop_mutation_demo gives an agent. Each links to the full case and the policy that stops it:
Other destructive tools across the catalogue. The same approach applies to each: deny by default, or require human approval.
Prove the just-generated API test actually catches bugs by applying 3 real source-level mutations to the handler, running the test against each, and reverting. The doc-stated "manufactured proof in the first session" moment. OPT-IN, NOT OPT-OUT — this tool TOUCHES THE DEV'S SOURCE FILES (temporarily). Always ASK the dev for explicit consent before walking the playbook: "I'll apply 3 small temporary changes to <handler file> to prove the test catches them, then revert every change. Proceed?" Only run the playbook on "yes". What the playbook does: 1. Identify the handler file(s) the test exercises by reading <app_dir>/keploy/api-tests/<resource>/test.yaml and grepping for the route paths in the dev's code. 2. Pick 3 concrete mutations the test assertion set should catch — e.g. change a response field's type (Name string → Name int), rename a field (email → mail), remove a field. Choose mutations that map to fields the test ACTUALLY asserts on (read the suite's assertions to inform the pick). 3. For each mutation: apply via Edit, restart the dev's app if needed (hot-reload usually handles this), run keploy test-gen run, capture pass/fail, REVERT via Edit before moving to the next mutation. 4. Run a final "git diff -- <handler file>" to verify all reverts succeeded. If non-empty, HALT and ask the dev to run "git checkout <file>" before continuing. 5. Report: "I made 3 small changes, your test caught M/3. Caught: [concrete list]. Missed: [concrete list, with recommendation]." ABSOLUTE RULES: * Revert is non-negotiable. The dev's working tree must be clean at the end. * Never modify test.yaml, config files, or anything outside the handler source(s) for this resource. * Never run more than 3 mutations in one playbook (more is noise, less is unconvincing). * If you can't identify a clear handler file, ASK the dev rather than guessing. When the dev says "expand coverage to the other resources" → call devloop_expand_coverage next.. It is categorised as a Destructive tool in the Keploy MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
Register the Keploy MCP server in PolicyLayer and add a rule for devloop_mutation_demo: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Keploy. Nothing to install.
devloop_mutation_demo is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the devloop_mutation_demo rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for devloop_mutation_demo. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
devloop_mutation_demo is provided by the Keploy MCP server (https://api.keploy.io/client/v1/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 103 Keploy tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.