Skip to content
in/guard/out
in/guard/out

MCP gateway & governance

in/guard/out vs MCPX

MCPX is Lunar.dev’s MIT-licensed MCP gateway, best known for Tool Groups: two teams hit the same server and see different tool subsets, which shrinks the over-privileged-agent problem at the infrastructure layer, with broad client support and an enterprise tier for IdP and risk scoring. Scoping what an agent can see is the first cut. in/guard/out makes the second and third: validating what each call does, and governing what the whole run is allowed to become.

Side by side

CapabilityMCPXin/guard/out
Governance depthScopes which tools each team/agent seesValidates each call: schema, tiers, dangerous args, grounding – and each run: order, loops, budgets
Surfaces coveredAgent-to-MCP trafficLLM boundary + MCP + checkpoints, one audit trail
The model’s outputGrounding, claim audit, format repair, PII screen-and-restore
Fabricated or injected argumentsAction grounding: a payee or amount must appear in the run’s sources
Data egress via toolsTaint tracking with per-tool PII egress rules
Cost governancePer-run hard budgets, reserved atomically before the next call
Poisoned tool resultsInjection-scanned before re-entering the model’s context
Audit outputGateway logsThe run graph with violations, cost, and coverage

Seeing fewer tools is not the same as being governed

Tool Groups answer a real question – why should the support agent see the deploy tools? – and infrastructure-layer scoping is the right place for it. The failures that remain are semantic: the in-scope payment tool called with an out-of-thin-air IBAN, the in-scope email tool leaking screened data, the in-scope loop that never stops. Catching those requires reading arguments against the run’s history and enforcing budgets mid-flight – the runtime layer in/guard/out ships, on MCP traffic and on the LLM boundary a tool-scoping gateway never sees.

Frequently asked questions

We scope tools with MCPX – what would in/guard/out add?

Everything below the tool list: argument validation against schemas and risk tiers, action grounding, taint, sequence policies, per-run budgets, result scanning – plus hallucination repair, PII round-tripping, and format enforcement on the model side. Scoping and semantics stack; neither replaces the other.

MCPX is open source – is in/guard/out?

in/guard/out is commercial with a limited demo. The paid layer is precisely what the open scoping gateways don’t attempt: run-state enforcement with atomic budgets, grounding, conformance compiled from n8n, and one audit graph across LLM, MCP, and checkpoint surfaces.

Can they run together?

Yes. Keep MCPX as the scoped entry point to your servers; point governed agents through in/guard/out for run semantics. Both speak MCP, so the order is an architecture choice, not a constraint.

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.