MCP gateway & governance
in/guard/out vs TrueFoundry
TrueFoundry consolidates AI infrastructure: an LLM gateway and MCP management in one control plane, in-memory auth and rate limiting for low latency, containerized MCP hosting, server groups, unified billing. It’s a platform answer to “how do we run all this?”. in/guard/out answers “how do we trust what runs?” – native guardrails with repair authority, run-scoped budgets and grounding, and an audit graph of what each agent task actually did.
Side by side
| Capability | TrueFoundry | in/guard/out |
|---|---|---|
| Center of gravity | Unified AI infrastructure: routing, hosting, rate limits, billing | Runtime governance: what each run may do, verified per call |
| Guardrail model | Integrations and configs at the gateway | Native pipeline – deterministic grounding, claim audit, PII restore, format repair, shields |
| When a check fails | Block at the gateway | Repair where safe; block or flag per policy, per key, per request |
| Agent budget enforcement | Rate limiting per key/team | Per-run hard caps – cost, steps, tool calls – reserved atomically mid-run |
| Tool-call semantics | Access control and server groups | Schema validation, risk tiers, action grounding, taint, sequence policies |
| Workflow conformance | — | Ordering policies auto-compiled from an n8n export |
| Steps that never touch an LLM | — | Checkpoint API + n8n node, LangChain callback, Python SDK |
| Audit output | Unified metrics and billing | The run graph – decisions, violations, and cost burn-down per task |
Platform latency and governance depth are different axes
A gateway that authorizes in microseconds is measuring the cost of infrastructure; governance spends its time on the checks themselves, and the only honest way to run both is to make the spend visible – which is why in/guard/out reports every stage’s latency and every guard-model dollar per request. Teams standardized on an infrastructure control plane don’t need to leave it: in/guard/out chains behind any OpenAI-compatible gateway, adds the run-scoped layer – budgets, grounding, conformance – and hands back a graph of what each agent task did.
Frequently asked questions
TrueFoundry has guardrails and rate limits – what’s the difference?
Configuration versus semantics. Gateway guardrails filter requests; rate limits cap throughput per key. in/guard/out reads the run: budgets that reserve before spending, arguments grounded in what the agent actually read, ordering enforced as a state machine, taint on egress – then repairs or blocks with the evidence logged.
We standardized on TrueFoundry for infrastructure – can we still use in/guard/out?
Yes – point the platform’s route at in/guard/out as an OpenAI-compatible backend (or front specific MCP servers with its gateway). Infrastructure stays consolidated; runs pick up governance and the audit graph.
Who is each product for?
An infrastructure control plane serves the platform team consolidating providers, hosting, and cost. in/guard/out serves the team shipping an agent that acts – refunds, payments, workflows – and the reviewer who has to sign off on letting it run unattended.
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.