Executive Summary
- The Agentic Stack consists of three layers: The Brain (LLM), The Hands (MCP Servers), and The Action Layer (APIs).
- AI Agents differ from chatbots because they don't just talk; they autonomously execute multi-step workflows through these layers.
- Security Risk propagates across the stack, meaning a "healthy brain" can still execute malicious actions if the Hands or Action Layer are unsecured.
- The Action Layer is the primary control plane for security, as it is where autonomous intent becomes enterprise consequence.
The term AI agent is dominant in current cybersecurity discourse. Vendors, analysts, and CISOs all use the label, yet technical confusion remains regarding how agents actually operate and where the security risks reside. Beneath the surface-level familiarity, there is often significant confusion about what an AI agent actually is, how it operates technically, and most importantly for security teams, where the risk actually lives.
To make informed security decisions, organizations must look past the interface and understand the underlying architecture. This architectural framework is known as the Agentic Stack. This piece is not about any particular vendor or platform. It is an attempt to map the architecture clearly, because you cannot make good security decisions about a system you do not fully understand.
What is an AI agent?
An AI agent is a software system designed to autonomously pursue goals by reasoning through a task and executing actions using external tools.
At a high level, we can describe an AI agent as a system capable of reasoning about its environment to autonomously pursue a goal by selecting actions and executing them using the tools and services it has access to. The ability to execute actions distinguishes an agent from a standard chatbot or a basic AI assistant. While a chatbot generates text responses, an agent performs work.
These actions can include searching the internet, running a database query, sending an email, updating a CRM record, triggering a financial workflow, or calling an external web service. The agent can string together many actions to pursue a goal. It can decide what to do at each step based on the outcome of the previous step.
That capability is also what makes agents powerful enough to be worth deploying at enterprise scale. And it is what makes them fundamentally different from the AI systems that came before them. This autonomy creates a fundamental shift in the enterprise attack surface. Security teams are no longer just protecting user-to-application traffic. They are protecting agent-to-agent (A2A) and agent-to-API workflows.
The Three Layers of the Agentic Stack
To understand how agents work and where they can go wrong, it helps to think of them as a three-layer system. Each layer has a distinct function, a distinct set of technologies, and a distinct risk profile. The Agentic Stack consists of the brain, the hands, and the action layer.
Layer 1: The Brain (The LLM)
The Large Language Model (LLM) serves as the agent's brain. Given a goal or instruction, it reasons about the steps it needs to take to achieve it and the tools it should use at each step. It learns and adapts based on the results of its previous actions and the context of its environment.
The LLM is the layer that most people picture when they think about AI security. Concerns about prompt injection, where malicious content in the environment manipulates the model’s behavior, live here. So do questions about model alignment, output safety, and guardrails. These are real and important concerns.
However, they are only one of three layers. A well-secured LLM connected to poorly secured tools and services remains vulnerable. The brain can be perfectly healthy while the hands and the action layer remain exposed. The model provides the intent, but it does not execute the change. If an attacker can manipulate the reasoning process, they can, in theory, force the agent to hallucinate a need to perform a malicious action, but the actual damage occurs elsewhere in the stack.
Layer 2: The Hands (MCP Servers)
Model Context Protocol (MCP) is an open standard that has emerged as the primary way AI agents connect to external tools, data sources, and services. If the LLM is the brain, MCP servers are the hands.
The MCP server acts as an intermediary between the LLM and the outside world. It exposes a list of capabilities that the agent can invoke. These capabilities can include reading a file system, making a database query, calling a service, sending a notification, or triggering a workflow. Without MCP servers, an agent can think but cannot act. With them, it can reach into virtually any system the organization connects it to.
From a security perspective, MCP servers are significant for several reasons:
- Authorization Scope: Defines the scope of what an agent can do and handles authentication to the services it connects to.
- Credential Management: They may carry their own configurations, credentials, and permission settings.
- Visibility Gaps: Because they sit between the model and the systems it interacts with, a misconfigured or compromised MCP server gives an attacker leverage over everything the agent can reach.
The MCP ecosystem is expanding rapidly. Teams are integrating them into agent workflows, often without centralized oversight. This means the set of tools any given agent can access is growing faster than most organizations can track. MCP servers determine what an agent can touch, making them one of the highest-leverage points in the entire stack.
Layer 3: The Action Layer (APIs)
APIs represent the Action Layer. This is the actual interface through which agents interact with enterprise systems, data, and workflows. When an agent reads a customer record, it calls an API. When it writes to a database, it calls an API. When it triggers a financial transaction, initiates a deployment, or sends a message, it calls an API.
APIs are not new. Enterprises have been building and managing API estates for decades. But AI agents change the nature of API risk in two important ways.
First, agents dramatically increase the volume and velocity of API calls. Where a human user might make a handful of API calls per session, an agent pursuing a complex goal might make hundreds in minutes. That scale amplifies the consequences of any vulnerability or misconfiguration in the APIs the agent can reach. If an API has a Broken Object Level Authorization (BOLA) vulnerability, an agent can exploit it at a scale and speed that no human could achieve.
Second, agents make API calls autonomously, without a human reviewing each action before it executes. Important authorization decisions, such as whether a system should perform a specific action now, are made by the agent based on its goal and permissions. If those permissions are too permissive, or the API endpoints they have access to are not properly secured, there is ample opportunity for unintentional or intentional wrongdoing.
It is also worth noting where API activity actually occurs. The majority of agentic API traffic is internal "east-west" communication between services within the enterprise environment. This traffic moves through systems that perimeter security tools were never designed to observe. Edge-based security, such as WAFs, gateways, and API proxies at the network boundary, simply does not see most of what agents are doing at the action layer.
How the Agentic Security Graph Connects the Layers
Understanding the three layers individually is important. But the more significant insight is how they interact, because vulnerabilities in one layer create risk that propagates through the others.
A manipulated brain issues malicious instructions to the hands (the MCP server). Those hands then execute those instructions via an API call at the action layer. A compromised MCP server can redirect what APIs the agent calls and what actions it takes, regardless of what the LLM intended. And vulnerable APIs at the action layer can be exploited directly, bypassing the model and MCP layers entirely, by any system or agent that can reach them.
This interdependence is what makes the agentic stack a genuinely new security challenge rather than a variation on existing ones. Point solutions that address only one layer leave the other two exposed. Also, since each layer bridges and relies on the other layers, a failure in one pillar is a failure of the framework itself.
To stop these attacks, security teams need visibility into the "Sequence of Intent." This requires mapping the relationships between specific agents, the MCP servers they utilize, and the APIs they call. We refer to this map as the Agentic Security Graph. Without this context, a security team cannot distinguish between a legitimate complex workflow and a malicious exploitation of the stack.
What This Means for Security Teams
For security practitioners trying to get ahead of agentic risk, the architecture described here points to a clear set of requirements:
- Visibility Across All Three Layers: Security cannot be siloed into just the model or just the perimeter. You need to see the full path from the LLM prompt to the final API call.
- Complete Inventory: You must maintain an inventory of all agents, MCP servers, and APIs operating in the environment. You cannot secure what you cannot see.
- Relationship Mapping: It is essential to understand the "line of credit" each agent has. Which agents connect to which MCP servers? Which MCP servers call which APIs? What data and systems do those APIs access?
- Continuous Behavioral Monitoring: Monitoring must happen across the full stack, not just at the edge. This requires analyzing the intent behind API calls to identify when an agent is being manipulated or is malfunctioning.
- Contextual Risk Assessment: Risk should be assessed based on what each agent can actually do (its potential impact on the action layer), not merely on its existence.
The agentic stack is not especially complicated once you see it clearly. But most security frameworks and tools were built before it existed, and they reflect that. Closing the gap starts with understanding the architecture, all three layers of it, and building a security approach that covers the full picture.
If you want to learn more about Salt and how we can help you, please contact us, schedule a demo, or visit our website. You can also get a free API Attack Surface Assessment from Salt Security's research team and learn what attackers already know.