MCP Gateway
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 |
Based on Zuplo MCP Gateway’s publicly available information. We’ve done our best to keep it accurate, but details may have changed since we last looked. If you’ve noticed an error, please email us.
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.