MCP servers expose the new AI action layer risk in production

At a glance

What this is: This is an analysis of MCP servers as the AI action layer, with the key finding that their API-mediated access creates a governance gap larger than prompt injection alone.

Why it matters: It matters because IAM, PAM, and NHI teams need visibility into what agents can actually do, not just what models are prompted to say.

By the numbers:

• Gartner predicts that by 2028, 80% of organizations will see AI agents consume the majority of their APIs.
• Gartner says that through 2029, over 50% of successful cybersecurity attacks against AI agents will exploit access control issues.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Salt's analysis of MCP server risk and the AI action layer

Context

MCP servers are becoming the control point where AI agents turn intent into real system actions, which makes them an identity and access problem as much as an AI problem. The governance gap is simple: once an agent can query databases, open tickets, and update records through APIs, the security question shifts from model safety to delegated authority.

That shift matters for NHI, PAM, and IAM programmes because the exposed asset is no longer just the API itself. It is the combination of machine identity, tool scope, runtime behaviour, and the organisational ability to detect when an agent exceeds the job it was meant to perform.

Salt frames this as the AI action layer, and that framing is useful because it separates decision-making from execution. The practical issue is not whether teams can deploy MCP quickly. It is whether they can prove what those MCP-connected identities are authorised to do, and whether they can stop misuse once those actions start.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What do organisations get wrong about AI safety and access control?

A: Organisations often focus on model outputs while ignoring the privileges behind the model. If an agent can read sensitive data or invoke tools, the real risk is what it can cause the environment to do. Effective control starts with scope, policy, and monitoring around actions, not just moderation of generated text.

Q: What should teams do if an MCP server can execute OS commands?

A: Treat it as privileged execution and place it under the same scrutiny as administrative access. Restrict who can deploy it, separate the identity it uses from lower-risk tools, and monitor command paths continuously. If the server can reach the operating system, the boundary has already moved beyond ordinary integration risk.

Technical breakdown

Why MCP servers turn agent intent into API risk

MCP is a protocol layer that lets an AI agent request tools, data, and actions from external systems. In practice, that means the agent is not operating only as a model prompt loop. It is orchestrating API calls through a machine identity path that can touch CRM, file stores, internal services, and SaaS apps. The security problem emerges when those calls inherit broad permissions, weak scoping, or hidden trust relationships. At that point, the control surface is no longer just the model. It is the full action chain from prompt to API execution.

Practical implication: Map every MCP connection to the underlying API, identity, and entitlement path before it reaches production.

Why arbitrary command execution changes the trust model

The article highlights that MCP's STDIO interface can allow arbitrary OS command execution with minimal authentication. That matters because a tool interface is not just a data connector. It can become an execution bridge from agent context into operating system actions, which widens the blast radius of a compromised or manipulated agent. The result is a trust inversion: the interface intended to speed integration can also shortcut control boundaries if it is not tightly governed. In identity terms, this is where delegated access becomes indistinguishable from uncontrolled execution.

Practical implication: Treat any MCP path capable of OS-level action as privileged access and subject it to explicit approval and inspection.

Why runtime intent detection matters more than static configuration

Static reviews miss the way AI-driven tools behave at runtime. An agent may appear normal at setup but later issue a sequence of valid API calls that collectively signals abuse, data harvesting, or unauthorised export. Behavioural baselining and intent analysis are therefore relevant because they look at the sequence and purpose of actions, not just whether each individual request passes authentication. That is a familiar NHI lesson: a credential can be technically valid and still be operationally dangerous if the behaviour behind it is not constrained.

Practical implication: Monitor agent activity for off-script sequences, not just blocked requests or failed authentications.

Threat narrative

Attacker objective: The objective is to convert trusted agent connectivity into silent, authorised-looking access that can steal data or trigger harmful actions at machine speed.

1. Entry occurs when a developer-built or shadow MCP server is exposed with broad API reach and weak authentication, allowing an attacker to manipulate the agent or its tools.
2. Escalation follows when the attacker leverages the agent's trusted access path to issue valid but malicious API calls, use arbitrary command execution, or widen scope across connected systems.
3. Impact is achieved through data exfiltration, unauthorised record changes, or abuse of downstream services that the organisation assumed were isolated from the agent layer.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The real risk has moved from model output to delegated execution. MCP servers are the place where intent becomes action, and that is where identity governance becomes operational rather than theoretical. Once an agent can press buttons on behalf of a user or workflow, the security question is no longer only what the model knows. It is what the agent is authorised to do, at runtime, across every connected API.

Shadow MCP infrastructure creates a new kind of identity sprawl. Local scripts that become production tools are functionally the same governance problem as unmanaged service accounts, except they arrive with more context and less visibility. The article's strongest point is that discovery is now the first control, because you cannot govern tools you cannot inventory. Practitioners should treat every undocumented MCP server as an identity asset with unknown blast radius.

Least privilege for AI agents is not a policy slogan but an execution boundary. Shared keys and broad run-anything tools collapse Zero Trust assumptions because they let the agent move from narrow task support to unrestricted system reach. That is especially dangerous where machine speed compresses the time between misuse and impact. The implication is that access scope, not model capability, becomes the primary control variable for agentic infrastructure.

Agentic Security Graph is a useful concept because it matches the layered risk model. The article separates the model, the MCP server, and the APIs it calls, which is the right mental model for governance. That layered view aligns with OWASP Agentic AI Top 10 thinking and with NHI practice around control-plane visibility, but the lesson is broader than one vendor's architecture. Practitioners need a single inventory of decision points, tool paths, and downstream entitlements.

Model Context Protocol hardens into a governance category only when teams accept that APIs are the real attack surface. The article is correct to say the AI revolution is an API revolution. That means the control problem spans NHI, IAM, PAM, and runtime monitoring together, not as separate workstreams. Security teams that still treat MCP as an integration detail will miss the identity layer that makes it dangerous.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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.
• That visibility gap becomes sharper in OWASP Agentic Applications Top 10, where tool abuse and identity misuse are treated as core agentic risks.

What this signals

AI action-layer governance is becoming a control-plane problem, not a model-management problem. If organisations keep separating AI oversight from IAM and PAM, they will miss the place where real harm occurs: the API path. That is why the inventory of connected tools and identities must move into the same operational rhythm as access reviews and posture management.

Ephemeral agent behaviour creates a kind of identity blast radius that traditional recertification does not measure well. When an agent can issue valid but harmful actions between review cycles, the governance issue is not review cadence alone. It is whether your programme can observe and constrain runtime behaviour before the session completes.

With 98% of companies planning to deploy more AI agents within the next 12 months in the SailPoint research, the near-term risk is not adoption itself but unmanaged scale. Teams should prepare for more machine identities, more connected APIs, and more pressure on the controls that sit between them.

For practitioners

• Inventory every MCP-connected identity and tool path Build a live register of agents, MCP servers, downstream APIs, and the service accounts or tokens used to connect them. Classify each path by data sensitivity, command capability, and business criticality so shadow deployments are visible before they become permanent access paths.
• Scope tool permissions to the minimum viable action set Replace broad run-any-query or shared API keys with task-specific permissions, explicit tool allowlists, and separate identities for high-risk actions. Review whether any MCP server can reach operating system commands or sensitive records without a separate control boundary.
• Add behavioural detection for off-script agent activity Baseline normal agent sequences and alert when an agent suddenly changes query volume, exports data, touches new systems, or chains multiple privileged actions. Use behavioural evidence to supplement static posture checks, because valid API calls can still represent malicious intent.
• Treat STDIO-enabled MCP as privileged execution Where MCP interfaces can execute arbitrary commands, subject them to the same governance as administrative access. Require approval, monitoring, and stronger isolation before any agent can use that channel against production systems.

Key takeaways

• MCP servers turn AI agents into action-bearing identities, which makes API scope and runtime behaviour the real governance problem.
• The evidence points to a structural visibility gap, with most organisations unable to fully audit what their AI agents access or do.
• Security teams should treat MCP-connected paths as privileged access, then inventory, scope, and monitor them like any other high-risk identity flow.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• Behavioural Baselining: Behavioural baselining is the process of learning how an identity normally behaves so deviations can be detected as risk signals. The baseline usually includes device, location, timing, and action patterns, and it becomes more valuable when used after authentication rather than as a replacement for it.
• 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.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• The article's three-pillar operating model for seeing, governing, and protecting agentic infrastructure.
• The specific posture and protection patterns Salt associates with MCP server risk, including intent analysis and behavioural baselining.
• The vendor's own examples of how discovery, policy templates, and alerts are applied across AI agents, MCP servers, and APIs.
• The source article's compliance framing for EU AI Act and ISO 42001 alignment in agentic environments.

👉 Salt's full article covers discovery, governance, and protection patterns for agentic infrastructure.

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