Limitations

Container escape via kernel exploit — Box uses OS-level namespaces, not hardware virtualisation (Firecracker/gVisor). A kernel vulnerability could allow host escape. Acceptable for local development; production deployments should use a VM-backed executor.
Persistent injection (sleeper channels) — attacks that plant artifacts in long-term memory or filesystem cron paths and trigger later are out of scope. See Maloyan & Namiot, arXiv:2605.13471 for this threat model.
First-contact TOFU attacks — on first connection from a server that has never presented ATTESTMCP credentials, the suite operates in permissive mode. Key pinning is not yet implemented.
Legitimately certified malicious servers — attestation proves identity, not behaviour. A server with a valid certificate serving malicious content passes the attestation check.
Transport-layer attacks (MiTM, DNS rebinding) — require TLS termination and certificate pinning at the transport layer, which is outside the current scope.
Host /tmp bind mount — The Docker Compose setup binds the host's /tmp into the shield container so sandbox workspace directories are visible to the Docker daemon when spinning up child containers. This is a Docker-out-of-Docker constraint, not a design choice. Production deployments should run the sandbox manager on the host directly rather than inside a container.
Vulnerability to Advanced Obfuscated Injections — While the output sanitizer intercepts protocol-layer payloads across tool returns, resources/read, and prompts/get channels, it relies on exact string and pattern matching. Advanced encoding bypasses (such as lookalike Unicode homographs, zero-width space disruptions, or base64 blocks embedded inside benign paragraphs) can still evade cleartext detection filters.
Lack of Static Configuration and Secret Auditing — The suite does not scan workspace configs, env files, or JSON configs for exposed API keys, credentials, or insecure HTTP endpoints prior to deployment.
Lack of Supply Chain / Dependency Verification — The stdio proxy spawns server commands directly (e.g., npx -y) without verifying if the commands are pinned to secure, verified versions, leaving it vulnerable to dependency hijacking.
Lack of Tool Schema/Description Hardening — The proxy enforces namespace permissions strictly on tool names. It does not inspect tool schemas, arguments, or descriptions to determine if the definitions themselves are structured to prevent prompt injection or LLM manipulation.
Sequence Rules Actions — Sequence rules currently only support block actions. "Warning-only" telemetry modes are a future work item.
Window-size selection — Detection rate and false-positive rate trade off sharply, not gradually, as sliding window size w increases: true detection saturates at 100% by w = 4, but the false-positive rate (measured against an adversarially-constructed benign corpus) climbs from 92.86% at w = 4 to 100% at w = 5 and stays there through w = 10. There is no single window size that maximizes detection without also flagging nearly every case in that adversarial-benign set. No single w is correct for every deployment — operators should tune w to the longest ordinary multi-step workflow they expect, not to the longest attack sequence, since detection does not improve further past that point while false positives keep rising. A few specific benign patterns are structurally indistinguishable from an attack at any window size; those require more specific sequence patterns rather than a window-size change.
Cross-server session correlation — SessionStore keys history by server_id, so each server's call history is tracked in isolation. This is a deliberate choice: pooling session history across servers in a shared, multi-tenant deployment would let an operator see every tenant's activity on every server, which undermines the isolation such a deployment is supposed to guarantee. The cost is that an attack sequence deliberately split across multiple backend servers (step 1 to server A, step 2 to server B, step 3 to server C) is invisible to the deployed system — each server's session history only contains its own fragment of the sequence, so detection on this attack class is currently 0%. A standalone (non-deployed) simulation that pools history under a single client identifier shows this gap is closable — it raises detection to 100% — but only at the cost of the cross-tenant isolation described above, and this pooled configuration is not part of the shipped system.
Session identity rotation and server pinning — Session history is keyed off the caller-supplied x-mcpsec-server-id header, and the proxy does not cryptographically verify the upstream server's identity when a request first arrives. An adversary who rotates this identifier on each request can deliberately fragment their own activity into separate session streams, breaking up the sliding window and evading multi-turn detection. Closing this would require binding session identity to something the server can't spoof — e.g. mutual TLS, TPM-backed attestation, signed session tokens, or a trusted server identity registry — none of which are implemented yet.
Single-machine persistence — The SQLite-backed session store lives on a single file on a single machine, which is enough to survive a process restart but not enough to survive horizontal scaling. A production deployment running multiple parallel proxy workers behind a load balancer would still be vulnerable if a malicious sequence were split across two different workers, since each worker's SQLite file only contains the requests that worker itself handled. A shared, network-accessible backend (e.g. Redis) would extend the same restart-survival guarantee across all workers; this migration hasn't been evaluated.
Rate-limiting benchmark gap — Previously a gap, now resolved in MPS-033 (V4). The sequence engine supports order-agnostic rate-limit rules (rapid_tool_escalation with max_calls/window_seconds), which catch high-frequency abuse even if an attacker scrambles call order to evade pattern matching. MPS-033 isolates and empirically validates this mechanism.

Future Plans

Build a Custom, Pure-Python Prompt Injection Guardrail: Avoid heavy external dependencies (like Llama-Guard) by implementing a multi-tiered heuristic scoring engine directly in Python. This engine will analyze texts dynamically using:
- Imperative Constraint Override Detection: Scanning for semantic combinations of override/bypass verbs (e.g., ignore, bypass, forget) coupled with target objects (e.g., instructions, rules, system).
- Roleplay and Persona Hijacking Scans: Identifying attempts to establish alternative identities (e.g., you are now, act as, DAN).
- System Prompt Leaking Detection: Flagging phrases asking the AI client to output or repeat previous instructions (e.g., output the above, repeat from the beginning).
- Entropy and Obfuscation Filters: Inspecting payloads for zero-width spaces, excessive Unicode anomalies, or base64 patterns commonly used to hide injection payloads from tokenizers.
Implement Command / Shell AST Parsers: Expand AST scanning beyond Python. Implement a bash/shell command parser (e.g., using bashlex) to analyze arguments passed to shell execution tools, blocking dangerous redirectors (>), pipe constructs (|), or subshells ($()) regardless of the parameter names used.
Stricter Filesystem and Workspace Sandboxing: Control what files the client agent is allowed to read. Prevent the client from reading config or workspace rule files (like .cursorrules) unless explicitly trusted/signed, or execute filesystem operations inside a restricted chroot or container namespace.