AI security risk is shifting from models to exposed action layers

At a glance

What this is: Salt says the AI security problem is moving from model behaviour to exposed action layers, especially APIs, MCP servers, and internal services that agents can reach and chain.

Why it matters: This matters because IAM, PAM, and NHI teams have to govern what AI agents can invoke, not just what they can say, or the blast radius of a compromise grows fast.

Context

The security gap here is not about model quality alone. It is about connected systems that were never designed to be safely invoked by software acting with decision-making latitude. When AI agents can reach undocumented APIs, internal services, or MCP servers, the attack surface becomes an access-control problem as much as an AI problem.

For IAM and NHI programmes, the shift is important because agent behaviour turns interface exposure into a governance issue. If an endpoint is callable, an agent may use it. That means authentication, authorisation, inventory, and lifecycle control become central to AI risk management rather than adjacent concerns.

Key questions

Q: What breaks when AI agents can reach exposed internal APIs?

A: The break point is governance, not just security tooling. Once an agent can call exposed internal APIs, it can chain permissions, query sensitive data, and trigger workflows at machine speed. That turns a single weak endpoint into a broad access path. Teams need to assume discoverability and chaining, then constrain each callable service with authentication, scoping, and runtime policy.

Q: Why do weakly governed action layers increase AI security risk?

A: Weakly governed action layers increase risk because agents do not need new exploits if existing endpoints already grant useful actions. A callable API, a misconfigured MCP server, or an exposed internal service becomes enough to access data or trigger workflows. The risk scales with reachability, not with model sophistication alone.

Q: What are the signs that an AI identity is failing governance even if access looks limited?

A: An AI identity is failing governance when teams cannot name an owner, explain why it exists, or trace what it did. Shared credentials, unclear purpose, missing retirement criteria, and weak attribution are strong warning signs. Those problems matter even if the identity only reaches low-risk data today, because the governance gap can expand quickly as integrations change.

Q: How should security teams govern API access for AI agents and service accounts?

A: Security teams should treat API access as a governed identity path, not a transport detail. That means assigning ownership to each machine consumer, limiting scopes to specific tasks, enforcing token binding where possible, and maintaining audit logs that tie every call to an identity and policy decision.

Technical breakdown

Why exposed APIs become the action layer for AI agents

An AI agent creates value by calling tools, not by generating text. In practice, that means it sits on top of APIs, service endpoints, and orchestration layers that translate intent into actions such as retrieving data, modifying records, or triggering workflows. If those interfaces are weakly authenticated or poorly inventoried, the agent inherits their exposure. This is why the action layer is the real enterprise control plane for agentic systems: the model may decide, but the interface executes. The security question is therefore not only whether the model is safe, but whether every callable path is known, authenticated, and bounded.

Practical implication: Inventory every agent-reachable endpoint and treat callable interfaces as privileged access paths.

How MCP servers and shadow integrations widen agent reach

MCP servers standardise how agents discover and invoke tools, but that also means misconfiguration can turn a convenience layer into a broad access bridge. Shadow integrations are even riskier because they may be connected informally, remain undocumented, or bypass normal security review. Once an agent can chain those services together, the issue stops being a single exposed API and becomes composite access across multiple systems. That creates machine-speed lateral reach through business workflows, especially where internal services were never scoped for agent consumption. The governance problem is exposure plus reachability, not just credential theft.

Practical implication: Apply least-privilege scoping and review every MCP server as if it were a privileged integration.

Why authentication and endpoint inventory now define AI security

Exposed APIs do not become dangerous only when a model is clever. They become dangerous when authentication is missing, weak, or inconsistently enforced across internal and external surfaces. Undocumented endpoints, forgotten services, and externally reachable admin paths all create the conditions for agent-driven misuse. Once an agent can probe and invoke at scale, small gaps produce large blast radius because the agent can discover and chain them faster than humans can monitor manually. The control problem is therefore inventory discipline, access enforcement, and continuous review of what is actually reachable.

Practical implication: Tie AI governance to API discovery, authentication assurance, and continuous exposure monitoring.

Threat narrative

Attacker objective: The objective is to use exposed action layers to reach internal systems, extract data, and trigger business actions that the organisation did not intend to expose.

1. Entry occurs when an AI system or agent can reach exposed APIs, MCP servers, or shadow integrations that were not designed for external invocation.
2. Credential or authentication weakness allows unauthenticated or weakly governed access to internal actions, data, and workflows.
3. Escalation happens when the agent chains multiple reachable services together, turning single exposed endpoints into broad operational access.
4. Impact is large-scale exposure or manipulation of data, prompts, accounts, files, and business workflows at machine speed.

Breaches seen in the wild

• 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.
• 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.

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

Action-layer security is now the real control problem for AI systems. The model may generate output, but the exposed interfaces determine whether that output can become a harmful action. That makes API governance, service inventory, and access scoping the practical center of AI risk management. For identity teams, the key point is that agent permissions are not abstract policy objects, they are executable trust relationships.

Shadow APIs create governance debt that AI agents can monetise immediately. Uncatalogued endpoints, forgotten internal services, and lightly reviewed integrations are no longer just hygiene issues. Once an agent can discover and call them, they become live pathways into sensitive data and workflows. Practitioners should treat undocumented reachability as an active exposure, not a dormant configuration problem.

MCP changes the blast radius of internal tools by making invocation easier. A misconfigured MCP server is not just a tooling issue, it is a potential privilege bridge between an agent and downstream systems. The more business logic sits behind generic tool interfaces, the more important it becomes to govern those tools as privileged access points. The implication is clear: control the tool layer or accept agent-scale exposure.

AI security programmes need a named concept for this risk: shadow action layers. This is the zone where exposed APIs, connected services, and agent-facing tools sit outside normal governance even though they can execute real business actions. The field needs to stop framing AI risk as model safety alone and start measuring action-layer exposure as a first-class governance metric. That shift belongs in IAM, PAM, and NHI operating models alike.

Identity governance has to extend to non-human callers, not just human users. An AI agent can only act through credentials, tokens, and service permissions, which means its security posture is inseparable from NHI governance. If identity programmes do not inventory and scope those machine-facing permissions, they leave the action layer open by design. The practitioner conclusion is to govern agent access with the same rigor used for privileged service accounts.

From our research library:

• Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
• Read next: AI Agent Authorisation Guide

What this signals

Shadow action layers are now a practical governance problem, not an abstract AI risk theme. Once an agent can discover a reachable endpoint, the question becomes whether the endpoint was ever designed to be invoked by a machine identity with delegated authority. The programme response is to bring API discovery, entitlement scoping, and service ownership into the same control plane.

The evidence from the wider market is moving in the same direction. Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey. That gap is large enough to make access scope the most important AI governance variable for practitioners.

For identity teams, the next step is to treat agent-facing APIs and MCP servers as governed assets with owners, review cycles, and revocation paths. The more those components are hidden inside “internal” workflow assumptions, the more likely they are to expand blast radius before anyone notices.

For practitioners

• Map every agent-reachable API Build an authoritative inventory of APIs, service endpoints, and MCP servers that an AI system can reach, including forgotten and shadow integrations.
• Scope agent permissions to specific workflows Limit each AI agent to the minimum set of actions and data paths needed for its task, and review those entitlements as privileged access.
• Enforce authentication on internal action surfaces Require strong authentication and explicit authorisation for every endpoint that can trigger a business action, even when it was originally internal-only.
• Review MCP servers as privileged integrations Treat each MCP server as a governed access path, with ownership, documented purpose, and periodic recertification of the tools it can invoke.
• Continuously monitor exposed action layers Use exposure scanning and configuration review to catch newly reachable services, unauthenticated endpoints, and external admin paths before agents find them.

Key takeaways

• AI security risk is moving from model behaviour to the action layer, where exposed APIs and connected services decide what an agent can actually do.
• Undocumented endpoints, weak authentication, and shadow integrations create blast radius far faster than prompt issues alone.
• IAM, PAM, and NHI governance now need to cover agent-reachable services, not just human users and traditional workloads.

Key terms

• Action Layer: The action layer is the point where an identity moves from asking for access to doing something with that access. For AI agents, this layer matters because tool use can happen faster than human review, and the meaningful risk appears when actions are chained across systems.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• 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.
• Machine Identity Governance: Machine Identity Governance is the discipline of controlling how non-human identities are created, used, monitored, and retired. It covers service accounts, API keys, certificates, tokens, workloads, and automation identities, with policies for ownership, lifecycle, least privilege, rotation, attestation, and auditability across cloud, application, and infrastructure environments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps practitioners connect delegated access controls to broader identity and security programmes.