MCP Sampling Attack — agent-side resource theft + conversation hijacking
MCP sampling allows servers to request additional model calls during a session. The protocol relies on an implicit trust model and lacks robust built-in security controls. Attackers exploit this for resource theft (drain compute quota), conversation hijacking (inject persistent instructions), and covert tool invocation (hidden tool calls + filesystem operations).
- MCP-using agents allowing model sampling
- Agents with implicit sampling-trust model (no robust built-in security controls)
- Hosted MCP servers without per-call quota enforcement
What an attacker does
A malicious MCP server, on tool invocation, requests many sampling calls back to the agent's model. Each sampling call carries adversarial input that the model processes as if it came from the user. By the end of the session, the agent has burned hours of compute budget AND its conversation state has been hijacked with attacker-controlled context that persists for the rest of the session.
How to detect
Monitor sampling-call patterns per MCP server — sudden quota burn or sampling-vs-tool-call ratio spike is the signal. Securie's cost-firewall + agent-scope expose these counters per session.
How to fix
Scope-restrict every sampling call. Bound max-concurrent samples per agent. Apply Llama-Guard 4 to sampled outputs before they re-enter the conversation context.
Class-vulnerability per Unit 42How Securie catches Class-vulnerability per Unit 42
Securie's cost-firewall enforces per-tenant compute caps with fail-closed reservation; sudden sampling-call bursts trip the soft-cap warn before the hard-cap hits. agent-scope's per-session bounded sampling limit prevents conversation hijacking via sampling-call abuse.