Approaches to securing AI agents and their MCP tools
There are five common ways to secure AI agents, and they work at different layers. Pre-deployment scanning vets tools before they connect. Access gateways control who may call what. Model-layer guardrails filter what goes into and out of the model. In-process governance applies policy from inside the agent. CheckedAgent inspects the MCP traffic itself — every tool request and every tool response — inline on the wire, in a separate trust boundary from the agent. They are complementary layers, not substitutes; most mature deployments run more than one.
Here's the part most stacks miss: the dangerous moment often isn't the request — it's the response. A tool the agent already trusts can return poisoned data or a hidden instruction; the agent acts on it, and data leaves. Inspecting what comes back — and tying it to what was asked — is the layer that closes that gap, and it's the one the other approaches aren't built for.
- The request looks normal — a legitimate call to a tool the agent already trusts.
- The tool returns a manipulated response — exfiltrated data shaped like a normal result, or a hidden instruction the agent will follow.
- The agent acts on it, and the data is gone. Pre-deployment scanning cleared the tool on day one. The access gateway authorised the call. The model guardrail never saw the MCP exchange. Nothing inspected the response against the request.
How the five approaches compare
| Pre-deployment scanning | Identity / access gateway | Model-layer guardrails | In-process governance | CheckedAgent | |
|---|---|---|---|---|---|
| Primary job | Vet tools before they connect | Authenticate & authorise calls | Filter model inputs/outputs | Apply policy inside the agent | Inspect MCP traffic on the wire |
| When it acts | Before deployment (static) | Runtime, at the call | Runtime, model boundary | Runtime, in-process | Runtime, inline & synchronous |
| Trust boundary vs the agent | Offline | Usually separate | At model I/O | Same process as the agent | Separate (sidecar) |
| Inspects MCP request payload | — | ~ access, not payload content | — model I/O, not MCP | ✓ ¹ | ✓ on the wire |
| Inspects MCP tool responses | — | — | ~ only text passed to the model | ~ varies | ✓ |
| Correlates request ↔ response | — | — | — | ~ varies | ✓ by JSON-RPC id |
| Flags tool-definition changes after approval | ~ only on re-scan | — | — | ~ startup scan | ✓ continuous |
| No agent code changes | ✓ | ✓ gateway | ~ varies | — library integration | ✓ |
| Model / framework / cloud-agnostic | ~ | ~ | — often platform-bound | — framework-specific | ✓ |
¹ In-process governance can inspect request payloads — it runs in the agent's call path. The distinction is position, not visibility: it sits inside the agent's own trust boundary and is tied to one framework. CheckedAgent inspects from outside that boundary, framework-agnostic, and also inspects the response and correlates it to the request — which in-process governance generally does not.
When you need each
Pre-deployment scanning
Catches a malicious or sloppy tool before you connect it. It can't see what a tool does once it's live, or a tool that passes the scan on day one and changes on day thirty.
Identity / access gateway
Decides who and what may call which tool. Essential, but it governs access, not the content of the messages that flow once access is granted.
Model-layer guardrails
Filter unsafe content at the model's input and output. They operate on what the model sees, not on the MCP protocol exchange between agent and tool.
In-process governance
Applies policy from inside the agent's own process. Fast to adopt within a given framework, but it shares the agent's trust boundary and is tied to that framework.
CheckedAgent
Inspects the MCP traffic itself, inline, in both directions, from outside the agent's trust boundary, with no agent code changes — so it covers the runtime, on-the-wire moment the others can't see, which is exactly where data exfiltration and tool-poisoning happen.
Common questions
What's the difference between scanning an MCP server and inspecting it at runtime?
Scanning checks a tool's definition and code before you connect it; runtime inspection watches the actual messages once it's live. A tool can pass a scan and later be changed or compromised, so the two address different moments and work best together.
Why does inspecting tool responses matter so much?
Because the most dangerous attacks don't look like attacks on the way in. A legitimate request to a trusted tool can return a manipulated response — exfiltrated data dressed up as a normal result, or a hidden instruction the agent then obeys. Pre-deployment scans, access gateways and model guardrails all act before or beside that moment; none inspect the tool's response and correlate it to the request. That correlation is where exfiltration and tool-poisoning get caught.
Do model-layer guardrails cover MCP tool responses?
They filter what the model reads and writes. They don't operate at the MCP protocol layer or correlate a tool's response to the request that triggered it, so a manipulated tool response isn't their surface.
If my agent framework already has built-in governance, do I still need CheckedAgent?
In-process governance can inspect requests, but it runs inside the agent's own trust boundary and is tied to that framework. CheckedAgent inspects from outside that boundary, on the wire, across frameworks, and correlates responses to requests — so it's a complementary layer, not a replacement.
Is CheckedAgent an alternative to an identity or access gateway?
No. A gateway decides who may call what; CheckedAgent inspects the content of the calls and responses that flow once access is granted. They sit side by side.
Every Agent action.
Checked.
30-minute walkthrough where we will show the full pipeline, run your suspected attack patterns through it, and answer the questions your auditor is already asking.