Integration
Guardrails & injection defense for MCP servers
MCP connects your agent to third-party tools – and third-party tools to your agent. The protocol itself has grown real security: the 2026 revisions brought an OAuth 2.1 authorization framework, incremental scope consent, and risk-hint tool annotations. That work governs who may connect, and with what permissions. What no spec can govern is what a specific call is about to do with the access it legitimately holds – and that is the half the gateway enforces.
Side by side
| Concern | MCP spec (2026) | in/guard/out gateway |
|---|---|---|
| Who may connect | OAuth 2.1 authorization, incremental scope consent – built into the protocol | Complements it: authenticated ≠ safe; each call is still inspected |
| Tool risk signals | Annotations (readOnlyHint, destructiveHint) – the spec itself says to treat them as untrusted hints | Permission tiers assigned by your policy, independent of the server’s self-description |
| Manifest drift (rug pull) | — not addressed | Manifest pinned at registration; drift = manifest_changed before further calls forward |
| Tool descriptions as attack surface | Consent prompts; hints | Descriptions injection-scanned; enforcement doesn’t depend on the model resisting them |
| Tool results | — returned to the client as-is | Injection-scanned before your agent’s context reads them |
| Argument safety | JSON schema in the manifest (client may validate) | Schema enforced, plus action grounding and taint tracking on argument values |
| Deny semantics | Client-side choice the model can reconsider | JSON-RPC error – the forwarded call didn’t happen |
| Cross-server run view | — per-connection | One run graph and one budget across every server in the task |
Enforcement in the middle of the conversation
The gateway integration puts enforcement in the middle: register a downstream server, route your client through the gateway URL, and every tools/call is inspected before it is forwarded. Because the gateway speaks MCP itself, its decisions bind – a denied call is a JSON-RPC error the client cannot treat as advisory. Results are injection-scanned before your agent’s context sees them, and the server’s tool manifest is pinned at registration – if it drifts later, that is a manifest_changed violation, not a silent rug pull.
The spec’s authorization work and the gateway are complementary by design. OAuth answers “is this client allowed to hold this scope?” once, at connection time. The gateway answers “should this call, with these arguments, run now?” – per call, against tool policy, permission tiers, grounding, and the run’s budget. Both questions need an answer; only one of them can live in a protocol document.
Setting it up with in/guard/out
1. Register the server
Add the downstream MCP server in the Keys tab. Its tool manifest is fetched and pinned at registration.
2. Repoint the client
Configure your MCP client to call the gateway URL for that server instead of the server directly. No client code changes – it is still MCP.
3. Set the policy
The same tool policy, permission tiers, grounding, and taint rules that govern the LLM boundary apply to gateway calls – configure once, enforced on both surfaces.
4. Watch for drift
A changed manifest – new tool, altered description – flags as manifest_changed before further calls forward. Review and re-pin deliberately, or cut the server off.
Frequently asked questions
The MCP spec now has OAuth and tool annotations – isn’t that enough?
They solve a different problem. OAuth 2.1 decides who may connect and with what scopes; annotations describe what a tool claims to be – and the spec explicitly says clients must treat them as untrusted. Neither inspects a specific call’s arguments, scans a result for injection, notices a changed manifest, or holds a budget. Authorization and enforcement layer, not compete.
Why not just enforce in the MCP client?
The client is the compromised party in the main attack scenarios – the model deciding whether a call is safe is the model the poisoned tool description just steered. The gateway enforces where the traffic flows, outside the agent’s influence.
Does the gateway work with any MCP server?
It fronts servers you register and speaks standard MCP to clients. If your client can point at a URL per server, it can point at the gateway.
What gets scanned in results?
The returned content is treated as untrusted input and run through the injection scan – patterns plus classifier – before your agent reads it. Flag in FIX, block in PREVENT.
How do gateway calls relate to the LLM-side view?
Same run, same ledger: gateway calls, model requests, and checkpoint decisions correlate by session and land in one run graph with one cost total and one audit trail.
Related
Put a trust boundary on your MCP tools
Front your MCP servers with the gateway - tools/call inspected, results scanned, manifests pinned against rug-pulls. We are running a limited demo - sign up and we will get you in as soon as we can.