Recurring MCP breach patterns show why AI interfaces still need IAM

At a glance

What this is: This is a consolidated analysis of recurring MCP breach patterns, showing that insecure command execution, over-privileged tokens, and weak isolation keep turning AI integrations into identity and access failures.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI-connected tooling with the same discipline they apply to APIs and service accounts, or the control gaps will spread across AI, workload, and human access paths.

By the numbers:

• Over 150 million downloads were affected by the MCP STDIO transport design flaw.
• 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.

👉 Read Authzed's consolidated timeline of MCP breach patterns and failures

Context

Model Context Protocol, or MCP, is the layer that lets AI systems reach tools, data, and operational systems. In practice, that makes it an identity problem as much as an integration problem, because every connected tool inherits the trust and privilege decisions behind the connection.

The breaches in this timeline show a familiar pattern dressed in new language: command execution through unsafe inputs, exposed credentials, over-broad tokens, and weak tenant isolation. AI changes the interface, but not the security math, and the first control failures are still around authentication, least privilege, and containment.

For IAM and NHI programmes, the lesson is not that MCP is uniquely broken. It is that new AI-native tooling becomes dangerous very quickly when teams treat it as a feature layer instead of a governed identity surface.

Key questions

Q: What breaks when MCP tools can reach system commands without strong validation?

A: The control boundary breaks immediately because untrusted input stops being data and becomes execution. In MCP environments, that can let an attacker run commands, read local secrets, or pivot from a tool integration into the host runtime. Security teams should treat any command path reachable from tool metadata, prompts, or remote endpoints as a critical trust boundary.

Q: Why do MCP integrations so often become non-human identity risks?

A: Because the integration usually runs on service accounts, API keys, or delegated tokens that are broader than the task requires. When those credentials are embedded in a tool bridge, a single compromise can expose cloud access, source code, or internal data. The issue is not AI novelty. It is standing privilege hidden inside automation.

Q: What do security teams get wrong about MCP supply-chain risk?

A: They often focus on the server code and ignore the registry, build pipeline, and metadata layer that deliver it. In MCP ecosystems, a malicious package or poisoned manifest can be enough to redirect trust and create downstream compromise. The right lens is supply-chain identity control, not just code scanning.

Q: How should organisations govern AI tool access when MCP is involved?

A: They should apply the same governance discipline used for other high-trust non-human identities. That means explicit ownership, per-tool scoping, short-lived credentials, tenant separation, and revocation when the relationship changes. If the tool can reach production data or infrastructure, it should be governed like privileged machine access, not like a convenience integration.

Technical breakdown

How MCP becomes a command execution path

MCP is designed to connect models to tools through a standard interface, but some implementations pass user-controlled values into shell commands or subprocesses without sufficient sanitization. That turns a tooling bridge into an execution bridge. The risk is not limited to one server type, because the same pattern shows up in local inspectors, remote proxies, hosted registries, and integration layers. Once command execution is possible, the attacker is no longer limited to model output manipulation. They can reach the host operating system, environment variables, and adjacent secrets stored on the same runtime.

Practical implication: review every MCP integration that executes system calls and remove any path where untrusted input can reach command parsing.

Why over-privileged tokens turn MCP into a breach multiplier

Many MCP workflows depend on service tokens, API keys, or delegated credentials with broad access to data sources, chat systems, source code, or cloud tools. If those credentials are reused across multiple tools or granted at account scope, a single compromise can expose far more than the immediate integration. This is classic non-human identity risk: the secret is not just an authenticator, it is a standing authorization boundary. When the token also sits inside a promptable or tool-driven workflow, the attacker can use legitimate calls to exfiltrate data while appearing to behave normally.

Practical implication: scope every MCP credential to one service, one purpose, and one environment, then remove any shared token pattern that expands blast radius.

Why isolation failures matter more in hosted MCP ecosystems

Hosted MCP registries and shared server platforms introduce a supply-chain layer where one compromised build path, package, or registry entry can affect many downstream deployments. If build contexts, container boundaries, or tenant boundaries are weak, the compromise can travel from a poisoned server definition to the host system and then into client traffic. That is why MCP security cannot rely on code review alone. The control plane, build pipeline, and runtime isolation model all become part of the identity trust boundary.

Practical implication: isolate build, registry, and runtime trust zones separately and treat hosted MCP components as multi-tenant identity infrastructure.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI integration layer into a reusable path for command execution, data theft, or service takeover.

1. Entry begins when attackers abuse exposed MCP tooling, malicious registries, or unsafe integrations to reach a trusted execution path.
2. Credential access follows when over-privileged API keys, service tokens, or local secrets are available to the compromised MCP runtime.
3. Impact occurs when the attacker uses legitimate-looking tool calls or direct command execution to exfiltrate data, take over services, or pivot into downstream systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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 has become an identity surface before it became a security product category. The breach timeline is not really about one protocol flaw, it is about what happens when tool connectivity inherits privilege without lifecycle discipline. Once AI systems can call tools, the question shifts from whether the model is safe to whether the connected identity and authorization model is constrained enough to survive abuse. Practitioners should treat MCP as governed identity infrastructure, not a convenience layer.

Over-privileged delegation is the recurring failure mode behind these incidents. The same pattern appears in exposed service tokens, broad personal access tokens, shared registries, and integration accounts that can do far more than one task requires. That is a non-human identity governance problem, not a model problem. Least privilege, tool scoping, and secret isolation remain the decisive controls, and their absence explains why so many MCP failures propagate quickly.

Tool poisoning is the named concept this timeline adds to the NHI threat model. Tool descriptions, registry metadata, and integration manifests can be used as the attack payload when an AI assistant trusts them as operational truth. That breaks the assumption that control decisions are based only on trusted code and verified requests. Practitioners should reclassify tool metadata as a governed trust input, not harmless configuration.

AI changes the interface, but not the accountability model that security teams rely on. The breaches show that when an MCP flow fails, the root cause still traces back to ordinary control gaps: authentication, containment, and privilege boundaries that were either missing or too broad. For IAM and PAM leaders, the implication is direct. Existing governance models still apply, but only if they are enforced at runtime and across the full delegation chain.

This timeline validates that NHI governance now needs to extend into AI-native integration fabrics. MCP servers, proxies, registries, and inspectors behave like high-trust service identities with unusually large blast radius. That means offboarding, credential rotation, access scoping, and tenant isolation are no longer back-office hygiene. They are the controls that decide whether AI-connected infrastructure becomes manageable or becomes a breach amplifier.

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.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• For a broader control model, see 52 NHI Breaches Analysis for recurring identity failure patterns and remediation themes.

What this signals

Tool-poisoning is becoming a governance signal, not just an exploit pattern. Once metadata, manifests, and registry content can influence runtime behaviour, practitioners need to treat the tool layer as part of the identity trust chain. That is especially true where OWASP Agentic AI Top 10 style risks intersect with delegated access and sensitive business data.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the operational lesson is clear: AI connectivity often arrives before basic secrets hygiene does. Teams that do not inventory exposed credentials now will keep inheriting the same blast radius, only with more tools attached to it, according to the 2025 MCP security research.

MCP is a preview of a wider pattern in AI-native infrastructure. As integrations spread, the control question will move from whether the model can reason to whether the surrounding identity fabric can absorb trust without turning every tool bridge into a lateral movement path.

For practitioners

• Inventory every MCP-connected identity Map each MCP server, proxy, registry, and inspector to the service account, API key, or token it uses. Include ownership, purpose, environment, and downstream systems so you can see where one credential silently spans multiple tools.
• Remove command execution from untrusted input paths Audit all MCP integrations for shell calls, subprocess execution, and command templating. If any user-controlled or model-controlled field can reach execution without strict allowlisting, treat that as a release blocker.
• Scope credentials to a single tool and tenant Replace shared or broad-scope tokens with short-lived, purpose-built credentials that cannot be reused across registries, clients, or environments. Narrow token scope before expanding MCP use cases.
• Treat tool metadata as trusted input only after validation Validate MCP manifests, tool descriptions, and registry entries before the assistant can act on them. Hidden instructions in metadata should be handled like supply-chain content, not documentation.
• Separate build trust from runtime trust Isolate package build paths, container execution, and client-facing traffic so a compromise in one layer does not expose credentials in another. This matters most for hosted MCP ecosystems and shared registries.

Key takeaways

• MCP failures are identity failures because the protocol turns tool connectivity into a privilege-bearing trust path.
• The evidence shows repeated exposure of secrets, broad access scopes, and command execution paths that were never narrowed enough for production use.
• Teams should govern MCP like privileged machine access, with scoped credentials, runtime containment, and strict validation of tool metadata.

Key terms

• Model Context Protocol: Model Context Protocol is a standard interface that lets AI systems connect to tools, data sources, and services. In practice, it creates a governed trust path between an AI runtime and external systems, so security depends on how authentication, authorization, and execution boundaries are implemented.
• Tool Poisoning: Tool poisoning is the use of malicious or altered tool metadata, descriptions, or manifests to influence an AI system's behaviour. The attack works because the model treats metadata as operational guidance, which can redirect tool calls, leak data, or trigger unsafe actions if validation is weak.
• Delegated Non-Human Identity: A delegated non-human identity is a service account, token, or API key that acts on behalf of a system, workflow, or AI integration. Its security value depends on scope, lifecycle, and revocation discipline, because a single over-broad credential can authorize far more than the task actually needs.
• Runtime Trust Boundary: A runtime trust boundary is the point where an identity or tool call crosses from controlled input into an execution environment. For MCP systems, this boundary matters because untrusted prompts, manifests, or endpoints can become commands, data access, or downstream automation if the boundary is not enforced.

Deepen your knowledge

MCP security and delegated access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is now treating AI tool bridges like production identities, that course is a practical next step.

This post draws on content published by Authzed: LLMjacking and recurring MCP breach patterns across 2025 and 2026. Read the original.