MCP server security gaps are widening as agent adoption grows

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WitnessAI's blog post: MCP servers are expanding the reach of enterprise AI agents, but the security model around visibility, attribution and runtime control is not keeping up.

Why it matters: IAM, PAM and identity governance teams need to treat MCP as an access layer problem, because autonomous tool use changes how permissions, accountability and auditability must be enforced.

By the numbers:

• 40% of enterprise apps are expected to feature task-specific AI agents in 2026.
• 30% of vendors are expected to launch their own MCP servers.

Context

MCP, or Model Context Protocol, is the adapter layer that lets AI agents call enterprise tools and data sources through a standard interface. In this article, the primary governance gap is not the protocol itself but the access model it creates, because agents can already act across systems faster than most identity and audit controls can track.

WitnessAI argues that this matters because MCP servers are turning agentic AI into an operational access plane rather than a chat interface. That shifts the problem from simple prompt safety to permission scope, accountability, third-party trust and control of machine-initiated actions.

The central question for IAM and security teams is whether existing governance can still answer who authorised an action, what the agent could touch, and whether unsafe tool calls can be stopped before execution. The article treats today’s visibility and control failures as already present, not hypothetical.

Key questions

Q: What is the biggest governance failure when MCP servers are added to enterprise AI workflows?

A: The biggest failure is assuming that a standard protocol creates safe access by itself. MCP can standardise tool use, but it does not replace inventory, privilege scoping, attribution or runtime intervention. If teams cannot see which servers are active and which actions each agent can take, governance becomes reactive instead of controlled.

Q: Why do MCP servers increase risk even when the underlying model is not compromised?

A: Because risk often sits in the access path, not the model. An agent using an overprivileged or third-party MCP server can read data, trigger workflows or modify records through a path that looks legitimate at the protocol level. That makes permission scope and server trust the practical control points.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should security teams decide whether to allow third-party MCP servers?

A: Treat them like privileged integrations rather than ordinary plugins. Teams should review what systems the server can reach, whether its code has been assessed, how access can be revoked, and what audit evidence will exist if the server is used in a consequential workflow.

Technical breakdown

How MCP servers mediate agent access to enterprise systems

MCP servers sit between an AI agent and the enterprise resources it needs to use, such as databases, APIs and internal tools. The protocol standardises tool discovery and tool calls so a client can ask for data or actions in a structured way rather than through custom integrations. That efficiency is also the risk surface: once an agent is allowed to call multiple servers, the protocol becomes a general-purpose action layer, not just a data retrieval path. The security model therefore depends on external controls for authentication, authorisation, scoping and logging.

Practical implication: treat MCP as an access plane and review every connected server as a governed identity path.

Why visibility and attribution fail in MCP-driven workflows

MCP sessions can carry sensitive data, tool parameters and responses across internal systems without the same observability stack that protects conventional web traffic. The article notes that traditional DLP and some gateway layers may not reliably interpret the conversational and JSON-based payloads moving between agents and servers. It also highlights a second gap: MCP has no native mechanism for tying a consequential agent action back to the human who initiated it. That leaves audit, rollback and accountability outside the protocol itself.

Practical implication: require inventory, runtime telemetry and immutable action attribution before allowing MCP access in production.

How overprivilege and supply-chain exposure emerge in MCP ecosystems

MCP does not enforce scope by default, so an agent’s real access depends on how each server is authenticated and authorised. That means a task-scoped agent can still inherit broad database or infrastructure privileges if the server is misconfigured. The risk expands further when teams connect to third-party servers they have not reviewed, because the trust boundary now includes code outside the enterprise. In multi-agent environments, one compromised tool response can also trigger escalation across other agents, turning a single weak link into a broader control failure.

Practical implication: constrain each MCP connection to the narrowest possible server scope and review third-party server trust before onboarding.

Threat narrative

Attacker objective: The attacker’s objective is to use the agent’s trusted MCP access path to exfiltrate data, trigger unauthorised actions or widen control across enterprise systems.

1. Entry occurs when an agent connects to an MCP server that exposes enterprise tools and data through a standardised protocol, often with incomplete inventory or review.
2. Credential and access abuse follow when overprivileged server configuration or malicious tool content lets the agent reach data, APIs or internal commands beyond the intended task scope.
3. Escalation happens when compromised tool responses or shared multi-agent connections extend that access into additional systems or agents.
4. Impact is unauthorised data exposure, unsafe actions, privilege escalation or shadow AI activity that security teams cannot easily attribute or roll back.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• 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 creates an identity governance problem, not just an AI integration problem. The article is right to frame MCP servers as the connective layer for enterprise agentic AI because that is where permissions, auditability and accountability converge. Once an agent can invoke tools directly, the control question is no longer whether the model is safe to prompt but whether the access path itself is governed as a production identity surface. Practitioners should treat MCP as part of the identity plane, not a peripheral developer convenience.

Visibility is the named concept that determines whether MCP governance is real or cosmetic. Without a current inventory of servers, real-time observation of agent actions and attribution of every action to a human identity, policy is effectively blind. This is where NHI governance and AI governance meet: the enterprise is trying to control runtime access that may have been created outside conventional IAM workflows. The practical conclusion is simple, if the access path cannot be seen end to end, it cannot be trusted end to end.

Overprivileged NHI patterns reappear in MCP form unless scope is enforced at runtime. The article shows that MCP itself does not define permission boundaries, so the burden falls on the surrounding governance stack. That means the same failure modes seen in service account sprawl and long-lived secrets can now emerge through agent tool access, except the blast radius is faster because agents act at machine speed. Practitioners should re-evaluate whether their least-privilege model assumes a human reviewer is present when, in practice, the action is already underway.

Third-party MCP server trust is becoming the new supply-chain boundary for agentic AI. When enterprises connect to unreviewed servers, they are extending trust to code they do not control and often do not fully understand. That is a governance problem as much as a security one, because ownership, revocation and change control are now spread across vendors, engineering teams and AI operators. The field needs to treat MCP onboarding like privileged third-party access, not like a routine integration decision.

Runtime intervention is the difference between auditing agent behaviour and governing it. The article’s emphasis on blocking unsafe actions before they execute is important because post-event logs do not restore control once a tool call has already altered data or triggered a workflow. The broader implication is that identity governance for agentic systems must move closer to issuance and execution time, where decisions can still be denied, redirected or constrained. Practitioners should design for prevention at the point of action, not retrospective explanation.

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.
• Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
• Read next: Agentic AI Identity Guide

What this signals

MCP visibility is now a governance prerequisite, not an optional hardening step. As agent connectivity spreads, security teams need a live inventory of server connections, tool scopes and ownership before they can claim meaningful control. The article’s warning is that once agent activity is untracked, policy drift becomes invisible and revocation decisions arrive too late.

Agent access reviews will need to shift from human-cycle assumptions to runtime enforcement. AI systems do not wait for quarterly certification windows, so a privilege that exists only for a short task may never be reviewed in a meaningful way. That pushes practitioners toward issuance-time controls, inline blocking and action-level attribution rather than retrospective review alone.

Intent-aware policy is the named concept that matters here. Simple allow or deny rules cannot distinguish a legitimate analytics request from an exfiltration attempt when both look like tool calls. Teams should evaluate whether their MCP governance can interpret context, constrain behaviour in-flight and tie every action back to a person or owning workflow.

For practitioners

• Inventory every MCP server connection Build a complete register of all MCP servers, including those created by engineering teams or embedded in developer tooling, and keep it current as part of identity governance.
• Bind every agent action to a human identity Require immutable attribution for each tool call and store enough runtime context to trace multi-agent chains back to the initiating person.
• Enforce runtime blocking for unsafe tool calls Inspect tool-call sequences, parameters and server responses in-line so privilege escalation or unauthorised actions can be stopped before execution.
• Limit each MCP server to narrow task scope Review server authentication and authorisation so an agent cannot inherit broad database, API or infrastructure privileges beyond the current task.
• Treat third-party MCP servers as privileged access Apply review, approval and offboarding discipline to external MCP servers before they are connected to enterprise data or workflows.

Key takeaways

• MCP servers extend enterprise AI from text generation into direct system access, which makes them an identity and governance problem as much as a platform choice.
• The main exposure is not just adoption scale but control failure, with weak visibility, incomplete attribution and overprivileged tool access creating a widening gap.
• Teams that cannot inventory servers, scope access and block unsafe actions at runtime are unlikely to govern agentic AI safely as MCP adoption grows.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

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.