MCP integration risks expose AI toolchains to code execution and theft

At a glance

What this is: The article shows that popular MCP tools can expose AI toolchains to remote code execution, API key theft, and file reads because the integration layer is trusted too much.

Why it matters: It matters because identity teams now have to govern tool-connected AI systems, not just human users and service accounts, or they inherit hidden access paths into data and secrets.

By the numbers:

• Collectively representing over 140k GitHub stars and 60k DockerHub downloads, these vulnerabilities expose organizations to data exfiltration, credential theft, and lateral movement.

👉 Read OXSecurity's analysis of MCP vulnerabilities exposing AI toolchains to RCE and theft

Context

MCP security is now an identity governance problem, not just a developer tooling problem. When an integration layer can execute actions, reach files, or pass credentials between AI systems and external tools, the question becomes who or what is authorised to act, and under what constraints.

The article shows that weaknesses in widely adopted MCP tools can turn local development assumptions into remote exposure paths. For IAM, NHI, and agentic AI programmes, that means the trust boundary has moved into the connector layer where tools, tokens, and runtime context intersect.

Key questions

Q: What breaks when MCP tools are treated as harmless local utilities?

A: Local-only MCP tools can still expose code execution, file reads, and secret theft if they sit inside a weak trust boundary. The failure is assuming locality equals safety. Once the tool can touch credentials or internal data, it becomes part of the privileged identity plane and must be controlled that way.

Q: Why do MCP-connected AI workflows increase lateral movement risk?

A: Because a single compromised integration point can provide reusable access to files, APIs, and session material that other systems trust. That lets an attacker move from one foothold to adjacent services without breaking each control separately. The wider the connected tool scope, the larger the blast radius.

Q: How do security teams know whether an MCP tool is over-privileged?

A: Look for any tool that can access more directories, APIs, secrets, or commands than its immediate task requires. If the tool can reuse environment variables, read broad filesystem paths, or reach multiple systems without a clear business need, its runtime privilege exceeds its intended function.

Q: Who should own governance for MCP tools inside AI environments?

A: Ownership should sit with the team responsible for identity governance and privileged access, not only application engineering. If an MCP tool can read secrets, access data, or trigger actions, the organisation should assign an accountable owner, define scope, and review it through the same governance path as other high-risk non-human identities.

Technical breakdown

How MCP trust boundaries create an identity attack surface

Model Context Protocol connects AI systems to tools and data sources through a shared execution layer. That design can be efficient, but it also means the connector inherits trust, context, and access from the surrounding environment. If authentication is absent or minimal, an attacker only needs a weakness in the tool or its exposure path to turn a local integration into an entry point for code execution, credential access, or file disclosure. In practice, the protocol layer becomes part of the identity plane because it can mediate actions and data flow without the safeguards normally applied to privileged access.

Practical implication: treat MCP endpoints as privileged integration surfaces and require explicit scope limits, network restriction, and credential isolation.

Why API key theft matters when tools sit inside AI workflows

API keys, session cookies, and other secrets are especially sensitive in MCP-enabled workflows because the tool layer often has direct reach into cloud services, repositories, and internal data. If a tool can read files or bypass origin checks, it can expose credentials without needing to break the underlying model or application. That changes the risk from a single vulnerable utility to a reusable foothold that supports persistence and lateral movement. For identity teams, the key issue is not only that secrets exist, but that they may be available to any connected component with insufficient boundary enforcement.

Practical implication: scope every secret to the narrowest feasible workload and separate tool runtime access from secret access paths.

Why localhost assumptions fail in modern AI development

Several MCP tools are deployed as if local execution is a safe default. In current developer environments, that assumption is fragile because browsers, desktop apps, containers, and cloud-synced tooling can all interact with local services in unexpected ways. CORS bypasses, DNS rebinding, and crafted user interactions can convert a supposedly local service into a remotely reachable attack surface. The failure is architectural, not just operational: locality does not equal trust, and trust does not equal containment.

Practical implication: do not rely on 'local only' as a security control unless the service is also isolated, authenticated, and network-restricted.

Threat narrative

Attacker objective: The attacker wants a trusted AI integration point that yields secrets, internal files, and reusable access into adjacent systems.

1. Entry occurs when a user opens a crafted HTML page or interacts with a reachable local MCP service, allowing the attacker to reach a trusted integration boundary.
2. Escalation follows when the vulnerable MCP exposes code execution, API key theft, or local file read capability that the attacker can abuse to obtain broader access.
3. Impact is achieved through credential reuse, data exfiltration, and lateral movement across connected developer and AI environments.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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 integration risk is an identity problem before it is an application problem. These tools sit between users, AI systems, repositories, and cloud services, so they inherit privilege without necessarily inheriting the controls that normally govern privilege. That makes the integration layer a governance boundary, not a convenience layer. Practitioners should classify MCP-connected components as part of the identity estate, not as neutral plumbing.

Trusted execution without blast-radius awareness is the real failure mode. The article points to a design pattern where a tool can act, read, and relay data inside a session without clear containment. That creates an identity blast radius larger than the organisation thinks it has. The practitioner conclusion is simple: if the connector can operate on secrets or files, it must be governed like a privileged workload, not a helper utility.

Local-only deployment is not a security model. The maintainers' argument that a service is local does not remove the need for authentication, origin control, and boundary enforcement. Modern developer environments mix browser content, desktop clients, sync agents, and containers in ways that collapse the old notion of 'safe localhost'. Security teams should stop treating locality as a substitute for identity and access control.

Runtime access to MCP tools should be evaluated through the same lens as other non-human identities. A tool that can reach data sources, use secrets, and trigger actions is already participating in governance decisions. The organisation may not call it an NHI, but the control problem is the same: who can it reach, what can it do, and what prevents abuse once it is trusted. Practitioners should fold MCP tools into NHI and PAM review processes.

Identity blast radius: the connector layer now determines how far one compromise can travel. That concept matters because the article shows a single weak MCP can become a bridge from code execution to credential theft and lateral movement. The implication for the field is that AI security cannot be separated from identity governance when tools are allowed to sit inside the trust boundary.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• A separate finding shows that 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.
• Forward-looking analysis: The same governance gap shows up in OWASP Agentic Applications Top 10, which helps teams map tool misuse, identity abuse, and boundary failures before they become incidents.

What this signals

Identity teams should expect AI integration layers to become audit and containment priorities, not just engineering dependencies. As MCP-style tooling spreads, the question shifts from whether a workflow is AI-enabled to whether its connector layer has an owner, a scope, and a revocation path. That is where governance will either hold or fail.

Runtime scope is now the control variable that matters most. If a tool can reach secrets, files, or cloud APIs, then boundary design matters more than the model brand or framework name. The practical test is whether the tool can be isolated without breaking the workflow.

With 80% of organisations already reporting AI agents acting beyond intended scope, the governance pattern is no longer hypothetical. Teams should align integration-layer controls with the NIST Cybersecurity Framework 2.0 and the OWASP Agentic AI Top 10 where AI-connected tools can execute privileged actions.

For practitioners

• Inventory every MCP-connected tool and service Map which tools can read files, reach APIs, access secrets, or execute commands. Classify each one as a governed integration asset and record its owner, approved scope, and dependency chain.
• Restrict MCP runtime scope to isolated environments Run MCP tools inside closed containers or tightly segmented hosts with no broad filesystem access and no unnecessary network exposure. Treat localhost as untrusted unless authentication and network filtering are in place.
• Apply secret governance to tool-connected workflows Eliminate hard-coded keys, scope every credential to the smallest possible task, and separate secret access from general application access. Review whether any MCP tool can read credentials indirectly through local files or environment variables.
• Add explicit review of integration-layer privilege Fold MCP tools into existing IAM, NHI, and PAM review cycles so access is assessed as a privileged runtime relationship, not a developer convenience. Require an owner to attest to what each tool can reach and why.

Key takeaways

• MCP tools can convert integration convenience into privileged access risk when authentication, scope, and containment are weak.
• The strongest evidence in the article is the combination of code execution, API theft, and local file exposure across tools with large adoption footprints.
• Practitioners should govern MCP-connected components as part of the identity estate and apply least privilege, isolation, and explicit ownership.

Key terms

• Mcp Trust Boundary: The security boundary created by a Model Context Protocol connection between an AI assistant and an external system. Each connection can supply data, trigger actions, or both, so it must be governed like a delegated access path rather than a simple integration.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Integration-layer privilege: Integration-layer privilege is the effective access created by connectors, plugins, and protocol bridges that mediate AI-to-tool communication. It is not always obvious in the application design, but it often determines whether a compromise stays local or becomes a wider identity event.

What's in the full report

OXSecurity's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step vulnerability breakdowns for kubectl-mcp-server, Archon OS, and MarkItDown MCP
• Responsible disclosure timeline and maintainer responses for each affected project
• Technical proof paths showing how the CORS bypass, API theft, and file read issues were reached
• Practical exploitation notes that help engineers validate exposure in their own environments

👉 OXSecurity's full post covers the vulnerability details, disclosure history, and exploitation paths for the affected MCP tools.

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