AI gateway governance for MCP and agent access is converging

At a glance

What this is: This comparison shows how AI gateway design is expanding from model routing into MCP governance, shadow AI detection, and runtime control.

Why it matters: It matters because IAM, PAM, and NHI teams now have to decide whether agent and tool governance belongs in a gateway, at the endpoint, or across both.

By the numbers:

• TrueFoundry says its AI gateway adds only about 3 to 4 ms of overhead while serving 350+ RPS on a single vCPU.
• TrueFoundry says its gateway connects to more than 1,600 LLMs through one OpenAI-compatible API.

👉 Read TruFoundry's comparison of RunLayer and TrueFoundry for MCP governance

Context

AI gateway governance now covers more than model routing. In this comparison, the real issue is how organisations control model access, MCP tool access, and shadow AI activity without forcing security teams to stitch together separate discovery, policy, and audit layers.

For identity practitioners, the key question is where non-human identity controls live when agents, tools, and models all sit in the same workflow. That matters for NHI governance, because gateway-level policy can centralise authentication and tracing, while endpoint discovery can still be required to find undeclared tool use.

The article’s starting position is typical of current enterprise AI programmes: model access is already formalised, but agent and MCP governance is still being assembled piecemeal. That gap is now visible at the control-plane level, not just in isolated tool deployments.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: What is the difference between shadow AI discovery and runtime governance?

A: Shadow AI discovery finds hidden agents, tools, and MCP servers that were never formally approved. Runtime governance controls what happens when a request is made, including policy checks, approvals, and blocking. Teams need both because discovery without enforcement cannot stop misuse, and enforcement without discovery cannot govern systems it never sees.

Q: When should teams centralise AI gateway controls instead of using point tools?

A: Centralise when model routing, MCP access, audit, and policy all need to be managed together. Point tools work for narrow problems, but they fragment identity, logs, and approvals across systems. If multiple teams are building agents or using many model providers, a shared gateway reduces policy drift and makes governance measurable.

Q: Who is accountable when an AI agent makes a destructive tool call?

A: Accountability sits with the organisation that allowed the runtime, connector, and policy model to exist together without sufficient control. In practice, that means security, platform, and application owners all share responsibility for the guardrails that should have stopped the action at the tool boundary.

Technical breakdown

MCP gateway controls and tool-level authorisation

An MCP gateway sits between an agent and the tools it can call, authenticating requests and checking policy before the tool executes. In practice that means the control point is not the model itself, but the authorisation boundary around tool access, approval, and audit. When a gateway supports OIDC, JWT, API keys, Cedar, or OPA, it can enforce different trust decisions for different tools and sessions. The important architectural shift is that tool invocation becomes policy mediated rather than implicit in the agent workflow.

Practical implication: map every MCP tool to a named owner, policy, and approval path before allowing agent access.

Shadow AI discovery versus traffic governance

Shadow AI discovery and traffic governance solve different problems. Endpoint-based discovery finds unsanctioned agents, MCP servers, or skills that were never declared, usually through device management or endpoint telemetry. Traffic governance controls what happens once a request reaches the gateway, where policies, audit trails, and rate limits can be applied to known flows. If an organisation relies only on traffic control, it may still miss hidden tools on employee devices. If it relies only on discovery, it cannot enforce runtime behaviour at the point of use.

Practical implication: decide which team owns discovery and which team owns runtime enforcement, then connect the two control planes.

Unified audit trails for models, agents, and tools

A unified audit trail is valuable because model prompts, tool calls, and approval events often sit in separate logs unless the gateway aggregates them. For identity governance, that matters because the chain of custody for a non-human action depends on being able to reconstruct who or what initiated the call, which policy applied, and whether a human override occurred. Without that linkage, incident response becomes forensic guesswork. With it, teams can correlate model activity, MCP execution, and security approvals into one record.

Practical implication: require one audit schema that preserves agent identity, tool invocation, and approval evidence together.

Threat narrative

Attacker objective: The attacker wants to turn legitimate AI usage into unauthorised tool reach, hidden execution paths, or unrecoverable audit gaps.

1. Entry occurs when an employee or builder uses sanctioned model access while hidden MCP tools remain undeclared on devices or in local workflows.
2. Escalation occurs when the agent reaches tools through gateway trust paths or discovers broader access than the team intended to expose.
3. Impact occurs when the organisation cannot reconstruct which agent, tool, or policy decision produced the action, weakening containment and accountability.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is becoming the new identity control plane for AI workflows. Once models, agents, and tools are routed through the same gateway, the question is no longer simply who can sign in. It is which non-human identities can invoke which tools, under what policy, and with what evidence. That makes the gateway a governance surface, not just an infrastructure layer. Practitioners should treat MCP authorisation as part of identity architecture, not a separate AI plumbing decision.

Shadow AI discovery and runtime policy are complementary, not interchangeable: endpoint visibility can reveal undeclared MCP servers and skills, but it cannot by itself enforce least privilege at execution time. Gateway policy can block risky tool calls, yet it will miss assets that never traverse the gateway. The control gap is therefore distributed across discovery and enforcement. Security teams need both views if they want to govern unsanctioned AI behaviour rather than merely observe it.

Unified audit is the difference between AI oversight and AI guesswork. When prompts, tool calls, approval events, and model routing are split across systems, incident reconstruction becomes incomplete and accountability becomes arguable. A single trace that spans agent identity, tool invocation, and policy outcome gives IAM and security teams a defensible record. That record matters for investigations, access reviews, and privileged workflow governance.

Platform consolidation is pushing identity teams toward policy abstraction rather than point controls. The market signal here is not that every organisation needs one vendor, but that fragmented governance across models, agents, and MCP tools is becoming harder to sustain. Teams should expect buying decisions to hinge on how well a control plane normalises identity, access, and audit across the full AI stack. The practical conclusion is simple: evaluate whether your current architecture can govern both sanctioned and shadow AI without duplicating policy logic.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• A separate finding from the same research shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and breach-investigation blind spot.
• For practitioners building governance now, the next step is to pair that research with OWASP Agentic Applications Top 10 so policy covers both runtime behaviour and agent attack patterns.

What this signals

Identity teams should expect gateway architecture to become part of the access review conversation. If model routing, MCP tools, and approvals all sit behind one control plane, then access certification has to cover agent identities, tool scopes, and policy exceptions together. That is a governance shift, not just a deployment choice. The practical signal is that IAM, PAM, and NHI programmes will need a shared view of who or what can invoke the AI stack.

AI gateway consolidation will pressure organisations to normalise policy across human, NHI, and agent workflows. When the same control plane mediates user access, service credentials, and agent tool calls, policy drift becomes easier to spot but harder to excuse. Teams that keep these domains separate will spend more time reconciling logs than reducing risk.

The broader signal is that shadow AI is moving from a discovery problem to a lifecycle problem. Once AI tools and agents are registered, approved, and traced, the remaining work is offboarding, recertification, and exception management across a mixed identity estate.

For practitioners

• Define the MCP authorisation boundary Identify which tools require gateway enforcement, which require endpoint discovery, and which still need separate approval workflows before first use.
• Separate discovery from enforcement ownership Assign one team to inventory shadow AI and undeclared MCP servers, and a different team to run the runtime policy controls that stop risky calls.
• Standardise a single audit schema Make agent identity, model request, tool invocation, and approval outcome land in one traceable record for investigations and access reviews.
• Review where secrets live in agent workflows Check whether model and MCP access depend on shared keys, local device configuration, or hidden connectors that bypass central governance.

Key takeaways

• AI gateway design is becoming an identity governance problem because it now mediates models, tools, and agent actions in one place.
• Discovery and enforcement address different failure modes, so teams that separate them will miss either hidden assets or unsafe runtime behaviour.
• Unified audit is the control that turns AI activity into something IAM, PAM, and compliance teams can actually review and explain.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Flat RBAC: Flat RBAC is a role model where permissions are attached mainly at the tenant or organization level, with little or no resource-specific scoping. It works for simple access patterns but becomes brittle when customers need different permissions on different objects within the same tenant.

What's in the full article

TruFoundry's full comparison covers the operational detail this post intentionally leaves for the source:

• Exact MCP gateway policy hooks and approval flow configuration for production use
• Per-capability comparison of shadow AI discovery methods across MDM and traffic-based controls
• Implementation detail for model routing, fallbacks, and cost control in the gateway
• The full feature matrix covering audit, guardrails, and deployment options

👉 The full TruFoundry article includes the feature-by-feature breakdown and deployment distinctions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.