MCP server security gaps are widening as agent adoption grows

At a glance

What this is: MCP servers standardise how AI agents reach enterprise systems, but the key finding is that adoption is outpacing visibility, accountability, and runtime control.

Why it matters: IAM, NHI, and autonomous-governance teams need to treat MCP as an identity and access layer, because weak scoping and missing auditability expand blast radius across both machine and human workflows.

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.

👉 Read WitnessAI's analysis of MCP server security risks for enterprise AI agents

Context

MCP server security is the governance problem that appears when an AI agent can use a standard protocol to reach enterprise databases, APIs, and internal systems. The article argues that task-specific AI agents are spreading quickly, but the controls around those connections are still immature, which leaves identity, access, and accountability gaps that IAM teams cannot ignore.

For identity programmes, the issue is not simply that more tools are connected. It is that MCP turns agent access into a reusable enterprise pattern, which means scoping, audit, and attribution must work at runtime rather than only at provisioning time. That makes MCP a governance problem for both autonomous agents and the human identities that initiate them.

Key questions

Q: How should security teams govern MCP server access in enterprise AI environments?

A: Start with discovery, then scope, then enforcement. Security teams should inventory every MCP server, classify which identities can reach it, and limit tools to the smallest task-specific set. After that, add runtime policy controls that can block unsafe tool calls before execution and preserve attribution for audit and response.

Q: Why do MCP servers create risk for NHI and IAM programmes?

A: Because they turn agent connectivity into a reusable access layer that can expose databases, APIs, and internal systems through a single protocol. If permissions are broad or audit trails are weak, the identity programme loses control over who or what acted, what data moved, and whether the action was authorised.

Q: What breaks when AI agents use MCP without strong scope enforcement?

A: Least privilege breaks in practice because the agent can execute far more than the business task requires. When tool permissions are broad, the difference between legitimate use and abuse becomes narrow, and a normal workflow can become a data exposure or unauthorized action path without any obvious boundary crossing.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

How MCP server access expands the agent trust boundary

MCP acts as a standard connector between an AI application, the client that brokers requests, and the server that exposes tools and data. Once an agent can issue structured tool calls, it can read files, query databases, write records, and invoke APIs through a single protocol layer. That efficiency is also the security problem: every connected MCP server becomes part of the agent's trust boundary. If authentication, authorization, or input validation is weak, the protocol gives attackers a clean path to make privileged actions look routine.

Practical implication: inventory every MCP server and map which tools each one exposes before agents are allowed to use them.

Overprivileged MCP tools and missing scope enforcement

MCP does not enforce least privilege by default. Access depends on how each server is authenticated and authorised, so an agent can inherit capabilities that are broader than the task requires. That matters because the agent does not need to break a control to abuse it; it only needs a permissive configuration. In practice, the most dangerous failure mode is not a dramatic compromise but a normal workflow that silently includes database writes, admin commands, or other high-impact actions the programme never intended to allow.

Practical implication: align MCP tool permissions to task scope and review any server that exposes broad read-write or admin functions.

Why audit trails and human attribution break down

MCP creates a chain of action that often lacks native accountability. The agent may call a tool, receive a response, and trigger follow-on actions without a durable record that ties the event back to the human who initiated it. From an IAM and compliance perspective, that means the programme loses the evidence needed for review, rollback, and investigation. Once the action is complete, traditional after-the-fact logging may show what happened but not who should be accountable or how permissions should be revoked.

Practical implication: require immutable runtime logging that preserves the initiating identity, tool call sequence, and final action outcome.

Threat narrative

Attacker objective: The objective is to turn legitimate agent connectivity into unauthorised data access, unauthorised action, and wider operational exposure across enterprise systems.

1. Entry occurs when an AI agent connects to an MCP server with access to enterprise data, APIs, or internal tools through a legitimate integration path.
2. Credential or instruction abuse happens when malicious tool content, overprivileged permissions, or compromised server responses cause the agent to execute unintended actions.
3. Impact follows when data is exfiltrated, records are modified, transactions are triggered, or one compromised agent propagates risk across additional agent connections.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Visibility debt is the core MCP governance failure: MCP risk starts before any exploit because enterprises often cannot see which servers exist, which agents use them, or which identities initiated the action. That is not a monitoring nuisance, it is a governance failure that prevents scoping, review, and attribution from functioning as designed. In OWASP NHI terms, the environment has already lost the ability to govern the non-human identity surface. Practitioners should treat undiscovered MCP connections as unmanaged identity infrastructure, not as a tooling side issue.

MCP is where least privilege becomes operational, not theoretical: A task-specific agent can inherit database, API, and workflow permissions far beyond the task boundary unless scope is enforced at the server layer. That creates a named failure mode we would call tool-scope overhang, where the accessible toolset outlives the actual business purpose of the agent session. ZT-NIST-207 and OWASP-NHI both point toward the same conclusion: if scope is not runtime-bound, the identity programme is already oversized. Practitioners should re-evaluate every agent connection that depends on broad server authorisation.

Human accountability cannot be inferred from agent action logs: The article's strongest operational point is that MCP activity is hard to tie back to the initiating human identity once actions move through chained tool calls. That means the common IAM assumption that an authorised user can be held accountable for downstream machine action breaks down quickly in multi-agent flows. The implication is broader than logging. Security, legal, and compliance teams need to recognise that delegated execution can dissolve the evidence chain they rely on for review and response.

Unified governance now has to cover human and autonomous access together: MCP collapses the separation between human use of AI and machine execution through AI, because both can touch the same backend systems through the same protocol. That is why isolated policy islands fail. A single control framework that spans human identity, NHI, and autonomous agents becomes the only durable model for this layer. Practitioners should align access governance, runtime control, and audit strategy across all three identity types instead of maintaining separate rulesets for each.

Shadow AI in MCP form creates unreviewed identity pathways: Untracked MCP servers turn ad hoc agent integrations into durable access paths with no security review, no inventory, and no policy baseline. This is not simply sprawl, it is identity drift, because every ungoverned connector expands the set of identities that can act inside enterprise systems. The practical takeaway is that discovery has to precede enforcement, otherwise policy will always lag the actual attack surface.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the same research.
• For a broader identity lens on this attack surface, see 52 NHI Breaches Analysis and the control patterns it extracts from real-world incidents.

What this signals

Tool-scope overhang: MCP programs fail when task intent and tool permissions drift apart, because the agent can retain capabilities long after the business need ends. Enterprises that are adding task-specific agents need to assume that discovery and scoping are now continuous governance activities, not one-time onboarding steps.

The next programme-level question is whether your current controls can connect a human initiator to an agent action without relying on post-incident reconstruction. If they cannot, then the issue is not just visibility. It is that accountability, access review, and rollback are all being asked to operate after the fact, which is too late for agent-driven systems.

For practitioners

• Build a complete MCP inventory first Catalog every MCP server, every connected agent, and every backend system they can touch. Include developer-built and shadow deployments so access review starts from reality rather than procurement records.
• Map tool scope to task scope Review each MCP server for read, write, and admin exposure, then remove any capability that is not required for the agent's actual business purpose. Broad tool sets should be treated as standing privilege.
• Require runtime attribution for every agent action Preserve the initiating human identity, tool-call sequence, and final action outcome in immutable logs so security and compliance teams can reconstruct what happened without relying on post-hoc inference.
• Insert in-path policy enforcement before execution Use gateway-style controls that can inspect tool calls and responses in real time, block unsafe actions before they complete, and route borderline cases for review instead of allowing silent execution.
• Unify human and agent governance controls Apply one governance model across human users, service identities, and AI agents so policy drift does not accumulate across separate admin processes or tool-specific exceptions.

Key takeaways

• MCP servers are becoming the access layer for agentic AI, which makes them an identity governance problem as much as a technical integration layer.
• The clearest risk is not hidden complexity but weak scope enforcement, missing auditability, and unmanaged server sprawl.
• Security teams should inventory, scope, and attribute MCP activity before agents are allowed to scale into production workflows.

Key terms

• Model Context Protocol: A standard that lets AI applications connect to external tools and data sources through a shared interface. In practice, it turns agent access into a reusable integration layer, which means identity, permission scoping, and auditability become security requirements rather than implementation details.
• MCP server: The component that exposes tools, data, or actions to an AI agent through the Model Context Protocol. It becomes part of the enterprise trust boundary, because any weakness in its authentication, authorization, or response handling can expand what the agent can do inside connected systems.
• Shadow AI: AI systems or agent connections that exist without formal approval, inventory, or governance. For MCP environments, shadow AI matters because unreviewed servers create hidden access paths that bypass normal identity controls, making discovery the first prerequisite for control.
• Runtime policy enforcement: Controls that inspect an action while it is happening and can allow, warn, block, or route it before execution completes. In agentic environments, this is the difference between monitoring behaviour after the fact and preventing an unsafe tool call from reaching production systems.

Deepen your knowledge

MCP server governance, agent scoping, and runtime attribution are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic AI access paths, it is worth exploring.

This post draws on content published by WitnessAI: Model Context Protocol (MCP) servers and enterprise AI security risks. Read the original.