MCP gateway & governance
in/guard/out vs Praesidia
Praesidia positions as an AI-agent governance control plane built around the November 2025 MCP authorization spec – OAuth 2.1 with PKCE, resource-bound tokens, per-caller tool scoping, with MCP servers as first-class registered entities. Spec fidelity matters; tokens that can’t be replayed against the wrong server close real holes. It is still an authorization story. in/guard/out’s story is behavior: the authorized token, at the authorized server, making a call that should never happen.
Side by side
| Capability | Praesidia | in/guard/out |
|---|---|---|
| Question answered | Is this caller authorized for this server and tool scope? | Should this call, in this run, execute – and at what cost? |
| Surfaces covered | MCP authorization layer | LLM boundary + MCP + checkpoints, one audit trail |
| Tool-call arguments | Scoped per caller | Schema-validated, risk-tiered, scanned, and grounded in the run’s sources |
| Cross-request semantics | Per-connection authorization | Loops, taint, sequence policies, per-run hard budgets |
| The model’s output | — | Grounding, claim audit, format repair, PII screen-and-restore |
| Poisoned tool results | — | Injection-scanned before re-entering the model’s context |
| Workflow conformance | — | Ordering auto-compiled from an n8n export |
| Audit output | Authorization events | The run graph with violations, cost burn-down, and coverage |
The spec secures the door, not the guest
Resource-bound tokens and PKCE close the credential holes the early MCP ecosystem shipped with – genuinely good hygiene, and the spec deserves adoption. What no authorization spec addresses is the semantic layer: the correctly-scoped agent whose context was poisoned, the in-scope tool receiving a fabricated payee, the run that has spent triple its budget on retries. Those need argument-level and run-level enforcement – and a view of the LLM boundary, where most of the manipulation actually happens, which an authorization control plane never sees.
Frequently asked questions
If we adopt the MCP auth spec fully, what risk remains?
The runtime risk. Authorization decides who may call what; it says nothing about arguments, ordering, cost, or what the model was manipulated into doing upstream of the call. in/guard/out enforces exactly that layer – and repairs the model-side failures (drifted numbers, malformed output, PII exposure) that never touch the auth flow at all.
Does in/guard/out implement the November 2025 auth spec?
Its gateway focuses on runtime inspection – manifest pinning, result scanning, checkpoint policy before forwarding – rather than replacing your authorization layer. Teams that want spec-deep OAuth at the edge can run it in front; in/guard/out governs the runs behind it.
Both products say “control plane” – what’s the practical difference?
Theirs governs access to agent infrastructure. in/guard/out governs behavior at runtime: per-call semantics, per-run budgets and conformance, and the model boundary – with every decision in one reconstructed run graph.
See it on your traffic first.
FIX mode observes without blocking, so you can measure what in/guard/out catches before enforcing anything. We are running a limited demo - sign up and we will get you in as soon as we can.