Originally published as part of VerifyClaw's internal security research into LLM-facing attack surfaces — adapted here for a general audience.
It's tempting, once you have good visibility into model behavior, to assume that visibility covers "AI security" as a whole. It doesn't. Some of the most consequential failures in an MCP deployment — an authorization check bound to the wrong session, a protocol message accepted without validation, a server process taking an action outside its intended scope — never touch model input, output, or inference at all.
Why it matters for MCP agents
An agent framework can have excellent prompt hygiene and still be compromised through a hole in how it authenticates a tool call, resolves a server identity, or handles a malformed protocol message. These are conventional application-security problems wearing an AI-shaped deployment, and they need conventional application-security tooling — access control review, protocol conformance testing, process sandboxing — not LLM-behavior analysis.
How we study it
The discipline that matters here is keeping three outcomes distinct: an observed model behavior, an unavailable model measurement (we didn't capture the right signal), and a not-applicable model measurement (the event never touched the model at all). A generated URL is not evidence a connection was made; a command string in a model's output is not evidence it was executed. Treating "no model-level effect" as "no security event" is the mistake this concern exists to name.
Related reading
- Attaching as a Callee: Defensive Probes (podcast)
- The Secure Boundary Model and Its Thirteen Principles (podcast)
Our SAF-MCP audit tests protocol- and authorization-layer behavior alongside model-facing checks — the full 86-technique suite covers both.