Threat Scenarios

1. Prompt injection triggers a destructive shell call

Scenario: An untrusted document convinces the model to run execute_shell with rm -rf or curl ... | sh.

Mitigation: Do not allow execute_shell unless you must. If you must, add deny regex rules for destructive patterns.

Expected outcome: SecureMCP-Lite blocks the request locally and returns a JSON-RPC error before the target MCP server receives it.

2. Over-permissioned filesystem server exposes secrets outside the project

Scenario: The target MCP server can read arbitrary files on disk, but the client should only access source files.

Mitigation: Allow only the file-related tools you need and constrain the path argument to ^/workspace/src(?:/.*)?$ or an equivalent project-specific regex. Add a deny rule for \.\. traversal attempts.

Expected outcome: Requests for /etc/passwd, .env, or ../ paths are blocked by policy.

3. SQL tool misuse from a looping agent

Scenario: An agent repeatedly attempts schema-changing queries after a failed plan.

Mitigation: Set a conservative requestsPerMinute limit and add deny regex rules for DROP, TRUNCATE, and ALTER.

Expected outcome: Unsafe queries are denied. Repeated request bursts are rate-limited with local JSON-RPC errors.

4. Runaway MCP loop floods the server

Scenario: A planner bug causes hundreds of repeated tool calls in a short window.

Mitigation: Use the built-in sliding window limiter.

Expected outcome: Once the configured threshold is hit, SecureMCP-Lite returns rate-limit errors and stops forwarding those requests upstream.

5. Accidental destructive operations

Scenario: A legitimate workflow is misconfigured and points a file tool or shell tool at the wrong directory.

Mitigation: Start with a narrow allowlist, log every intercepted request, and review blocked events before loosening policy.

Expected outcome: Operators can see exactly what was attempted and adjust policy deliberately instead of granting blanket access.