MCP gateway & governance
in/guard/out vs MintMCP
MintMCP productizes MCP curation: Virtual MCP Bundles give each team a per-use-case endpoint with SCIM-driven membership and a curated tool list, agent identities get M2M auth, and customer middleware can call out to DLP vendors. It’s a clean answer to tool sprawl and least-privilege visibility. in/guard/out enforces one level deeper – not which tools an agent may see, but whether this call, with these arguments, at this point in this run, should happen.
Side by side
| Capability | MintMCP | in/guard/out |
|---|---|---|
| Governance depth | Which tools each team/agent can see and call | What each call does: schema-validated arguments, risk tiers, ordering, grounding |
| Surfaces covered | MCP traffic | LLM boundary + MCP + checkpoints – one policy engine, one audit trail |
| The model’s output | — | Grounding, claim audit, format repair, PII screen-and-restore, content safety |
| Fabricated payees / injected args | — | Action grounding: consequential arguments must appear in the run’s sources |
| Data egress via tools | Middleware can call external DLP | Native taint tracking – screened PII, secrets, and canaries can’t exit via tool args; per-tool egress rules |
| Cross-request semantics | Per-call policy | Loops, sequence policies, and per-run hard budgets enforced across the run |
| Workflow conformance | — | Ordering policies auto-compiled from an n8n export |
| Audit output | Gateway logs | The run graph – every step, violation, and dollar of one task |
Curation bounds exposure. Semantics catch attacks.
A curated bundle is genuinely useful – an agent that can’t see a tool can’t call it. But the incidents that make headlines happen inside the curated set: the authorized payment tool called with a fabricated IBAN, the authorized email tool exfiltrating screened data, the authorized loop running two hundred times. Enforcement has to read the arguments, the ordering, and the run – which is what in/guard/out’s agent stack does, on MCP traffic and on the LLM boundary that curation platforms don’t see at all.
Frequently asked questions
We use bundles for least privilege – what’s missing?
Argument- and run-level semantics. A bundle answers “may this agent use the payment tool?”; in/guard/out answers “may it pay this payee, this amount, given what this run has actually read, within this budget, in this order?” Both are least privilege – one is static, the other is enforced per call.
MintMCP supports guardrails via middleware – isn’t that equivalent?
Middleware calling out to external checkers is per-request and bring-your-own-logic. in/guard/out ships the checks natively – grounding, taint, sequence, budgets – with run state behind them, plus the entire LLM-boundary pipeline (PII restore, hallucination repair, format) that MCP-only middleware never sees.
Can the two coexist?
Yes – curation platforms manage which servers and tools your organization exposes; in/guard/out governs the runs that use them. Its own MCP gateway adds manifest pinning and result scanning for the servers it fronts.
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.