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