Skip to main content
Every coding agent and AI app reaches the TrueFoundry AI Gateway differently, and that decides what you can govern. This page is the single reference: find the tool, read across. For Claude’s plans and interfaces there is a more detailed table.

How to read the columns

Every cell links to the tool’s guide, which has the setup steps and the vendor’s mechanism.
  • Model traffic via gateway: can the tool’s model calls be sent to the gateway? Full means every model request, so you get per-user cost tracking, budgets, rate limits, and attribution on all of it. Partial means only some features route; you get those controls on the routed traffic. None means the app calls its vendor’s backend with no endpoint setting, so there is nothing to meter.
  • Enforcement fleet-wide: can an admin push the gateway configuration so users can’t remove it? Full means a locked or system-level config exists (TrueFoundry’s tfy-local-ai-setup for Claude and Codex, the vendor’s managed config for the rest). Partial means the setting lives in user-editable config; push it with MDM and pair it with network policy that blocks direct vendor endpoints.
  • Guardrails and audit: can the gateway inspect, block, and log content? Full means gateway guardrails and request logs apply to the tool’s traffic, sometimes with extra client-side or vendor-side hooks. Partial means allow/deny and audit on content only, without cost or budget controls.
  • MCP via gateway: can the tool’s remote MCP servers be pointed at the MCP Gateway, with an admin able to enforce that? Full means pre-provisioning plus an allowlist or a block on user-added servers. Partial means the user can point servers at the gateway but an admin can’t enforce it. This is independent of model routing.

The table

Ordered from most to least governable. Every Docs link opens the tool’s guide at the relevant section.
  • ✅ Full: the gateway covers everything the column describes, and an admin can enforce it.
  • 🟡 Partial: the gateway covers only some of the column, or covers it only for users who set it up themselves.
  • ❌ None: the gateway can’t reach it.

Three things that hold for every row

MCP governance doesn’t depend on model routing. Every tool above can point remote MCP servers at the MCP Gateway, and those tool calls get allowlisting, per-user OAuth, tool-level RBAC, guardrails, and audit, even for the two apps whose model calls can’t be governed at all. Most vendors now also ship an admin allowlist, so you can make the gateway the only MCP path, not just the recommended one. Who pays is decided by the credential that reaches the vendor, not by the tool. With an API key on the gateway’s model account, every request is billed per token to that key and the user’s subscription is untouched. Claude Code and Codex CLI can instead forward the user’s own login so a seat pays; see Authentication and who pays. Partial enforcement still means full governance for the users who set it up. The gap is enforcement: a developer can remove the setting and talk to the vendor directly. Where that matters, block the vendor’s API endpoints from managed devices with network policy so the gateway is the only path that works, and prefer the tools in the top half of the table for new rollouts.