The agentic stack exposes where AI agent risk actually lives

At a glance

What this is: This is an architectural analysis of the agentic stack, showing that AI agent security depends on the brain, tools, and action layer together, not just the model.

Why it matters: It matters because IAM, PAM, and broader governance teams need to control what agents can reach, not just what they can say, especially where autonomous API calls and tool-mediated access create new identity and privilege risk.

👉 Read Salt's analysis of the agentic stack and AI agent security

Context

AI agent security breaks when teams treat the model as the whole system. In practice, an agent is a chain of reasoning, tool access, and execution, so the control problem starts with identity and authorization, not with prompts alone. That is why the agentic stack matters for NHI governance, workload identity, and API access control.

Salt's framing separates the LLM, MCP servers, and APIs into distinct layers because each one creates a different failure mode. The security question is not whether the model is safe in isolation, but whether the agent's access path is bounded, observable, and revocable across the full sequence of intent.

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 chat-based AI systems create new identity risk for organisations?

A: Chat-based AI systems compress intent, delegation, and execution into one interaction, which makes privilege boundaries easier to cross without noticing. The risk is not only misuse of the model, but also over-scoped connectors, weak approval design, and unclear ownership of actions that begin in conversation but end in external systems.

Q: What breaks when MCP servers are over-permissioned?

A: When MCP servers are over-permissioned, the agent inherits broader access than its task needs, and a compromise in that layer can reach every connected system. The result is excessive blast radius, weak auditability, and poor separation between legitimate automation and abuse. Access scope should be narrowly segmented and revocable by workflow.

Q: What should teams do when agents can trigger internal API actions without review?

A: Teams should add runtime authorisation, transaction logging, and anomaly detection around the exact actions the agent can take. The main accountability question is whether the workflow can be approved, traced, and rolled back. If those controls are missing, autonomous execution can create business impact before a human sees it.

Technical breakdown

The LLM as the reasoning layer in agentic systems

The LLM is the agent's planning engine. It turns goals into stepwise actions, but it does not itself execute those actions. That distinction matters because prompt injection and output manipulation can change the agent's intent, yet the real business impact only appears when the downstream tool or API layer accepts that intent and performs a change. Security teams should therefore treat the model as one decision point in a larger chain, not as the whole control surface.

Practical implication: control model behaviour, but verify every downstream tool and API that can convert model intent into action.

Why MCP servers are the hands of the agentic stack

Model Context Protocol servers sit between the model and external systems. They expose capabilities, carry credentials or configuration, and determine which tools the agent can invoke. That makes them a high-leverage identity and authorization boundary. If an MCP server is compromised or over-permissioned, the attacker inherits the reach of every connected workflow, regardless of whether the LLM itself is behaving correctly. This is where non-human identity governance becomes operational, because the server effectively mediates machine access at runtime.

Practical implication: inventory MCP servers as privileged integration points and bind each one to explicit, minimal, revocable access.

The action layer is where autonomous intent becomes enterprise consequence

APIs are the action layer. They are where an agent reads records, writes data, triggers workflows, or initiates transactions. Agentic systems amplify API risk because they can generate many calls in a short time and do so without human review for each action. The article's key architectural point is that most agentic traffic is internal east-west traffic, which means perimeter tooling often misses it. In other words, the highest-risk control point is not the chat interface, but the authenticated path from agent to internal service.

Practical implication: monitor authenticated east-west API activity and apply policy to the actions the agent can actually complete.

Threat narrative

Attacker objective: The attacker wants to turn a seemingly legitimate AI agent into a high-speed execution channel that can access data, trigger workflows, or abuse internal systems.

1. Entry begins when an attacker manipulates an agent's reasoning layer or compromises the tool path the agent depends on, such as an MCP server or exposed API credential.
2. Escalation occurs when the attacker uses the agent's granted tool scope to issue more powerful calls than a human would normally make, often at machine speed.
3. Impact follows when the agent performs unauthorised reads, writes, workflow triggers, or transactions through internal APIs that perimeter controls do not observe.

NHI Mgmt Group analysis

Agentic governance debt is now an architecture problem, not a policy problem. The article shows that model safety alone cannot govern an agent that acts through external tools and APIs. Once control is distributed across the LLM, MCP server, and action layer, security teams need a layered governance model that tracks identity, privilege, and execution together. The practitioner conclusion is simple: if you cannot map the chain of intent, you cannot govern the agent.

MCP servers are emerging as non-human identity choke points. They are not just connectors. They are the runtime mediation layer that translates agent intent into authenticated access, which means they deserve the same scrutiny IAM teams apply to service accounts and privileged integrations. In practice, this creates a new governance boundary for access review, secrets handling, and revocation. The practitioner conclusion is to treat MCP servers as first-class identities in the control model.

Action-layer visibility is the missing control plane for agentic AI. Security programmes still over-index on prompts, while the real consequence occurs in east-west API traffic, where autonomous execution becomes business change. That makes API authorization, behavioral monitoring, and transaction-level auditability the decisive controls. The practitioner conclusion is that AI governance must extend into runtime access control, not remain trapped at the model layer.

Sequence of intent is the right named concept for this risk category. The article correctly points to the need to map the relationship between agent, tool, and API call before the action occurs. That is a different problem from logging after the fact, because chain-of-intent visibility determines whether the event is legitimate automation or hostile delegation. The practitioner conclusion is to build governance around relationships, not isolated events.

Agentic attack surface expands faster than review cycles can keep up. The article notes that teams are integrating MCP servers rapidly and often without central oversight. That creates a compounding governance gap where inventory, permissioning, and audit trails lag behind deployment. For identity and security teams, the practical conclusion is that discovery and entitlement governance must become continuous, not episodic.

What this signals

The practical shift for programme owners is that AI governance now needs to look like access governance. That means tying inventory, entitlement review, and runtime monitoring together, rather than treating model oversight as a separate discipline. The architecture described here aligns closely with the NIST AI Risk Management Framework, especially where accountability and monitoring must extend across the full system lifecycle.

Sequence-of-intent visibility is the emerging control gap for enterprise AI. If teams cannot reconstruct which agent used which MCP server to reach which API, they will struggle to prove legitimacy, investigate abuse, or enforce least privilege. This is where NHI governance, secrets management, and API authorization converge into one operational question: who or what was allowed to act, and under what scope?

For identity teams, the next milestone is not more model policy. It is better mapping between non-human identities, tool mediation, and internal service access. That makes agent inventory, access lineage, and transaction-level audit trails the controls most likely to survive scale, especially as agentic deployments accelerate faster than governance cycles.

For practitioners

• Map every agent to its MCP servers and APIs Build an inventory that records which agents use which MCP servers, which APIs those servers call, and what data or workflow each call can affect. This is the only way to see the full sequence of intent and identify over-broad reach before it is abused.
• Treat MCP servers as privileged integration identities Assign each MCP server a narrowly scoped credential set, review its permissions like a service account, and rotate or revoke access when the connected workflow changes. If the server can reach multiple systems, separate those paths rather than reusing shared credentials.
• Move monitoring to authenticated east-west API traffic Focus detection on API calls made inside the environment, not just perimeter traffic or chat prompts. Look for call volume spikes, unusual sequencing, and actions that exceed the expected business process for the agent involved.
• Apply policy to what the agent can complete, not what it can discuss Define allowed actions in terms of create, update, approve, transfer, or disclose, then bind those permissions to the specific service and dataset. That keeps the control model tied to business consequence rather than conversational output.

Key takeaways

• AI agent risk is distributed across the LLM, MCP server, and API layers, so model-only controls leave the real execution path exposed.
• Agent governance becomes an identity problem when tool mediation and API execution depend on credentials, permissions, and runtime scope.
• Practitioners need sequence-of-intent visibility, least-privilege tool access, and east-west API monitoring before agentic workflows scale further.

Key terms

• Agentic Stack: The layered architecture of an AI agent, typically described as reasoning, tool mediation, and execution. It matters because risk does not sit in one place. Security must govern the full path from intent to action, including identity, access, and observable runtime behaviour.
• 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.
• Sequence of Intent: The chain that connects an AI agent's goal, the tools it selects, and the API actions that result. The concept is useful because it lets defenders distinguish legitimate automation from harmful delegation, especially when actions happen quickly and through internal systems that are hard to observe.
• 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.

What's in the full article

Salt's full article covers the architectural detail this post intentionally leaves at the governance level:

• A layer-by-layer explanation of how the agentic stack routes intent from LLM to MCP server to API call.
• Examples of how east-west API traffic bypasses perimeter controls in real enterprise environments.
• Operational guidance on mapping sequence of intent across connected services and workflows.
• The vendor's view of why current security tools miss the highest-risk part of agentic execution.

👉 Salt's full post explains the LLM, MCP, and API layers in more operational 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 practitioners build the control model needed to govern autonomous systems, service accounts, and privileged integrations.