MCP gateways are becoming the control plane for AI tool access

At a glance

What this is: This article argues that MCP gateways are the control layer for AI agent tool access, with the key finding that governance must move from network filtering to tool-level policy and attributed audit trails.

Why it matters: That matters because IAM and security teams need enforceable controls for MCP-connected agents, hidden tool discovery, and delegated actions across human, NHI, and agentic identity programmes.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read WitnessAI's explanation of MCP gateway governance for AI agent tool access

Context

Model Context Protocol, or MCP, gives AI agents a standard way to discover and call tools and data sources. The governance problem is not the protocol itself, but the fact that tool discovery and invocation now happen outside the visibility model most IAM and security programmes were built around.

In AI-enabled IDEs and desktop clients, MCP connections can be configured outside a company-managed rollout, which makes them difficult to inventory through procurement or software records. That leaves a gap between what teams think is approved and what agents can actually reach, especially when actions are delegated from a human user through an agent chain.

For identity programmes, the core question is whether access is being governed at the point of tool use. If policy cannot see the server, the tool, and the actor behind the call, then the organisation is relying on incomplete inventory and post-event review rather than enforceable runtime control.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do MCP connectors create new IAM and NHI governance risks?

A: MCP connectors create risk because they turn a user-facing integration into a reusable access path that may outlive the original request context. If the connector can call multiple tools or retrieve metadata without continuous revalidation, it behaves like standing privilege. That makes it an NHI governance issue as much as an AI integration issue.

Q: What breaks when organisations rely on packet controls for MCP governance?

A: Packet controls can see transport, but they cannot evaluate tool semantics, intent, or the delegation chain behind an agent action. As a result, they miss shadow connections, cannot distinguish legitimate from risky tool sequences, and leave audit evidence too thin for compliance or incident review.

Q: How do security teams prove accountability for agent actions through MCP?

A: They need structured audit records that tie each tool invocation back to the human who exercised the authority, along with the tool name, parameters, server, and policy decision. Without that chain, review teams cannot reconstruct what happened or who authorised it.

Technical breakdown

How an MCP gateway changes tool-level authorisation

An MCP gateway sits between an agent and the MCP servers it calls, intercepting discovery and invocation traffic before the action reaches the server. That placement lets the gateway authenticate the session, map it to a human identity, and apply policy at the individual tool level rather than the server level. In practice, this is closer to runtime authorisation than network filtering. The governance unit becomes the specific tool action, not the endpoint or the protocol connection.

Practical implication: teams need policy models that evaluate individual tools, roles, and session context before execution.

Why tool discovery creates a new exposure surface

MCP discovery exposes the list of available servers and tools to the agent, which means governance starts before execution. If an unapproved server is visible, the agent may reason over capabilities the business never intended to expose. Tool descriptions also matter because they become part of the model’s context, so hidden instructions or poisoned descriptions can influence downstream behaviour without obvious user visibility. That makes discovery a control point, not just a convenience feature.

Practical implication: security teams should inspect discovery responses and maintain an allow list of approved servers and tools.

Data protection and audit trails in MCP governance

Governance-grade MCP gateways do more than block calls. They can tokenize sensitive values in tool parameters before they leave the trust boundary, then restore them only where authorised, which reduces exposure while preserving workflow continuity. They also create human-attributed audit trails that record who invoked which tool, with what parameters, against which server, and what policy decision occurred. For regulated environments, that is the difference between observing agent activity and being able to prove control over it.

Practical implication: compliance teams should require tokenization, attribution, and immutable audit records for every tool call.

Threat narrative

Attacker objective: The objective is to get an agent to reach and use internal tools or data sources before governance controls can block, route, or attribute the action.

1. Entry occurs when an AI-enabled IDE or desktop client connects to an MCP server outside the company-managed rollout, creating a shadow connection the security team may not yet know exists.
2. Escalation follows when the agent discovers additional tools or servers and can reason over capabilities that were never formally approved, including descriptions that may shape tool selection.
3. Impact occurs when the agent invokes sensitive tools or transmits regulated data without a governed runtime check, leaving the organisation with limited visibility and weak attribution.

Breaches seen in the wild

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

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 gateways are becoming the practical control plane for agentic tool access. The article makes clear that the governance problem is not whether agents can connect, but whether those connections are discovered, authorised, and attributed at the tool level. That shifts MCP from a developer protocol into an identity enforcement problem. For practitioners, the control boundary has to move to the point where the tool call is made.

Legacy packet-centric and keyword-based controls do not map cleanly to agent intent. They can see traffic, but they cannot determine whether a tool call is legitimate, risky, or part of a harmful sequence. That creates a blind spot for both NHI governance and AI agent oversight. The named concept here is tool-level governance gap: the distance between network visibility and enforceable policy at the specific action the agent is taking.

Human-attributed audit trails are now a governance requirement, not a reporting luxury. The article’s delegation-chain model is important because agent activity often inherits human authority while obscuring the downstream sequence of actions. Identity teams need to treat the user, the agent, and the sub-agent as one attribution chain for review and evidence. The practitioner implication is that accountability must follow the authority path, not the network path.

Shadow MCP connections reveal a broader inventory problem across AI-enabled workstations. If agents can connect outside company-managed rollout paths, then traditional procurement-led inventories will always lag actual use. That is an NHI issue as much as an AI issue, because unmanaged connections behave like unrecorded machine identities with effective access. Teams should assume that discovery, not approval, is the first gap to close.

Governance for MCP will increasingly resemble the way organisations manage high-risk NHI access. Tool allow lists, runtime enforcement, tokenisation, and auditability are the same controls identity teams already use for privileged machine activity, now applied to agent behaviour. The implication is not that MCP needs a brand-new discipline, but that agentic access must be folded into existing NHI and IAM governance models before scale makes exceptions unmanageable.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Top 10 NHI Issues helps teams connect agent governance back to broader non-human identity controls and lifecycle discipline.

What this signals

MCP governance will be judged by discovery and attribution, not by gateway placement alone. If teams cannot inventory connections made from desktop clients and AI-enabled IDEs, policy enforcement arrives too late to matter. The operational signal is whether approved and actual access converge before agents reach production scale.

Tool-level access control is now the right abstraction for agentic AI. The old model of coarse service-level permissions does not fit an environment where one tool can create a pull request, merge code, or delete a repository. That is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs remains relevant: lifecycle control must now reach agent sessions, not just service accounts.

Shadow MCP activity is the named concept teams should watch. It describes approved or unapproved tool connections that exist outside formal rollout and procurement records, yet still influence enterprise data and execution paths. The more AI development shifts into local clients and side-loaded connectors, the more this becomes a board-level governance signal rather than an engineering curiosity.

For practitioners

• Inventory shadow MCP connections Discover MCP servers and tools used in AI-enabled IDEs, desktop clients, and local agent frameworks, then reconcile them against approved procurement records and identity policies.
• Enforce tool-level policy before execution Apply allow, warn, route, and block decisions at the individual tool level so risky actions are stopped before they reach the server.
• Bind every agent session to a human identity Use identity-integrated authentication so downstream calls inherit a clear delegation chain from user to agent to sub-agent.
• Inspect tool descriptions during discovery Review descriptions returned in MCP discovery responses before they enter the model’s context, because hidden instructions can steer agent behaviour.
• Tokenize sensitive parameters in transit Redact PII, credentials, and source code before they leave the gateway, then restore them only where authorised and log the tokenized value in the audit trail.

Key takeaways

• MCP moves AI governance into the tool-call layer, where identity, intent, and policy have to meet before execution.
• Discovery gaps and weak attribution are the main reasons legacy controls miss agent activity, especially in unmanaged desktop and IDE workflows.
• Enterprises that want defensible AI adoption need tool-level policy, pre-execution enforcement, and human-attributed audit trails now, not after scale arrives.

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 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.
• Shadow Mcp Activity: Shadow MCP activity is MCP use that exists outside formal inventory, approval, or rollout processes. It often appears in local IDEs, desktop clients, or agent frameworks and creates unmanaged access paths that traditional procurement or software records do not capture.
• 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.

What's in the full article

WitnessAI's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how the MCP gateway authenticates sessions and binds them to human identity.
• Specific examples of tool-level policy decisions such as allow, warn, block, and route.
• Details on how tool description inspection reduces exposure to prompt or tool poisoning.
• How tokenisation and human-attributed audit trails support compliance evidence and incident review.

👉 The full WitnessAI article shows the gateway flow, policy controls, and audit trail model in more operational detail.

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 or identity governance programme, it is worth exploring.