AI security risk is shifting from models to exposed action layers

At a glance

What this is: This is an analysis of why AI security risk is moving from model behavior to the connected action layer, with exposed APIs and MCP-connected services creating the biggest blast radius.

Why it matters: It matters because IAM, PAM, and NHI governance now have to cover agent-to-API access, not just human users or model prompts, or organisations will miss the real control point.

By the numbers:

• 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%).
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Salt's analysis of AI agents, exposed APIs, and the action-layer attack surface

Context

AI security becomes materially different once systems can take actions rather than only generate text. In that model, the risk is not limited to prompt abuse or model output manipulation. The larger governance problem is the action layer, where agents call APIs, reach internal services, and inherit permissions from poorly scoped integrations and shadow connections.

The article argues that many enterprises are still defending the model while leaving the surrounding access paths open. That is a genuine identity and access issue because AI agents, connected tools, and MCP servers behave like non-human identities with delegated reach. When those identities are not scoped, inventoried, and monitored, the attack surface expands faster than the security model around it.

The McKinsey and McDonald’s examples used here are typical of a broader pattern rather than isolated exceptions: exposed or weakly governed APIs become the easiest place for agent-driven abuse to turn into operational impact.

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 AI agents complicate traditional IAM and PAM controls?

A: AI agents complicate IAM and PAM because they can make decisions, chain tools, and act faster than human review cycles can respond. They also blur the line between authentication and authorization, since the same identity may trigger multiple actions after a single approval. That means organizations need policy, telemetry, and revocation designed for autonomous behavior, not just human login events.

Q: What do security teams get wrong about AI access risk?

A: Many teams focus on the model while ignoring the identity path that reaches it. If a service account or token can invoke AI infrastructure, then that credential becomes the real control point. The mistake is treating AI risk as a model problem instead of an access governance problem.

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Technical breakdown

Why the action layer matters more than the model layer

An LLM produces content, but an AI agent can also invoke tools, call APIs, read data, and trigger workflows. That makes the agent a control-plane participant rather than just a model consumer. Security teams often focus on jailbreaks and unsafe prompts because they are visible and testable, but the real enterprise exposure sits where the agent is allowed to act. If the surrounding services are weakly authenticated, over-permissioned, or poorly documented, the model becomes a path to the system rather than the system itself.

Practical implication: Map every action the agent can take to a named owner, authenticated service, and explicit access policy.

How exposed APIs and shadow integrations expand blast radius

An exposed API is any reachable interface that accepts requests without the governance expected for its sensitivity. In AI environments, that becomes dangerous when internal or undocumented endpoints are reachable through workflow tools, browser agents, or MCP servers. Once an agent can discover and chain those endpoints, even a modest access path can become high impact because machines can enumerate and reuse calls at speed. The problem is not only exposure, but the combination of exposure, weak scoping, and machine-scale chaining across services.

Practical implication: Inventory externally reachable APIs and remove agent access to any endpoint that lacks strict authentication, rate limits, and scope boundaries.

What MCP changes in enterprise governance

Model Context Protocol gives agents a standard way to connect to tools and data sources. That is useful for interoperability, but it also concentrates risk if the connected servers inherit broad or implicit access. An MCP server that exposes credentials, undocumented tools, or broad read-write functions can become a high-leverage bridge into internal systems. Governance therefore has to treat MCP servers as first-class identity and access surfaces, not as neutral plumbing. Without that, the protocol becomes an accelerator for privilege misuse.

Practical implication: Treat each MCP server as a governed workload identity and review its permissions, secrets, and reachable tools on a recurring basis.

Threat narrative

Attacker objective: The attacker wants to turn a single exposed integration into broad access to sensitive data, internal systems, and automated workflows.

1. Entry occurs when an AI agent reaches an exposed or weakly authenticated API, MCP server, or shadow integration that should not have been externally reachable.
2. Escalation follows when the agent or attacker chains the reachable endpoints, using overbroad permissions to move from one service to another and collect sensitive context.
3. Impact occurs when the action layer is used to access, expose, or manipulate internal data and workflows at machine speed, expanding the blast radius far beyond the original entry point.

NHI Mgmt Group analysis

AI security has shifted from prompt safety to action governance. The central mistake in many enterprise programmes is treating the model as the primary risk object. In practice, the material control point is the connected action layer, where AI systems call tools, invoke APIs, and inherit privileges. That moves the problem into IAM, PAM, and NHI governance territory because the real question is who or what is authorised to act. Practitioners should now measure AI risk by reachable actions, not only by model output quality.

Shadow APIs are becoming the new hidden privilege surface. When APIs were internal, undocumented, or lightly governed, they were already risky. Once connected to agents or MCP servers, they become machine-discoverable and chainable, which materially changes their threat profile. Shadow API exposure: the point at which forgotten or weakly governed services become an active enterprise attack surface once agents can reach them. Practitioners should assume that any reachable endpoint can be found and abused once agent connectivity is introduced.

MCP security is an identity problem as much as a protocol problem. MCP servers can simplify integration, but they also concentrate trust if server permissions, secrets, and tool scopes are not tightly governed. That means workload identity, secrets management, and access scoping have to be handled together, not as separate operations. In NHIMG terms, this is where agentic AI security and NHI governance converge. Practitioners should classify every MCP endpoint as a privileged machine identity and enforce least-privilege from the start.

The market is still underweight on runtime containment for agentic systems. Most current AI security conversations remain focused on pre-deployment review, model governance, or content filtering. Those controls matter, but they do not stop a trusted agent from abusing an overexposed endpoint. The discipline is now moving toward runtime authorisation, asset discovery, and scoped delegation across the AI stack. Practitioners should re-evaluate whether their current control set can actually constrain machine-speed action, not just human-reviewed prompts.

What this signals

Action-layer governance will become the practical test for AI security programmes. The organisations that can inventory callable services, map agent permissions, and monitor runtime usage will be able to contain agentic risk more effectively than those still relying on prompt filters alone. That is also where identity and access teams gain influence, because the control surface is now closer to NHI governance than to model tuning.

Shadow API exposure will increasingly behave like undocumented machine privilege. Once agent workflows are allowed to discover services dynamically, governance teams need to watch for endpoints that were never designed for external use but now function as part of the attack surface. The next maturity step is not only discovery, but continuous review of service reachability and delegated scope.

Enterprises should expect AI security programmes to converge with workload identity, secrets management, and API governance. The strongest signal of maturity will be whether a programme can explain, in operational terms, which machine identities can act, on what services, and under what limit. That is the control model agentic systems now require.

For practitioners

• Inventory every AI-reachable API Build a complete list of APIs, internal services, and MCP servers that any agent, copilot, or automation workflow can reach. Classify each endpoint by authentication, sensitivity, and whether it is externally reachable or shadowed by undocumented use.
• Scope agent permissions to named tasks Require each agent to operate with task-scoped access, not broad service permissions. Tie every tool call to an owner, an approved business purpose, and explicit limits on read, write, and administrative actions.
• Remove unauthenticated or weakly governed interfaces Prioritise exposed endpoints that accept requests without strong authentication, rate limiting, or policy enforcement. If an endpoint cannot be defended at runtime, disconnect it from agent workflows until controls are in place.
• Treat MCP servers as governed machine identities Assign each MCP server an owner, a secrets policy, and a permission review cycle. Review which tools it can expose, which data sources it can query, and whether any credentials are stored in configuration files.

Key takeaways

• The real AI security risk is moving from model behaviour to the action layer where agents can call APIs, services, and workflows.
• Exposed or weakly governed APIs create the largest blast radius because agents can discover and chain them at machine speed.
• Identity teams need to govern agents, MCP servers, and tool permissions as privileged machine identities, not as passive integrations.

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.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.

What's in the full article

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

• A vendor walkthrough of exposed API discovery for AI-connected services and internet-reachable endpoints.
• A deeper explanation of the McKinsey and McDonald’s incident patterns as application-layer failures, not model-layer failures.
• Operational guidance on where Salt Surface fits in exposure mapping for AI-related workflows.
• The article's own framing of how organisations should assess action-layer blast radius in live environments.

👉 Salt's full post covers the McKinsey and McDonald’s examples, exposed API risk, and the action-layer controls it recommends.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity control to the systems and services that now carry machine access risk.