Action layer security is the missing control for AI agents

At a glance

What this is: This article argues that AI security is failing to keep pace with agentic systems because the real risk sits in the action layer, where agents use MCP servers and APIs to change systems.

Why it matters: For IAM and security teams, the key issue is that agent permissions, API trust, and runtime monitoring now need to be governed together across NHI, autonomous, and human identity programmes.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Salt's analysis of AI agent action-layer security

Context

AI agent security fails when teams treat the model as the control point and ignore what happens after the agent decides to act. The primary problem here is not prompt quality, it is governance over the APIs, MCP servers, and downstream systems that agents can reach. That gap matters because the same delegation pattern also applies to non-human identities, where authority is often broader than teams realise.

In practice, the article describes a shift from conversation security to action security. That is a real identity and access problem because agents behave like software identities with delegated reach, yet many organisations still monitor them as if they were only text interfaces. The starting position is increasingly typical, not unusual, which is why the control gap is now visible across both AI and IAM programmes.

For teams already working on NHI governance, the lesson is to map agent permissions as part of the broader identity estate, not as a separate AI-only concern. For AI security teams, the immediate challenge is to find where runtime actions are occurring, who authorised them, and whether those actions match policy.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do autonomous AI agents create more access risk than task bots?

A: Autonomous AI agents create more access risk because they can combine persistence, reactivity, and initiative. A task bot usually executes a narrow command, but an agent can preserve context, request more access, and act on changing conditions. That wider behavioural range increases the chance of overreach, unintended data exposure, and difficult-to-trace actions.

Q: What breaks when organisations only secure the model layer of agentic AI?

A: They miss the point where decisions become actions. A clean prompt and a safe response do not prevent an agent from calling an over-permissioned API, writing to a database, or sending a harmful workflow event. The result is a false sense of control over a system that is already operating elsewhere.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

What is the action layer in agentic AI?

The action layer is the part of an agentic system where the model stops generating text and starts causing real-world change. An LLM may choose a course of action, but the agent executes that choice through MCP servers, APIs, databases, email systems, or workflow tools. That makes the agent a runtime identity problem as well as an AI problem, because every action depends on credentials, permissions, and trust relationships outside the model. Security controls that only inspect prompts or responses will miss the actual abuse path if the risky step happens through a legitimate API call.

Practical implication: inventory the systems agents can reach and treat each connection as an access path that needs governance.

Why model-layer monitoring misses the real risk

Model-layer security is designed to detect unsafe prompts, leaked outputs, and jailbreak attempts. Those controls matter, but they do not observe whether an agent used an authorised integration to call an unfamiliar endpoint, chain harmless-looking requests into data exfiltration, or trigger a production change. In other words, they inspect intent, not execution. The blind spot grows when multiple downstream actions are individually valid but collectively harmful. That is why agentic security needs runtime visibility across traffic, baselines, and connected systems, not just LLM-side policy enforcement.

Practical implication: extend monitoring from prompts to runtime API behaviour, including unusual call sequences and payload patterns.

How MCP servers change the trust model

MCP servers act as the bridge between an agent and the tools it can use. They are useful because they standardise access to systems, but they also concentrate trust. If an MCP server is over-permissioned, shadow-deployed, or poorly inventoried, it becomes a high-impact route from AI decision-making into infrastructure action. The issue is not that MCP is inherently unsafe. The issue is that it extends agent reach into environments where identity lifecycle, privilege scope, and tool registration are often weak. That makes MCP governance a core part of both AI security and NHI control design.

Practical implication: register and review every MCP connection as if it were a privileged integration with explicit lifecycle ownership.

Threat narrative

Attacker objective: The attacker wants to turn legitimate agent execution into an unchecked path for data theft, workflow abuse, or operational disruption.

1. Entry occurs when an attacker compromises an agent, its connected credentials, or the downstream API path the agent already trusts.
2. Escalation happens when the agent uses legitimate permissions to call new endpoints, chain requests, or perform actions outside normal behavioural baselines.
3. Impact follows when those actions exfiltrate data, alter records, or trigger unauthorized operational changes in production systems.

Breaches seen in the wild

• McDonald's McHire AI Chatbot Default Credentials — Default credentials in McDonald's McHire AI recruitment chatbot expose 64 million job application records.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Action-layer security is now an identity governance problem, not just an AI safety problem. Once an agent can call APIs and trigger workflows, it behaves like a software identity with delegated authority. That means IAM and NHI teams must govern what the agent can do, not just what model it runs on. The field needs a control model that treats runtime action as the primary security boundary, because that is where loss, abuse, and misconfiguration become real.

Agentic trust gap: organisations are still monitoring the model conversation while the abuse is happening in connected infrastructure. This is the same failure pattern identity teams have seen in NHI sprawl: authority is granted broadly, then only partially observed after deployment. In AI systems, that gap is worse because actions can be chained quickly and hidden behind legitimate integrations. Practitioners should treat unobserved agent action as an access governance failure.

MCP governance is becoming the practical control plane for agentic systems. MCP servers compress multiple trust decisions into one layer of tooling and therefore deserve the same scrutiny that IAM teams apply to privileged connectors and service accounts. If teams do not know which servers are registered, shadowed, or over-scoped, they do not know where agent authority really lives. The next phase of AI governance will be decided by whether organisations can map and constrain these connections.

Runtime baselining will separate mature agent programmes from experimental ones. The important question is no longer whether an agent can do work, but whether the work it does is measurable, attributable, and policy-bound. Without behavioural baselines, anomaly detection becomes noise and access review becomes retrospective theatre. Teams that can correlate identity, tool access, and live traffic will have the only control view that matters.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For a related governance view, see OWASP NHI Top 10 for agentic application risk patterns and control focus.

What this signals

Action-layer visibility is becoming the dividing line between AI experimentation and AI governance. Teams that cannot observe runtime API traffic will not be able to explain what an agent actually did, which means they cannot defend access decisions, prove least privilege, or investigate abuse. That gap is now a programme risk, not a tooling inconvenience.

Agent behaviour needs to be governed like a privileged integration estate. The next practical step for many organisations is to align AI security with identity controls, secret management, and API governance, because those are the mechanisms that decide whether an agent can turn intent into impact. Where the control plane is missing, the operational blast radius is already larger than the model layer suggests.

If your programme already tracks NHI exposure, the same discipline should now extend to agentic systems. That means correlating permissions, connected tools, and live execution, then linking the resulting policy model back to identity governance and runtime monitoring.

For practitioners

• Map agent-to-system trust chains Document every API, MCP server, workflow engine, and downstream system an agent can reach, then assign an owner for each connection. Include shadow deployments and unofficial integrations so the map reflects actual runtime reach, not design intent.
• Baseline normal agent behaviour Define expected call patterns, frequencies, payload types, and sequence logic for each agent before you depend on it in production. Use those baselines to flag unexpected tool use, unusual call chains, and privilege escalation through legitimate integrations.
• Govern agent credentials as NHI Treat agent secrets, tokens, and service accounts as non-human identities with lifecycle ownership, rotation, and revocation rules. Tie each credential to a task scope so access ends when the workflow ends, not when the next review happens.
• Monitor runtime API traffic Extend detection beyond prompts to the live traffic that agents generate across Kubernetes, gateways, legacy systems, and cloud services. The aim is to spot abnormal execution paths, not just suspicious language.

Key takeaways

• The central risk is not what an AI agent says, but what it is allowed to do once it starts acting in production.
• Runtime visibility, behavioural baselines, and scoped credentials are the controls that determine whether agentic AI is governable.
• Identity teams should treat MCP connections and agent permissions as part of the privileged access estate, not as a separate AI concern.

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.
• 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.
• Configuration Baseline: The approved reference state for a system, policy, or controlled asset. A baseline defines what the environment should look like after a legitimate change. Security teams use it to compare current state against intended state and to spot drift, tampering, or incomplete implementation.
• Agentic Security Graph: An agentic security graph is a correlated view of agents, connected tools, infrastructure, and observed traffic. It helps teams understand where trust enters the system, how permissions flow, and which connections create the highest-risk paths from AI decision to production impact.

What's in the full article

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

• How its Agentic Security Graph correlates agents, MCP servers, technologies, and third-party vendors into one runtime view.
• What live traffic data and posture overlays are used to identify action-layer risk across connected systems.
• How the vendor describes behavioural baselining for agents across different infrastructure environments.
• Which implementation gaps it says most AI security tools miss when they stop at the model layer.

👉 Salt's full post covers the runtime visibility model, agent baselining, and infrastructure risks in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners translate identity controls into practical runtime governance for modern environments.