MCP gateway governance needs identity context, not just routing

At a glance

What this is: This is an analysis of MCP gateway governance that says routing and authentication are not enough because AI agents still need identity context, least-privilege tool controls, and attributable lifecycle management.

Why it matters: It matters because IAM, PAM, and NHI programmes have to govern agent actions as identities, not just network traffic, if they want defensible access, review, and offboarding controls.

Context

MCP gateways are control planes for AI agent access, but they do not solve the identity problem that starts once an agent is inside the enterprise toolchain. In practical terms, routing can tell you where a request goes, but it does not tell you who is really behind the action or whether the action should be allowed at all.

For AI agents, the governance gap shows up in three places: tool-level authorisation, lifecycle management, and audit attribution. If the programme only treats MCP as a protocol boundary, the organisation ends up with machine-speed access that is broader than the human owner, harder to review, and difficult to revoke cleanly.

Key questions

Q: What breaks when MCP governance stops at authentication and routing?

A: Policy becomes too coarse to control what an agent can actually do inside a system. The organisation may know the gateway accepted the request, but it still cannot prove that the action was permitted, attributable, or within the human owner's scope.

Q: Why do AI agent runtimes create more governance risk than ordinary service accounts?

A: AI agent runtimes can combine decision-making, tool use, and secret access in one execution path, so a single trust failure can cause data exposure and operational change. Unlike ordinary service accounts, agents may validate one action and perform another at runtime. That makes blast-radius control and lifecycle governance more important than simple credential issuance.

Q: How do security teams know whether an MCP gateway is actually working?

A: Look for three signals: tool-level policy enforcement, before-execution blocking or approval, and a complete audit trail tied to a real owner. If any of those are missing, the gateway is providing connectivity control, not governance control.

Q: What should organisations do when an AI agent is no longer needed?

A: They should revoke the agent’s access, retire its credentials and confirm that its downstream integrations are disabled before the business use case is closed. If the identity stays active after the task ends, the organisation has created lingering authority with no live business owner behind it.

Technical breakdown

Why MCP gateways are not enough for agent governance

An MCP gateway sits between AI clients and MCP servers and can authenticate, inspect, and route tool calls. That creates an enforcement point, but not a full governance model. The missing piece is identity context: the gateway sees a request path, yet it does not inherently know the human owner, the business role, or the intended scope of the agent. Without that context, policy becomes coarse and the resulting access model tends to over-permit rather than constrain. The technical issue is not visibility alone. It is that the gateway must be tied to identity data and task-level authorisation if it is to govern actions rather than merely transport them.

Practical implication: treat the gateway as an enforcement layer, not the source of truth for identity or entitlement design.

Tool-level authorisation versus server-level access

Server-level access control says whether an agent can reach a given MCP server. Tool-level authorisation says which functions inside that server the agent may call, and under what conditions. That distinction matters because one server can expose both low-risk and high-risk operations, such as read-only queries and state-changing actions. If policy stops at the server boundary, the organisation either blocks useful automation or grants more access than the job requires. Real governance needs policy granularity that maps tools, actions, and data sensitivity to the role, persona, or delegated purpose behind the agent.

Practical implication: design access policies at the tool and action level, not just at the server allowlist level.

Audit trails and identity lifecycle for AI agents

Agent governance fails when activity is logged without a stable identity chain. An action that cannot be tied back to a human owner, a non-human identity, and a lifecycle state is hard to investigate, certify, or revoke. That is why agent lifecycle matters as much as access control. Provisioning, review, and deprovisioning need to follow the same governance logic used for other identities, otherwise access persists after role change or departure. For regulated environments, this is where MCP shifts from a technical integration problem to an identity assurance problem.

Practical implication: connect agent onboarding, access review, and offboarding to the same identity lifecycle process used for other governed identities.

Threat narrative

Attacker objective: The objective is to use agent access to perform actions inside enterprise systems beyond the intended human scope while avoiding clear attribution and durable oversight.

1. Entry occurs when an AI agent is granted access to enterprise systems through an MCP gateway and can begin making tool calls inside business applications.
2. Escalation happens when server-level permissions are too broad and the agent can invoke high-risk tools or chain multiple actions beyond the intended human scope.
3. Impact follows when those actions execute without a complete, attributable audit trail, leaving the organisation unable to prove what happened or revoke access cleanly.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity context is the control boundary, not the MCP gateway itself: A gateway can enforce transport and inspection, but it cannot determine delegated intent on its own. The real governance question is whether the agent is acting within the human owner's authority, not whether the request passed through a proxy. Practitioners should stop treating protocol mediation as identity governance.

Tool-level scope is the decisive control for agentic access: Server-level allow or deny decisions are too blunt for environments where one MCP server exposes both benign and destructive functions. That creates an access mismatch between what a person should do and what an agent can technically reach. The implication is that entitlement design has to move from server boundaries to action boundaries.

Lifecycle governance now extends to AI agents as first-class identities: Agents that outlive the employee or contractor behind them create orphaned machine authority. That is not a routing defect, it is a lifecycle failure. Offboarding, review, and change management must include the agent because the agent can continue acting after the human relationship ends.

Human attribution is a governance requirement, not a logging feature: If an enterprise cannot tie each tool call back to a real person and a specific authorisation state, it has no defensible audit model for agent activity. That breaks incident review, compliance evidence, and accountability. The practitioner conclusion is simple: attribution must be designed into the control plane from the start.

Identity blast radius is the right concept for MCP programmes: Once an agent can chain tool calls across systems, the question is no longer only whether access was allowed. It is how far one delegated identity can move before governance regains control. Teams should measure and constrain blast radius across human, NHI, and agentic identities, not just network paths.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Identity context is now the control that separates useful agent automation from unmanaged delegated access: MCP gateways can enforce traffic flow, but they cannot replace the identity model that tells the organisation who owns the agent, what it may do, and when it must be removed. Programmes that leave that context outside the gateway will keep accumulating unowned access paths.

Governance programmes should expect tool-level scoping to become the default requirement for agent oversight: Server-level allowlists are too blunt when a single MCP endpoint exposes both low-risk reads and high-risk writes. The decision point shifts to action-level policy, where entitlement design can actually express business role boundaries.

7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey: that uncertainty is a warning sign that audit, attribution, and control boundaries are already too weak for operational AI governance.

For practitioners

• Define tool-level policy boundaries Map each MCP server to the specific tools, actions, and data domains it exposes, then grant access by role or persona instead of by server alone.
• Bind each agent to an owner Require every agent to carry a human owner, a business purpose, and a lifecycle state so review and offboarding can follow the same governance path as other identities.
• Enforce inline decisioning before execution Block or approve tool calls before they run, rather than relying on logs after the fact, so policy can stop harmful actions at machine speed.
• Preserve attributable audit chains Capture every approved and denied tool call with timestamps and the identity chain that initiated it, so investigations can reconstruct who acted and under what authority.
• Reduce standing access with task-scoped issuance Use just-in-time access for sensitive agent operations so the agent receives only the permissions needed for the current task and not a persistent privilege set.

Key takeaways

• MCP gateways improve enforcement, but they do not by themselves solve identity ownership, least privilege, or offboarding for AI agents.
• When tool-level scope is broader than the human owner's job, governance breaks at the point of delegated action rather than at the login layer.
• Auditability and lifecycle control are the controls that turn MCP from a connectivity layer into a defensible identity programme.

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.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Identity Attribution: Identity attribution is the ability to determine which entity performed an action and under what authority. For AI agents, it requires separate identities, structured logs, and traceable decision records so investigations can distinguish human intent from autonomous execution.
• Agent Lifecycle Management: The process of provisioning, governing, updating, and retiring an AI agent or other non-human identity. It includes credential issuance, permission changes, logging, rotation, and offboarding. Without lifecycle control, agents can retain access after their business purpose ends, creating persistent risk.

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 building or maturing an IAM programme, it is worth exploring.