MCP security gaps are exposing enterprise AI workloads

At a glance

What this is: This analysis argues that MCP is accelerating AI-to-tool connectivity faster than enterprise security controls can provide native authorization, visibility, and safe runtime oversight.

Why it matters: It matters because practitioners now have to govern AI assistants and workloads that can reach sensitive systems through standardized connectors without relying on traditional perimeter or review-cycle assumptions.

By the numbers:

• A March 2025 update added OAuth 2.1 based authorization, but thousands of MCP servers are already deployed without it.
• Aqua securely protects over 500 of the world’s largest enterprises.

👉 Read Aqua Security's analysis of MCP security for agentic AI workloads

Context

Model Context Protocol, or MCP, is the interface layer that lets AI applications connect to tools, data sources, and hosted services. The identity problem is that standardisation makes integration easier before governance has caught up, so access decisions, telemetry, and trust boundaries are often weaker than the speed of deployment would suggest. For practitioners, that turns MCP security into an IAM and workload identity issue, not just an AI engineering concern.

In enterprise environments, MCP changes the control plane for AI access by normalising connections to CRM, ticketing, file, and database systems. That creates a new class of exposure where a prompt injection, jailbreak, or over-permissive connector can move from model interaction into business data access. The governance question is whether AI-to-tool access is being treated as an identity boundary, or merely as an integration detail.

Key questions

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

A: Start by treating every MCP server as a privileged integration point. Require ownership, scope review, and server-specific authorization before production use, then map each connector to the data it can reach. Governance must include inventory, token scoping, and workload telemetry so security teams can see what the model actually does with that access.

Q: Why do MCP connectors increase risk for AI assistants and copilots?

A: They extend model behavior into external systems, which means a prompt can become a tool call and then a business action. If authorization is weak or visibility is poor, a malicious instruction can move from content manipulation into data exposure, file access, or destructive operations inside connected workloads.

Q: What breaks when MCP servers are deployed without native authorization?

A: The organization loses a reliable control point between the AI client and the external tool. That creates a patchwork of implicit trust, where some servers may be over-permissive, difficult to audit, or exposed through weak tokens. The result is an identity boundary that exists in design but not in enforcement.

Q: How do teams know whether MCP security controls are actually working?

A: Look for complete inventory, enforced scope limits, and a unified log trail that links prompts to tool calls and downstream system activity. If you can only see the model output, not the action path, the control is incomplete. Effective governance should prove who or what accessed which tool and why.

Technical breakdown

Why MCP authorization is still the first governance gap

MCP standardises how AI clients discover and call external tools, but early deployments often lacked native authorization between client and server. That means the protocol can describe connectivity before it can enforce who or what should be allowed to use each function. OAuth 2.1 improves the model, but only for environments that actually retrofit it and manage the resulting token and scope design correctly. Until then, the real control point sits outside the protocol in compensating identity, network, and workload safeguards.

Practical implication: treat MCP authorization as incomplete unless you have verified token scope, trust boundaries, and server-specific access controls.

How remote and local MCP deployments change the attack surface

Local MCP connects an app to resources on the device, while remote MCP shifts trust to a third-party or hosted server. Fully remote models reduce enterprise visibility because the model provider and server may exchange data with little internal monitoring. That creates different failure modes, but both still depend on how the surrounding workload is governed. The security issue is not just location. It is whether the organization can inspect, constrain, and audit the tool calls that flow through the connection.

Practical implication: classify MCP endpoints by trust model and apply different monitoring and isolation controls to local, remote, and fully remote deployments.

Runtime inspection is now part of AI identity governance

MCP makes prompts, tool calls, and responses part of an operational identity chain, because the model is no longer only generating text. It is initiating actions through tools that may reach databases, file systems, or SaaS platforms. That means runtime security has to observe not only the content of the prompt, but also the behavior of the workload as it exercises those permissions. In practice, AI identity governance now depends on seeing what the model accessed, when it did so, and whether the resulting action stayed within policy.

Practical implication: add workload-level monitoring that can correlate prompt activity, tool access, and downstream system actions in one audit trail.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI connectivity into unauthorized data exposure or unsafe tool execution through the MCP layer.

1. Entry begins when an AI application connects to an MCP server that has weak or absent native authorization, giving the model a route to external tools and data sources.
2. Escalation occurs when prompt injection or a malicious instruction causes the model to invoke overly broad tool permissions or leak secrets through the connector.
3. Impact follows when the model-driven action reaches customer records, internal documents, or destructive operations inside the connected workload.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

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 security is really a governance problem disguised as a protocol problem. The protocol makes AI connectivity easier, but it does not remove the need to define trust boundaries, approve tool scope, and audit downstream actions. That is why the control gap shows up first in identity and workload governance, not in the model layer itself. Practitioners should stop treating MCP as an integration detail and start treating it as a privileged access path.

Native authorization is the minimum bar, not the operating model. Thousands of deployed MCP servers will not be fixed by protocol updates alone because the installed base already exists with different trust assumptions, different owners, and different token handling. The practical reality is a patchwork environment where some servers are scoped and observable while others remain functionally open-ended. That makes inventory and containment the governance baseline, not a nice-to-have.

Runtime visibility is now part of identity control for AI workloads. Once an AI app can call tools, the effective identity is no longer only the API key or service account behind it. It is the combination of model, connector, tool scope, and execution context. That means security teams need to govern the whole decision path, not just the credential that opened it. The implication is straightforward: if you cannot see the tool call, you cannot govern the identity.

Prompt injection becomes materially more dangerous when it can cross into tool execution. The moment MCP connects a model to business systems, malicious instructions can move from content manipulation into operational action. That shifts the risk from bad output to privileged side effects, including exposure of sensitive data or file-system actions. The practical conclusion is that AI safety controls and workload controls now have to operate as one control plane.

AI-to-tool access boundary: MCP creates a new governance boundary where traditional application access reviews are too slow and too static for the pace of model-driven execution. The assumption that trust can be decided at onboarding and then revisited later is too weak for AI systems that can discover and call tools dynamically. Practitioners need to rethink how access is established, observed, and revoked across the full AI workload lifecycle.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• A separate finding showed that 53% of MCP servers expose credentials through hard-coded values in configuration files, which means configuration hygiene is now a core access-control issue.
• For a broader agentic view, see OWASP Agentic Applications Top 10 for the control patterns most likely to fail when models can select tools at runtime.

What this signals

MCP creates a new operational identity layer that most IAM programmes are not yet measuring. The immediate signal is not just connector proliferation, but unowned trust paths that sit between the model and the systems it can reach. Teams should expect their review processes to miss these paths unless MCP inventory is tied directly to workload monitoring and access certification.

Ephemeral AI access will keep outpacing static control cycles. Once a model can discover tools at runtime, the decision window is shorter than traditional access review cadences. That makes runtime telemetry, connector scoping, and hardening of the underlying container or service environment more valuable than periodic attestation alone.

Secret exposure around MCP should be treated as an identity operations problem, not a configuration footnote. When configuration files leak credentials, the boundary between AI enablement and unauthorized access collapses quickly. Practitioners should pair MCP governance with secret discovery, rotation, and workload isolation, and use the Ultimate Guide to NHIs , Why NHI Security Matters Now as a baseline for non-human identity risk planning.

For practitioners

• Inventory every MCP endpoint and connector Map each local, remote, and fully remote MCP deployment to an owner, data class, and trust level so shadow AI and undocumented connectors are not left outside governance.
• Require scoped authorization before production use Verify that every MCP server has enforced OAuth 2.1 or equivalent access scoping, with least-privilege token design and explicit server-side policy enforcement.
• Correlate prompt activity with workload actions Log prompts, tool calls, and downstream file or network activity together so investigators can reconstruct how an AI action unfolded across the stack.
• Harden the underlying container or runtime layer Apply network, file, and process restrictions at the workload layer so a compromised or overreaching MCP integration cannot freely expand its blast radius.

Key takeaways

• MCP is turning AI integration into an identity and access problem because tool calls can now reach business systems directly.
• The biggest practical risk is not the protocol name but the combination of weak authorization, poor visibility, and over-permissive connectors.
• Teams should govern MCP like a privileged access path, with scoped tokens, runtime telemetry, and workload-level containment.

Key terms

• Model Context Protocol: A standard interface that lets AI applications connect to tools and data sources without custom point-to-point integrations. In security terms, it creates a new access boundary that must be governed like any other privileged integration, because the model can use the connection to reach sensitive systems.
• Prompt Injection: A malicious instruction embedded in input, content, or tool context that tries to steer an AI system into unsafe behavior. In MCP environments, the risk rises because the model may convert that instruction into an external tool call or data access action.
• Remote MCP Server: An MCP server hosted outside the local environment, often by a third party or in a managed service. It expands capability, but it also shifts trust and visibility away from the enterprise, which makes authorization, monitoring, and vendor governance more important.
• Shadow AI: Undiscovered or unmanaged AI tools and agents operating inside an environment without formal approval or inventory. With MCP, shadow AI can emerge through unofficial connectors, internal experiments, or remote services that security teams have not classified or monitored.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Aqua Security: MCP to Agentic AI, shaping AI security for what’s next. Read the original.