AI agent risk is moving from prompts to API actions

At a glance

What this is: This analysis argues that AI agent security now hinges on the action layer, where prompts become tool calls, MCP requests, and API activity.

Why it matters: IAM, NHI, and AI governance teams need to treat agent runtime visibility and authorisation context as core controls, not optional telemetry.

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%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Salt's analysis of AI agent action risk, MCP visibility, and API control

Context

AI agent security is not just a prompt-injection problem. The primary identity issue is that a single user request can traverse an application, an agent runtime, an MCP server, and one or more APIs before it produces a real business action, which makes traditional model-centric controls incomplete for agentic AI governance.

That matters for NHI, agentic AI, and IAM programmes because the authoritative control point is no longer only the model or the user interface. Security teams need to know which tools an agent can call, what permissions those tools inherit, and how to reconstruct the action chain when the agent touches data or triggers workflows.

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 AI agents complicate existing IAM and NHI controls?

A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary. That breaks assumptions built into static entitlements and traditional service account management. Governance has to account for delegated action, changing context, and auditability across the full execution chain.

Q: What breaks when agent governance stops at the LLM layer?

A: What breaks is visibility into the actual business action. The model may generate safe text while the agent still reaches a powerful tool, invokes a sensitive API, or triggers a workflow that changes records. Governance has to cover the execution layer, because that is where risk becomes impact.

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

A: Accountability sits with the governance chain that approved the access model, not with the agent alone. Teams need a trace from requester to policy decision to identity issuance to action results. If that chain is missing, incident review becomes guesswork and access governance cannot be defended to auditors.

Technical breakdown

Agent runtime to API chain: where AI agent identity becomes operational

An agentic application is a multi-layer system, not a single chatbot. The prompt enters an application layer, reaches an agent runtime, is interpreted by an LLM, and then drives tool use through built-in connectors, custom functions, or MCP servers. The security consequence is that intent, authorisation, and execution are separated across layers. By the time a downstream API is called, the original request may be several steps removed from the action that changes data or triggers a workflow. That makes the agent runtime and API layer the meaningful places to observe behaviour and assess whether the action matched the intended purpose.

Practical implication: map the full prompt-to-API chain before trusting any agentic workflow.

MCP servers as the hidden policy boundary for tool access

Model Context Protocol standardises how agents discover and call tools, typically through operations such as initialise, list tools, and call tool. That standardisation helps interoperability, but it also creates a new abstraction layer where visibility can collapse. A security team may see the final API request while missing which agent selected the tool, which MCP server executed it, and which upstream prompt initiated the flow. In practice, MCP servers become a policy boundary even when no one treats them that way. If the server exposes powerful tools without scoping, the agent inherits those capabilities at runtime.

Practical implication: treat MCP tool exposure as an access-control problem, not just an integration detail.

API visibility is now the control point for agentic governance

The article’s central technical claim is that agentic risk becomes visible when it reaches the API layer. API logs alone are not enough if they only show the request and response, because agentic systems need context across the LLM, MCP, tools, connectors, and downstream systems. The useful security graph is the relationship map between those layers, not isolated traffic records. For IAM and NHI teams, this means posture management must extend from identity objects to their runtime interactions, especially when agents can combine tool use with sensitive data access in ways that are legitimate individually but risky together.

Practical implication: build API-level detections that preserve upstream agent, tool, and prompt context.

Threat narrative

Attacker objective: The attacker wants a trusted agent to perform an authorised-looking but harmful action that moves data, changes records, or triggers workflow impact through legitimate infrastructure.

1. Entry begins when a user prompt is accepted by an agentic application and routed into the agent runtime through a normal interface such as a chat or workflow endpoint.
2. Escalation occurs when the agent selects tools, MCP servers, or custom APIs that grant it broader operational reach than the original request implied.
3. Impact follows when the agent triggers downstream actions such as data access, record updates, messaging, or workflow execution that produce real business change.

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

The governance failure is not prompt quality, it is action authority. Security programmes that stop at model safety assume the dangerous part of agentic AI is the text the model produces. In reality, the business risk appears when an agent is allowed to choose and execute a tool action that affects live systems. That shifts the governance question from answer correctness to runtime authorisation. Practitioners should treat every agentic workflow as an execution path that needs explicit access boundaries.

Agentic systems create an identity blast radius that traditional IAM reviews do not describe well. The same user request can fan out through an application, LLM, MCP server, and multiple APIs before any control point records the full context. That means the access decision is distributed across several systems, and the security team may not see the originating intent when the downstream action occurs. The implication is that visibility and accountability must follow the chain, not the interface.

Runtime context, not static permission sets, defines the real trust boundary for AI agents. A tool may be safe in isolation, yet dangerous when combined with an overbroad connector, sensitive data source, or downstream workflow. This is the point at which least privilege becomes harder to reason about because the agent can combine permitted capabilities in unexpected ways. Practitioners should evaluate the combination of tools, not only the permissions of each individual component.

OWASP-style agentic risk models are becoming necessary because the attack surface now includes tool discovery and delegated execution. The article’s architecture shows that prompts, LLM reasoning, MCP discovery, and API calls are all part of one operational chain. That is why governance has to extend into runtime visibility and contextual monitoring rather than stopping at content filtering. Teams that cannot trace the chain cannot explain the decision, and teams that cannot explain the decision cannot govern it.

From our research, AI agents are already behaving like unmanaged identities in too many environments. When agents can access systems, expose secrets, or trigger workflows beyond intent, the enterprise has an NHI governance issue, not just an AI safety issue. The right mental model is identity with delegated action, because that is what creates the blast radius. Security leaders should reframe agentic AI as a governed identity class with runtime consequences.

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.
• Another finding from the same research shows only 52% of companies can track and audit the data their AI agents access, leaving 48% without complete compliance and investigation visibility.
• For a broader control model, see OWASP Agentic Applications Top 10 for the runtime risks that emerge once tools, prompts, and delegated actions intersect.

What this signals

Agentic runtime visibility is becoming a programme-level requirement, not a nice-to-have telemetry layer. With 80% of organisations already seeing AI agents act outside intended scope, security leaders should assume that action drift will appear before perfect governance does. The practical response is to align AI governance, IAM, and API security around the same execution chain.

Identity blast radius will matter more than model quality in the next phase of agent deployment. If an agent can reach sensitive APIs through approved tooling, the question is no longer whether the model is intelligent enough. The question is whether its delegated access can be explained, contained, and reviewed in time to matter.

Agentic systems need an OWASP-style risk vocabulary and a NIST AI Risk Management Framework operating model. Without a shared language for tool misuse, prompt-to-action drift, and contextual authorisation, teams will keep treating symptoms instead of the underlying control boundary. The operating model should follow the action path, not the UI.

For practitioners

• Map prompt-to-API execution paths Inventory every step from user input to downstream API action, including the application layer, agent runtime, MCP server, connector, and final service. Keep the mapping current as tools and workflows change so investigators can reconstruct who or what caused each action.
• Scope MCP tools as privileged capabilities Review each MCP server for exposed tools, default permissions, and hidden access to sensitive data or admin workflows. Apply least privilege to tool exposure, not just to the agent process, and block tools that cannot be justified for a specific business task.
• Preserve agent context in API telemetry Retain the originating prompt, selected tool, MCP server, and agent identifier alongside each API event. Without that context, security teams can see activity but cannot determine whether the action was expected, risky, or induced by prompt manipulation.
• Separate model safety from action authorisation Do not rely on prompt guardrails alone to control agentic risk. Require explicit checks before tool invocation and downstream API execution, especially where an agent can access customer data, change records, or launch workflows.

Key takeaways

• The core risk in agentic AI is wrong action, not just wrong output, because delegated tools and APIs turn model decisions into business change.
• Enterprise evidence already shows widespread scope drift, with most organisations reporting AI agents acting beyond intended boundaries and many lacking full audit visibility.
• Security teams need runtime context across prompts, MCP servers, tools, and APIs, or they will be unable to explain and contain agent-driven actions.

Key terms

• Agentic Soc: An agentic SOC is a security operations model where AI systems assist with triage, investigation, and response using tool access and execution authority. The control challenge is not just accuracy, but governance of what the machine can see, decide, and do.
• 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 Runtime Authority: A runtime control model that evaluates an AI agent's request before it reaches a target system and can stop the action if it exceeds approved intent. It combines policy enforcement, session boundaries, and auditability so autonomy is constrained at the moment of execution.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• A layer-by-layer walkthrough of agent runtime, MCP, and API interactions that implementation teams can use to build telemetry requirements
• Specific examples of how contextual visibility is intended to help trace agent behaviour across connected tools and downstream services
• Discussion of how the security graph approach fits into posture management for agents, tools, connectors, and APIs
• Roadmap references to agentic protection features that are not detailed in this editorial analysis

👉 Salt's full post covers the agentic execution chain, security graph context, and real-time protection detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.