MCP gateway & governance
in/guard/out vs Obot
Obot is the open-source-leaning entrant in the MCP platform space – hosting, registry, gateway, and chat client in one, with IdP integration, tiered RBAC roles, per-user OAuth passthrough, and attention to rug-pull and tool-poisoning scenarios. As MCP infrastructure, it covers a lot of ground. in/guard/out plays a different position: the runtime policy layer that decides what a governed run may do – on MCP traffic, on the LLM boundary, and on workflow steps that touch neither.
Side by side
| Capability | Obot | in/guard/out |
|---|---|---|
| Center of gravity | MCP infrastructure: hosting, registry, access, audit | Runtime enforcement: what this run may do, verified per call |
| Surfaces covered | MCP traffic and clients | LLM boundary + MCP + checkpoints in one trace |
| The model’s output | — | Grounding, claim audit, format repair, PII screen-and-restore |
| Tool-call arguments | Access policy per user/tool | Schema validation, risk tiers, dangerous-arg scan, action grounding in the run’s sources |
| Cross-request semantics | Per-call proxying and logs | Loops, taint, sequence policies, per-run hard budgets – enforced mid-run |
| Workflow conformance | — | Ordering policies auto-compiled from an n8n export |
| Poisoned tool results | Server vetting and registry controls | Every result injection-scanned before it re-enters the model’s context |
| Audit output | Interaction logs | The run graph with violations, cost burn-down, and checkpoint coverage |
Infrastructure and enforcement are complements
Obot answers “how do we host, catalog, and connect to MCP servers safely?” – with RBAC deciding who gets in. in/guard/out answers what happens next: the authorized agent whose context was poisoned three steps ago, the payment argument no source supports, the run that should have stopped at its budget two calls back. Those checks need run state and the LLM boundary, which MCP infrastructure – open source or not – doesn’t carry. The two stack cleanly, and in/guard/out’s own gateway brings manifest pinning and result scanning to whichever servers it fronts.
Frequently asked questions
Obot handles rug-pulls too – how is in/guard/out different there?
Both take the threat seriously; the difference is surface. Obot addresses it at the registry and platform level. in/guard/out pins the manifest per server at the gateway, flags drift as a violation in the run, injection-scans results, and – uniquely – carries the same run’s LLM calls and checkpoints in the same audit trail.
Is in/guard/out open source like Obot?
The product is commercial with a limited demo. What it ships that the open MCP platforms don’t is the runtime semantics layer: budgets with atomic reservations, action grounding, taint, conformance compiled from n8n, and the hallucination/PII/format pipeline on the LLM boundary.
Can in/guard/out front servers that Obot hosts?
Yes – the MCP gateway fronts any reachable MCP server. Hosting and registry stay where they are; runtime policy and the run graph come from the proxy.
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.