MCP gateway & governance
in/guard/out vs Zuplo MCP Gateway
Zuplo’s MCP Gateway (public beta, June 2026) does the unglamorous auth work properly: spec-correct OAuth with dynamic client registration and PKCE, credential brokering that answers “whose credentials hit the upstream?” per route, and virtual MCP servers that expose a curated tool view. If your problem is connecting clients to MCP servers safely, it’s a credible managed answer. in/guard/out starts where a completed handshake ends: is this authorized call, with these arguments, at this point in this run, something that should happen?
Side by side
| Capability | Zuplo MCP Gateway | in/guard/out |
|---|---|---|
| Question answered | Who is this client, and whose credentials reach the upstream? | Should this call execute – and should this run continue? |
| Surfaces covered | MCP connections | LLM boundary + MCP + checkpoints, one policy engine |
| Tool-call arguments | Curated tool views per virtual server | Schema validation, risk tiers, dangerous-arg scanning, action grounding |
| Cross-request semantics | Per-connection auth and audit | 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 context |
| Workflow conformance | — | Ordering policies auto-compiled from an n8n export |
| Audit output | Per-user attribution in gateway logs | The run graph: every step, violation, and dollar of one task |
After the handshake
Spec-correct OAuth eliminates a whole class of credential mess, and brokering keeps tokens off desktops – plumbing worth having. But authorization ends at identity: the properly-authenticated agent with properly-brokered credentials can still be steered into paying a fabricated invoice or looping through its budget, because nothing in the OAuth flow reads arguments, ordering, or cost. That’s the runtime layer in/guard/out enforces – with the LLM boundary and non-LLM checkpoints in the same trace, which a connection-layer gateway can’t see.
Frequently asked questions
Our MCP auth is solved by Zuplo – what’s left?
The behavior. Auth establishes who is calling; in/guard/out governs what the call does: argument-level validation, action grounding against the run’s sources, taint on egress, budgets that stop the next call, and the model-side pipeline. Different layers, both needed for consequential agents.
Does in/guard/out do MCP auth brokering?
It authenticates clients to its gateway and manages downstream server registration, but spec-deep OAuth brokering is not its focus – if that’s your gap, a connection-layer product is the right tool, with in/guard/out governing the runs that flow through it.
Can they chain?
Yes – both speak MCP over streamable HTTP. Broker connections at the edge; enforce run semantics behind it; correlate the run with the same session id across in/guard/out’s three surfaces.
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.