TL;DR: Three vulnerabilities across widely used MCP tools and Archon OS, including unauthenticated API key theft and arbitrary code execution, were found according to OXSecurity, with the affected projects representing more than 140k GitHub stars and 60k DockerHub downloads. Trusted integration layers are becoming identity and data access surfaces faster than governance controls are being adapted.
At a glance
What this is: OXSecurity identified three MCP-related vulnerabilities across popular open-source tools and Archon OS that can enable arbitrary code execution, API key theft, and local file reads.
Why it matters: AI toolchains now expose identity-bearing integration layers, so IAM, PAM, and NHI teams need to treat MCP connections as governed access paths rather than passive plumbing.
By the numbers:
- The affected projects represented more than 140k GitHub stars and 60k DockerHub downloads.
Context
MCP security gaps are not just software bugs. They are governance failures at the point where AI tooling is allowed to reach APIs, local files, and credentials without the same controls applied to other privileged integrations.
In this article, OXSecurity says three vulnerabilities across popular MCP tools and Archon OS can lead to arbitrary code execution, unauthenticated API key theft, and local file read. That combination matters because the integration layer is increasingly where identity, secrets, and execution converge.
For IAM and NHI programmes, the issue is not whether an MCP is local or open source. The issue is whether that integration path has authentication, scope control, and blast-radius limits that match the access it can actually exercise.
Key questions
A: The control boundary breaks because the integration layer becomes a privileged actor rather than a neutral transport. If one connector can read files, call APIs, and trigger execution, then compromise of that connector can produce credential theft, data exfiltration, and lateral movement. Practitioners should govern that path like an identity with scope and revocation, not like a simple plugin.
Q: Why do unauthenticated MCP endpoints increase the risk of API key theft and lateral movement?
A: Because any endpoint that can expose tokens without verifying the caller creates a direct path from trust assumption to secret exposure. Once an attacker can retrieve API keys or session material, downstream services may accept that access as legitimate. The issue is not only exposure of the key, but the absence of caller binding, scope restriction, and revocation control.
Q: How do security teams know if MCP access policies are too coarse?
A: If a single role or policy grants access to broad datasets or multiple tools when the task needs only one resource, the policy is too coarse. The signal is overpermission, not just denied requests. Good MCP governance should show client-specific consent, narrow scopes, and auditable request context.
A: No. Local deployment is not a substitute for security boundaries when a tool can access credentials, files, or code execution. The practical difference is operational, not authoritative. Organisations should apply the same identity, secret, and permission governance to local AI tools that they apply to remote integrations whenever those tools can touch sensitive assets.
Technical breakdown
Why MCP integration layers become privileged execution surfaces
Model Context Protocol connects AI tools to external services, but the security model is often thinner than the access it enables. When a tool can call APIs, read files, or interact with local services, it effectively becomes an identity-bearing integration point, even if it is treated operationally like helper software. The article shows that a compromised MCP can move from convenience layer to execution layer because the trust boundary is not the model, but the integration path. That is why the presence of a toolchain connector changes the risk posture of the whole environment, not just the individual plugin.
Practical implication: Treat each MCP integration as a governed access path with explicit authentication, scope, and revocation controls.
How unauthenticated API key theft happens in MCP workflows
The Archon OS issue described in the article is a good example of how browser-origin or cross-origin trust assumptions can expose sensitive tokens. If an integration endpoint can be reached without proper origin controls or strong authentication, API keys become retrievable through the very workflow that is supposed to broker access. In identity terms, the problem is not only weak secrecy handling. It is the failure to bind token exposure to a verified caller and a constrained session. That makes the integration surface a credential theft target, not merely an application interface.
Practical implication: Enforce token scoping, origin restrictions, and explicit authentication on every MCP-facing endpoint.
Why local file read and code execution are the same governance problem
Arbitrary local file read and arbitrary code execution look different technically, but both show that the MCP has crossed from data mediation into system authority. Once a tool can read arbitrary files or drive a victim system into executing content from a crafted page, the boundary between assistant workflow and host control disappears. For NHI governance, this is the critical warning: access scope is being inherited through integration rather than assigned deliberately. That creates an oversized blast radius even when the tool was installed for a narrow task.
Practical implication: Limit MCP file and execution reach to tightly defined directories, processes, and permission scopes.
Threat narrative
Attacker objective: Use a compromised MCP integration to steal secrets, execute code, and pivot into broader access across the AI toolchain.
- Entry occurs through a popular MCP tool or integration path that is trusted by developers and users but lacks sufficient security controls.
- Credential access follows when the integration can expose API keys, session material, or other secrets through weak origin handling or file access.
- Escalation occurs when the tool is able to execute code or expand its effective privileges beyond the intended task boundary.
- Impact is data exfiltration, credential theft, and lateral movement through downstream services that trust the compromised integration layer.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
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 security is now an identity-governance problem, not just an application-security problem. The article shows that integration layers can expose code execution, API keys, and file access in a single control plane. That means the real question is who or what is authorised to act through the integration, not just whether the tool is technically reachable. Practitioners should treat MCP pathways as governed identities with explicit lifecycle and scope controls.
Blast radius, not feature count, is the decisive control variable in MCP deployments. A tool that can reach files, keys, and APIs without strong boundaries creates compound risk even when each individual capability looks modest. The named concept here is integration-layer blast radius: the size of the damage possible when a single trusted connector inherits too much authority. Security teams should measure what one compromised connector can touch, not how many connectors are installed.
Local-only deployment assumptions have stopped being a valid security boundary. The article’s maintainers and disclosed flaws both point to a pattern where “meant to be local” is treated as equivalent to “safe.” That assumption breaks once developer machines, browser sessions, and AI workflows are interconnected. The implication is that governance must follow actual access paths, not deployment intent.
MCP tools inherit secrets governance failures the moment they can touch API keys. If an integration can read or surface keys without scoping, it becomes part of the secret lifecycle whether or not the vendor intended it. This is the same discipline NHI teams already apply to service accounts and tokens. Practitioners should manage MCP connectors as secret-bearing actors with ownership, scoping, and revocation requirements.
AI toolchain risk is converging on the same control gaps that have long affected non-human identities. The article describes a familiar pattern: permissive trust, weak scoping, and unclear accountability at the integration layer. What changes here is the speed and reach of the access path, not the underlying governance failure. Teams should align MCP oversight with NHI control patterns before the toolchain becomes the highest-trust route in the environment.
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.
- Read next: MCP Security Guide
What this signals
Integration-layer blast radius: MCP is turning the connector itself into the unit of governance. When one tool can expose secrets, read files, and execute code, access reviews need to move from application inventory to path-level authority review.
Enterprises should expect more findings like this as AI tooling spreads through developer workflows. The practical response is to discover which assistants, IDE extensions, and local services can touch credentials or file systems, then place them under the same control expectations as other privileged non-human identities.
For practitioners
- Enforce connector-level authentication Require every MCP endpoint and gateway to authenticate callers explicitly and bind access to a verified identity and session scope.
- Constrain file and process reach Restrict MCP tools to specific directories, container boundaries, and process permissions so a single tool cannot read arbitrary local files or broaden execution scope.
- Harden token handling on AI integrations Store API keys and session tokens outside configuration files, and apply least-privilege scopes plus revocation processes for any MCP that can surface them.
- Review localhost trust assumptions Block public exposure of local services, validate browser-origin controls, and test whether local-only tools remain isolated under real developer workflows.
- Inventory MCP usage across teams Discover which AI assistants, IDE extensions, and developer tools are using MCP so ownership, approval, and offboarding can be assigned to each integration.
Key takeaways
- MCP connectors are now part of the identity perimeter because they can mediate access to code, files, and secrets.
- The reported vulnerabilities show that a single integration path can create exposure across credential theft, local file read, and code execution.
- Practitioners need to govern AI toolchain integrations with explicit authentication, narrow scope, and revocation, or the attack surface will keep expanding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed API keys and token theft through MCP integrations. |
| NHI-04 — Insecure Authentication | Unauthenticated key theft and weak caller verification are central to the Archon OS issue. | |
| NHI-05 — Overprivileged NHI | The article shows MCP tools inheriting excessive access to files, APIs, and execution. | |
| Recommendation — Scan MCP-connected tools for exposed secrets and remove any integration that can surface keys indirectly. Require explicit authentication on every MCP-facing endpoint and reject anonymous access paths. Reduce MCP permissions to the smallest possible file, API, and process scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The vulnerabilities enable secret theft and movement through downstream systems. |
| Recommendation — Map MCP exposure to credential access and lateral movement detections in your threat model. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about ungoverned access paths inside AI toolchains. |
| PR.DS-10 — Data in Transit is Protected | CORS bypasses and exposed endpoints show weak protection of sensitive exchanges through the integration layer. | |
| Recommendation — Review MCP entitlements against task need and remove any standing access that exceeds scope. Protect MCP traffic and endpoint exposure so sensitive data cannot be intercepted through relaxed transport controls. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key handling and token governance are central to the abuse path described in the article. |
| AC-6 — Least Privilege | The article repeatedly points to excessive access granted to AI integration tools. | |
| Recommendation — Apply authenticator management to revoke, scope, and rotate any secrets exposed through MCP tooling. Constrain each MCP integration to least privilege so one compromise cannot reach unrelated systems. | ||
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 connector: An MCP connector is the integration component that lets an AI agent or application use the Model Context Protocol to reach external tools, data sources, or services. It translates protocol requests into tool-specific actions, handles authentication and context exchange, and helps govern what the agent can access, invoke, or retrieve.
- Answer-layer Blast Radius: Answer-layer blast radius is the number of users or decisions that can be affected when one manipulated source influences a generated response. The risk is larger than a single bad citation because one page can be reused across many prompts and many users.
- Caller binding: The practice of tying a sensitive action or secret retrieval to a verified requester and context. For MCP environments, caller binding matters because a token or API key should not be retrievable unless the requesting tool, session, and origin are all explicitly trusted.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org