Originally published as part of VerifyClaw's internal security research into LLM-facing attack surfaces — adapted here for a general audience.
Cache state and inference isolation is less about attackers and more about the plumbing an attack could exploit if it were wrong. Applications that reuse an inference context across requests, or run auxiliary scoring alongside a primary generation, are making an implicit isolation promise: none of that extra work is allowed to change the answer the user actually receives. When that promise breaks, you get cross-request contamination that has nothing to do with prompt content.
Why it matters for MCP agents
Multi-tenant deployments and any system that reuses KV-cache state across sequences inherit this risk directly — a context that isn't fully isolated per session can leak state between users or between an evaluation pass and the real one. This is an infrastructure property, not a model-behavior property, which is exactly why it's easy to miss when a security review focuses only on prompts and outputs.
How we study it
The verification is comparative: run the primary prediction with auxiliary candidate-scoring enabled and disabled, and confirm the two match. If they diverge, isolation has already failed, independent of anything an attacker put in the prompt. This is infrastructure hygiene in the same spirit as sandboxing a skill's execution — the isolation guarantee has to hold regardless of what's asked of the model, not just for well-behaved requests.
Related reading
- Jumping the Sandbox Without Touching It (podcast)
- The Secure Boundary Model and Its Thirteen Principles (podcast)
Our sandbox-based SAF-MCP checks apply identical isolation to every server under test — the same principle applies at the infrastructure layer.