Medium Risk

devloop_resolve_storage

Resolve the storage mode for V1 ("user maintains the flow") API tests on this app. ═══════════════════════════════════════════════════════════════════ MUST BE YOUR FIRST MCP CALL for ANY of these dev verbs/intents: ═══════════════════════════════════════════════════════════════════ * "run the san...

Part of the Keploy server.

devloop_resolve_storage can modify Keploy data, with no limits today. PolicyLayer puts allow, deny, and rate-limit rules on every call. Live in minutes.

SECURE KEPLOY →

Free to start. No card required.

AI agents use devloop_resolve_storage to create or modify resources in Keploy. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.

Without a policy, an AI agent could call devloop_resolve_storage repeatedly, creating or modifying resources faster than any human could review. PolicyLayer's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach Keploy.

Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.

policy.json
{
  "version": "1",
  "default": "deny",
  "tools": {
    "devloop_resolve_storage": {
      "limits": [
        {
          "counter": "devloop_resolve_storage_rate",
          "window": "minute",
          "max": 30,
          "scope": "grant"
        }
      ]
    }
  }
}

See the full Keploy policy for all 103 tools.

Get this rule live on your own Keploy server in minutes. PolicyLayer enforces it on every call, before it runs.

ENFORCE ON MY KEPLOY →

View all 103 tools →

These attack patterns abuse exactly the kind of access devloop_resolve_storage gives an agent. Each links to the full case and the policy that stops it:

Browse the full MCP Attack Database →

Every attack above starts with a tool call. PolicyLayer checks each one against your policy first, so devloop_resolve_storage only ever does what you allow.

SECURE KEPLOY →

Other write tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.

What does the devloop_resolve_storage tool do? +

Resolve the storage mode for V1 ("user maintains the flow") API tests on this app. ═══════════════════════════════════════════════════════════════════ MUST BE YOUR FIRST MCP CALL for ANY of these dev verbs/intents: ═══════════════════════════════════════════════════════════════════ * "run the sandbox tests" / "run the API tests" / "test sandbox" / "run keploy tests" * "record the sandbox" / "rerecord" / "refresh the mocks" / "capture mocks" * "replay the sandbox" / "replay the tests" / "show me the report" / "what failed in the last run" * "generate keploy tests" / "add a keploy test for <endpoint>" * "set up keploy in this repo" / "onboard this service to keploy" * any other reference to keploy/api-tests/, sandbox tests, integration tests, mocks, suites REASON: this is the gate that determines whether the app is on the V1 (repo-mode) code path or the legacy cloud-mode code path. The two paths use entirely different MCP tool surfaces: ┌───────────────────────┬─────────────────────────────────────────────────────────┐ │ Storage mode │ Tools to use │ ├───────────────────────┼─────────────────────────────────────────────────────────┤ │ "repo" │ devloop_* tools only. NO cloud-mode tools. │ │ │ (record_sandbox_test, replay_sandbox_test, │ │ │ replay_test_suite, create_test_suite, list_branches, │ │ │ get_app_testing_context, listTestSuites etc. will │ │ │ REFUSE with a redirect to the V1 surface.) │ ├───────────────────────┼─────────────────────────────────────────────────────────┤ │ "cloud" or "" (unset) │ Cloud-mode tools (record_sandbox_test, │ │ │ replay_sandbox_test, replay_test_suite, │ │ │ create_test_suite, list_branches, get_app_testing_ │ │ │ context, listTestSuites, etc.). devloop_* tools may │ │ │ also be called for the V1 cloud-mode path. │ └───────────────────────┴─────────────────────────────────────────────────────────┘ DO NOT SKIP THIS. If you reach for cloud-mode tools first (replay_sandbox_test, list_branches, listTestSuites, etc.) without calling devloop_resolve_storage, you WILL misroute repo-mode apps and tell the dev to "upload local tests as suites and record into the cloud" — the EXACT regression that prompted these MCP-side guardrails. The cloud-mode tools server-side gate on devloop_storage_mode == "repo" and will refuse the call with a redirect message; devloop_resolve_ storage front-runs that refusal cleanly. Resolution order: 1. If app.devloop_storage_mode is set → return {mode, source: "persisted"}; do NOT re-ask. 2. Else if the dev's repo (app_dir) already contains keploy/api-tests/ → ATEMPT to infer repo mode. This tool returns source="asked" with a hint asking you to check the dev's filesystem; if you confirm keploy/api-tests/ exists, call devloop_set_storage_mode({app_id, mode:"repo", reason:"inferred_local_tests_exist"}) and proceed silently. 3. Else → return {source: "asked"} with the trade-off text in message; surface that to the dev, get yes/no, persist via devloop_set_storage_mode. The AI is responsible for inspecting the repo (this MCP server does not have filesystem access). Use your native filesystem tools (read/grep) to check whether keploy/api-tests/ exists under app_dir. APP RESOLUTION — the dev should NEVER have to type an app_id. Pass EITHER: * app_id (UUID) — exact, fast path. Use this once you've resolved it earlier in the conversation. * app_name_hint — a case-insensitive substring of the app name (typically the cwd basename). The tool calls listApps(q=hint) and resolves to a unique match. If neither is set, the tool errors with the candidate list so you can ask the dev. If app_name_hint matches multiple apps, the error names them and asks you to disambiguate. If no app matches, you propose creating one (call createApp) BEFORE re-running this tool.. It is categorised as a Write tool in the Keploy MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

How do I enforce a policy on devloop_resolve_storage? +

Register the Keploy MCP server in PolicyLayer and add a rule for devloop_resolve_storage: 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.

What risk level is devloop_resolve_storage? +

devloop_resolve_storage is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Can I rate-limit devloop_resolve_storage? +

Yes. Add a rate_limit block to the devloop_resolve_storage 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.

How do I block devloop_resolve_storage completely? +

Set action: deny in the PolicyLayer policy for devloop_resolve_storage. 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.

What MCP server provides devloop_resolve_storage? +

devloop_resolve_storage 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.

Enforce policy on every Keploy tool call.

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.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.