MCP servers expose the new AI action layer risk in production

At a glance

What this is: This is an analysis of how MCP servers turn AI agents into an action layer that can interact with real systems through APIs, creating a visibility and governance gap in production.

Why it matters: It matters because IAM, PAM, and NHI teams need to govern what agents can do, not just what models can say, or machine-speed API actions will bypass existing controls.

Context

MCP servers are the middleware that let AI agents call internal systems, third-party services, and databases through APIs. In practice, that means the control problem shifts from model output to governed execution across an expanding action layer.

The security gap is that many teams are treating these connections like temporary developer tooling while they are already behaving like production access paths. That creates an unmanaged identity and authorisation surface for NHI and agentic AI programmes.

Salt's argument is that visibility, posture, and runtime protection have to extend to the MCP layer itself, because securing the model without governing the APIs it can trigger leaves a material control gap.

Key questions

Q: What breaks when an MCP server is treated like a temporary developer script?

A: Ownership and accountability break first. The server can drift into production without lifecycle governance, leaving its API bindings, credentials, and data scope unmanaged. At that point, the organisation may still see a working integration but no reliable way to recertify access, limit blast radius, or offboard the path when it is no longer needed.

Q: Why do MCP agents increase access risk compared with conventional service accounts?

A: MCP agents can make runtime tool choices and may carry human-derived entitlements, so their effective authority is not fixed at provisioning time. That makes least privilege harder to define with static roles alone and increases the chance that one workflow can reach more resources than expected.

Q: How do security teams know if a workflow is behaving outside its intended boundary?

A: They compare observed behaviour against a known baseline for the workflow, including destinations, processes, and registration activity. If a job suddenly contacts unfamiliar domains, downloads new binaries, or creates a runner, that is a governance signal rather than a harmless variation.

Q: When should organisations re-evaluate third-party controls for AI agents?

A: Re-evaluate them whenever an agent can send regulated or CUI-adjacent data to an external API, hosted model, or orchestration service. Each integration can become a compliance boundary. If the dependency map is not current, the organisation is relying on assumptions instead of verified control over data flow.

Technical breakdown

Why MCP servers become an action layer

MCP is a protocol for connecting an LLM-based agent to tools and data sources, but in production it becomes a control plane for actions. The agent does not merely generate text; it can open tickets, query databases, update records, and trigger downstream API calls through MCP servers. That means the real security boundary is no longer the model prompt. It is the set of permissions, tool bindings, and runtime conditions that govern which actions can be issued, to which systems, and with what data scope. Practical implication: treat MCP-connected tools as governed execution paths, not harmless integration glue.

Practical implication: Inventory MCP-connected tools as governed execution paths, not harmless integration glue.

Why STDIO exposure changes the risk profile

The article highlights that MCP's STDIO interface can allow arbitrary OS command execution with minimal authentication, which expands the problem beyond simple API abuse. Once an agent or server can invoke local commands and reach internal resources, the security model has to account for both command execution and the APIs those commands can reach. That makes the attack surface mixed, with local privilege, application access, and data movement all converging in one place. Practical implication: isolate MCP transports and require explicit authorisation boundaries before an agent can bridge from text generation into system execution.

Practical implication: Isolate MCP transports and require explicit authorisation boundaries before an agent can bridge into system execution.

Why shadow MCP servers are hard to govern

The article describes MCP servers starting as local scripts and drifting into production, which creates a discovery problem rather than just a policy problem. Traditional inventory tools are built for static assets and miss ephemeral or developer-spun services that become part of the AI action layer. That means an organisation can have live access paths without any durable ownership, risk classification, or offboarding process. Practical implication: build continuous discovery for agentic infrastructure and tie each MCP server to an accountable owner, data scope, and revocation path.

Practical implication: Build continuous discovery for agentic infrastructure and tie each MCP server to an accountable owner, data scope, and revocation path.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI action path into a covert mechanism for unauthorized API calls, data exposure, or destructive system actions.

1. Entry occurs when an attacker manipulates an AI agent through prompt injection or another input path that causes the agent to act on hostile instructions.
2. Credential or command abuse follows when the agent uses its MCP server connections to issue valid API calls or OS-level commands against connected systems.
3. Impact occurs when those actions produce data exfiltration, bulk export, or unauthorized system changes that traditional controls fail to distinguish from normal use.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

The core risk is no longer model behaviour, it is governed execution. MCP servers convert an AI agent from a conversational system into a system that can take real actions through APIs. That shifts the control question from prompt safety to authorisation scope, runtime monitoring, and containment of downstream effects. The practitioner conclusion is simple: if you cannot govern the action path, you do not have an agentic security programme.

Shadow MCP infrastructure creates an identity governance blind spot. Local experiments that drift into production are not just untracked tools, they are unowned non-human access paths. That means no clear joiner-mover-leaver logic, no consistent recertification, and no durable offboarding when the experiment becomes business-critical. The implication is that lifecycle governance now has to follow the server, the agent, and the API binding together.

Identity blast radius is the right named concept for this layer. A mis-scoped MCP server can expose more than a single credential or endpoint, because it can expand the agent's effective reach across multiple systems at machine speed. The article's warning is that one misconfigured API or broad tool can turn routine automation into a company-wide action channel. Practitioners should treat scope and observability as the primary limits on blast radius.

Least privilege for agents must be enforced at the action layer, not assumed at the model layer. The model may be constrained by prompts, but the agent's effect is determined by the APIs and tools it can reach. That is why broad keys, shared service accounts, and run-any-query tools become especially dangerous once an MCP server is in the path. The practitioner takeaway is that entitlements must be measured against actual action capability, not against intended use cases.

Agentic security now depends on API governance as much as on AI governance. The article is right that the AI revolution is also an API revolution, because the agent's value and risk both materialise through calls to existing systems. That means security teams have to evaluate AI-to-API interactions as a first-class access pattern, not as a side effect of model adoption. The field should expect MCP governance to converge with API security, NHI oversight, and Zero Trust control design.

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.
• Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
• Read next: AI Agent Authorisation Guide

What this signals

Identity blast radius: when an MCP server sits between an AI agent and production systems, the size of the real control problem is measured by what the agent can do, not by what the model can say. That makes entitlement scope, transport isolation, and API visibility the practical boundaries that matter for programme design.

A mature agentic security programme has to treat MCP servers as governed non-human access paths. If discovery, authorisation, and revocation do not follow the server lifecycle, temporary integrations become durable exposure points with no clean offboarding path.

For practitioners

• Define the MCP server inventory Create a living inventory of every MCP server, including owner, connected systems, data types touched, and whether the service is temporary, shared, or production-bound.
• Scope AI agent entitlements to actual actions Review which APIs, databases, and OS commands each agent can invoke, then remove broad tools and shared credentials that allow run-any-query or unrestricted task completion.
• Segment MCP transports from core production paths Separate agent transport paths from sensitive operational networks so that an injected task cannot directly pivot from a local MCP call into privileged internal services.
• Monitor for off-script agent behaviour Baseline normal agent actions and alert when a workflow shifts from its usual queries to bulk exports, record changes, or other high-risk API sequences.
• Tie revocation to server offboarding Ensure MCP servers, service credentials, and downstream API bindings have an explicit offboarding path so temporary experiments do not become permanent access channels.

Key takeaways

• MCP servers turn AI agents into systems that can carry out real actions through APIs, which shifts the security problem from output quality to governed execution.
• The article's central warning is that unmanaged MCP infrastructure can become an invisible action layer, especially when local experiments drift into production.
• Practitioners need discovery, least-privilege entitlements, and continuous monitoring at the MCP layer to keep machine-speed actions inside a controllable blast radius.

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.
• AI action layer: The AI action layer is the part of an agentic system where model decisions become external actions through APIs and tools. It is the point at which identity, access, and runtime behaviour converge, which makes it the practical control surface for security teams rather than the model alone.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.
• Agentic Security Graph: A unified view of the identities, tools, APIs, data sources, and permissions that an AI agent can traverse. It shows the operational path from an agent’s action to the systems and records it can reach, which is essential for governing cross-platform risk.

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.