MCP Gateway
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 |
Based on Runlayer’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.
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.