MCP gateway & governance
in/guard/out vs Runlayer
Runlayer is the identity-first entrant in enterprise MCP security – IdP-integrated access control, an MCP catalog, shadow-AI discovery, threat detection, VPC deployment, and marquee logos early. Its question is an IT question: which people and agents may reach which servers, under what conditions? in/guard/out asks the runtime question that starts after access is granted: what is this run actually doing – across its LLM calls, tool calls, and workflow steps – and should it continue?
Side by side
| Capability | Runlayer | in/guard/out |
|---|---|---|
| Unit of governance | The user, the agent identity, the connection | The run – one task’s requests, tool calls, and checkpoints, correlated and budgeted |
| Surfaces covered | MCP traffic | LLM boundary + MCP gateway + non-LLM checkpoints, one policy engine and audit trail |
| The model’s output | — | Grounding, claim audit, format repair, content safety, PII screen-and-restore |
| Tool-call arguments | Access policy + threat detection on requests | JSON-schema validation, risk tiers, dangerous-arg scanning, action grounding against the run’s sources |
| Cross-request semantics | Per-request authorization | Loop fingerprinting, taint tracking, sequence policies over tool order |
| Cost governance | — | Per-run hard budgets – cost, steps, tool calls – reserved before the next call spends |
| Workflow conformance | — | Ordering policies auto-compiled from an n8n export |
| Audit output | Access and request logs | The reconstructed run graph with violations, cost burn-down, and coverage |
Different buyer, different failure
Access governance protects you from the wrong person or agent using a tool. It has little to say when the right agent, properly authorized, is manipulated into doing the wrong thing – a poisoned ticket plants a payee, the model promises a refund no workflow executed, a loop quietly spends the budget. Those failures live between the model and the tools, inside a legitimate session. in/guard/out is built for exactly that layer: argument-level checks before the call forwards, budgets enforced mid-run, and every step – LLM or not – in one graph.
The two postures coexist without friction: an identity-first platform can front your organization’s MCP estate while in/guard/out governs your product’s agent runs – and in/guard/out’s own MCP gateway pins manifests and injection-scans results for the servers it fronts.
Frequently asked questions
Is in/guard/out an enterprise MCP catalog?
No – no employee catalog, no SSO provisioning, no shadow-AI discovery. Those are the identity lane. in/guard/out governs runtime behavior: what a governed run may call, with which arguments, in what order, at what cost, grounded in what evidence – plus the whole LLM boundary, which access platforms don’t touch.
We’re deploying an MCP access platform – does in/guard/out still add anything?
The runtime half. Access control decides who may call a tool; in/guard/out decides whether this specific call – these arguments, this point in this run, this budget – should execute, and repairs or blocks the model’s output on the way. The failure modes it catches occur inside fully authorized sessions.
Does in/guard/out handle rug-pulled MCP servers?
Yes – its gateway pins the tool manifest of servers it fronts and flags drift, injection-scans returned results, and enforces the checkpoint policy before forwarding a call. A deny is a protocol error the client can’t ignore.
They govern who connects. We govern what runs do.
in/guard/out covers the runtime half - budgets, grounded actions, the LLM boundary - and coexists with an identity-first MCP platform. We are running a limited demo - sign up and we will get you in as soon as we can.