MCP gateways are becoming the control plane for AI tool access

At a glance

What this is: This article explains why MCP gateways are becoming the control plane for AI tool access and why tool-level governance is needed when agents discover and call external systems.

Why it matters: It matters because IAM and AI security teams need controls that bind agent identity, tool policy, and auditability before agentic tool calls reach internal systems.

Context

MCP is a protocol problem only when it is treated as a transport problem. In practice, the security issue is that AI agents can discover and invoke tools dynamically, which means the control point must sit at the tool layer rather than only at the network or application boundary.

For identity and governance teams, that changes the unit of control from host, port, or URL to agent, tool, and delegated session. If an organisation cannot inventory shadow MCP connections or attribute tool calls back to a human identity, it does not have workable oversight of agentic access.

This is an NHI governance issue because MCP servers and agent sessions behave like non-human identities with delegated authority. The article’s starting position is typical for organisations adopting agentic tooling before governance catches up.

Key questions

Q: What breaks when AI tools are exposed through loosely governed MCP servers?

A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.

Q: Why do shadow MCP connections create security risk for AI tool access?

A: They create risk because tool access can exist before procurement, installation, or review records show the connection. That means an agent may reach internal systems through an authorised-looking pathway that was never formally approved, making accountability and containment much harder.

Q: What should security teams do when AI agents need access to tools and data?

A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.

Q: What should identity teams do when agent actions must be reviewed after an incident?

A: They should reconstruct the decision chain, not just the runtime trail. That means correlating delegation, intent, policy decision, tool execution, and outcome so the team can prove what authority existed at the moment of action and whether any rollback or revocation is needed.

Technical breakdown

Why MCP gateways change the control plane for AI tool access

MCP creates a standard way for AI agents to discover tools and call external systems, which makes the tool itself the policy boundary. A gateway placed inline can authenticate the session, restrict discovery, evaluate each tool call against policy, and record what happened before the action reaches the server. That is materially different from packet filtering, which sees traffic but not the intent behind the call. It also differs from generic API mediation because the gateway can govern tool discovery, not just request execution.

Practical implication: Treat MCP tool discovery and invocation as a governed identity plane, not as a networking exception.

How pre-execution policy enforcement works in MCP gateways

A governance-grade gateway does more than allow or block traffic. It can evaluate the agent’s session context, the tool being selected, and the intent implied by the request before the call executes. That matters because risky behaviour often appears as a sequence of legitimate actions rather than a single obviously malicious call. The gateway can therefore warn, route, or block based on policy. This shifts enforcement earlier in the chain, where it can prevent an agent from reaching a sensitive server at all.

Practical implication: Use pre-execution decisions to stop risky tool sequences before they become irreversible server-side actions.

Why attributed audit trails matter for delegated agent activity

MCP activity is hard to govern if the organisation cannot trace which human authority stood behind a tool call. The gateway’s audit trail should capture the user, the tool, the parameters, the server, the policy decision, and the outcome, then preserve the delegation chain through any sub-agents or background workers. That gives security, audit, and compliance teams one record instead of stitched-together logs from separate systems. It also reduces the chance that shared or anonymous service identities obscure accountability.

Practical implication: Bind every agent call to a human-backed delegation chain so investigations and compliance reviews have a defensible source of truth.

Threat narrative

Attacker objective: Gain tool-level access through agent-driven connections that bypass normal inventory and oversight processes.

1. Entry occurs when an AI-enabled IDE or desktop client is configured to connect to MCP servers outside a managed rollout, creating a connection the security team may not inventory.
2. Credential or authority is then exercised through the agent session, which can reach internal tools before defenders know the connection exists.
3. Impact follows when the agent invokes approved or unapproved tools with delegated access, creating unmanaged exposure, hidden actions, or data movement beyond intended oversight.

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.

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

MCP gateways are becoming the practical enforcement point for agentic tool access. The control problem is no longer whether an agent can send traffic, but whether it should be allowed to discover, select, and invoke a specific tool at all. That makes the gateway the place where identity, intent, and authorisation converge. Practitioners should treat the gateway as part of the identity control stack, not as an add-on proxy.

Shadow MCP connections create governance debt before they create visible risk. If AI-enabled IDEs and desktop clients can connect outside company-managed rollout processes, the organisation may not know the tool inventory it is supposed to govern. That weakens recertification, exception handling, and incident attribution because the authorised state is never fully known. The implication is that discovery becomes a prerequisite control, not a monitoring enhancement.

Human attribution is the missing governance primitive for delegated agent activity. A tool call without a human-backed delegation chain cannot be meaningfully reviewed in a compliance or incident context. This is not just about logging volume. It is about proving which authority exercised the action, which is the basis for accountability across NHI, autonomous, and human programmes. Practitioners should require attributable action records before scaling agent deployment.

Tool-level policy is the right control granularity for MCP because server-level decisions are too coarse. A source-control integration may expose safe and unsafe actions on the same server, and security teams need different outcomes for create, merge, and delete operations. That is a named governance gap: tool-level authorisation drift. When access is governed only at the server boundary, the real risk surface remains unsegmented. Teams should align policy to the action, not just the connector.

Assumption collapse: access review processes were designed for access that persists long enough to review. That assumption fails when an agent can obtain, use, and discard access through dynamic tool selection in the same working session. The implication is that governance must move from after-the-fact review to pre-execution control and continuous attribution across the delegation chain.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 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.
• Read next: AI Agent Authorisation Guide

What this signals

Tool-level governance is now the practical boundary for agentic AI access. Security teams that still think about MCP in terms of network paths will miss the real control point: which tool an agent can discover, select, and invoke. The programme implication is that discovery, authorisation, and audit must move together, or the organisation will keep finding access paths after agents have already used them.

Shadow MCP activity is an inventory problem before it is a detection problem. AI-enabled developer tools and desktop clients can create approved-looking connections outside managed rollout, leaving defenders to discover the connection after the agent is already active. That is why attributed audit trails and discovery at the control layer matter more than post-event log correlation.

Access review processes assume access lasts long enough to be reviewed; autonomous and semi-autonomous tool use compresses that window to the point where review alone is too late. 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. The programme response is to move governance upstream to issuance and invocation time, not to rely on retrospective certification.

For practitioners

• Define tool-level policy boundaries Map each MCP server to the exact actions an agent may invoke, then separate safe operations from destructive or data-sensitive ones at the tool level rather than the server level.
• Inventory shadow MCP connections Scan AI-enabled IDEs, desktop clients, and local agent frameworks for unmanaged MCP server connections, then reconcile them against approved rollout records and ownership data.
• Bind sessions to human identity Require every agent session to inherit a traceable human identity through the IdP and preserve that chain through any sub-agent or background worker involved in the call.
• Enforce pre-execution guardrails Use allow, warn, route, and block decisions before tool invocation so risky sequences stop at the gateway instead of reaching the server.
• Protect sensitive tool parameters Tokenize credentials, source code, and other sensitive values before they leave the trust boundary, and restore them only where authorised.

Key takeaways

• MCP gateways turn AI tool access into a governed identity problem by putting policy, discovery, and audit in one control point.
• The biggest operational gap is not only unauthorized traffic, but unmanaged tool discovery and delegated access that security teams cannot reliably inventory.
• Practitioners need pre-execution enforcement and attributed audit trails before scaling agentic AI into production environments.

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 MCP Connection: An unreviewed or unsanctioned Model Context Protocol connection created outside formal security oversight. These connections are risky because they can bypass approval, expand agent access, and create blind spots that prevent teams from understanding how data and tools are being used.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Tool-Level Policy: Tool-level policy is permissioning that evaluates a specific action, such as a repository delete or data query, rather than allowing or denying an entire server. This is the right control grain for agentic systems because risk often lives in one tool, not the whole integration.

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.