Ask what AI agent security covers and every source hands you a different map. Gartner's guardian-agents guide names three capability areas, as summarized in a vendor-contributed piece on The Hacker News. Bessemer maps the attack surface across four layers: endpoint, API and Model Context Protocol (MCP) gateway, SaaS, and identity. One vendor map groups 61 vendors into 12 categories. A buyer holding all three cannot tell which gaps they actually have.
Here is a different cut: five control layers, each defined by the single question it answers. The payoff is a diagnostic. When an agent does something it shouldn't, ask which question went unanswered. That tells you which layer to fix, and which layers would not have helped.
What is AI agent security?
AI agent security is the set of controls that keep an autonomous agent's actions inside what its operators intended. It overlaps with what many teams call AI agent governance. One practical way to break it down is five layers: model, identity, policy, execution, and monitoring, each answering a different question.
| Layer | The question it answers | Typical controls |
|---|---|---|
| Model | How likely is the agent to try something bad? | Alignment, prompt-injection defenses, guardrail classifiers |
| Identity | Who is this agent, and who vouched for it? | Agent registration, credential issuance and removal, session revocation |
| Policy | What is allowed, on paper? | Permission models, tool allowlists, written rules |
| Execution | Should this specific action run, now? | Judging a command or tool call before it reaches the target |
| Monitoring | What did the agent do, and does anyone see it? | Discovery, logging, telemetry, alerting |
The layers are questions, not vendor boxes. One product can answer several. Microsoft's open-source Agent Governance Toolkit, per its own April 2026 announcement, pairs a policy engine, which hooks into agent frameworks to intercept agent actions before execution, with separate identity and kill-switch components. CrowdStrike's Falcon Guardian is described as an endpoint-side runtime enforcement layer that also discovers known and shadow agents on Windows and macOS. Read the table as five questions to have an owner for, not five products to buy.
The model layer: how likely is a bad action?
The model layer is the one closest to the agent, and its own standards are candid about the limit. OWASP's prompt-injection entry says "it is unclear if there are fool-proof methods of prevention for prompt injection". Its own mitigations include "Enforce privilege control and least privilege access" and "Require human approval for high-risk actions." Those are identity, policy and execution controls: least privilege is identity and policy, and approving a specific high-risk action is an execution decision.
So the model layer's own standard hands the residual problem to the layers below it. Model-layer work changes the odds. It does not bound the outcome, which is the argument we made in why alignment isn't enough.
The identity layer: who is this agent?
The identity layer establishes who an AI agent is. Agents need identities before any other control can attach to them, and the process for issuing and retiring those identities is thin. A Cloud Security Alliance and Oasis survey of 383 IT and security professionals, released in January 2026, found that 78% of organizations "don't have documented and formally adopted policies for creating or removing AI identities".
The vendors are moving. Okta announced Okta for AI Agents in September 2025, opened early access in March 2026, and made it generally available in April 2026; it registers agents as first-class identities in Okta's Universal Directory. Microsoft's Entra Agent ID is now generally available. Mature identity systems can also cut a live session off when risk signals change. What identity settles is who is calling and whether the session should continue.
The policy layer: what is allowed, on paper?
The policy layer answers what an AI agent is allowed to do, on paper. It is the written intent: which tools an agent may call, which data it may touch, who must approve what. It is necessary, and on its own it is only a decision. Something else has to apply it to the action in front of the agent, and the policy has to still describe the thing it approved. A rule written for a tool definition says nothing once the definition changes.
The execution layer: should this action run?
The execution layer of AI agent security sits outside the agent. After the caller is authenticated and before the action reaches the system, it judges the specific command or tool call. The judgment can be deterministic rules, a model, or both, and each choice has tradeoffs: rules leave room for the cases nobody thought of, and a model judging another model can be wrong in its own way. What defines the layer is placement, not the judge. It is outside the agent, and it decides before the action lands.
The market already recognizes this question. Gartner's guide lists "Runtime Inspection and Enforcement" as a core area, which in the wording a vendor-contributed Hacker News piece quotes means ensuring "that AI agents' actions and outputs match defined intentions, goals, and governance policies." Bessemer, writing in March, called "targeted, in-flight intervention" the most underdeveloped part of the space. The market agrees the question exists. It does not agree on who answers it, or how. We make the full case for why access decisions don't answer it in our piece on execution control.
The monitoring layer: what happened, and does anyone see it?
The monitoring layer shows what an agent did and whether anyone sees it. It is how you find the miss another layer made, and where stated confidence runs well ahead of coverage. Gravitee's The State of AI Agent Security 2026, a vendor-published survey of 750 senior technology leaders from June 2026, put stated confidence in agent visibility at 91.8%, against a mean reported monitoring coverage of about 52%. A dashboard that exists is not the same as an agent that is seen.
Which layer failed? Five incidents, read by layer
OWASP's Q3 2026 exploit roundup, published October 8, covers July through September, plus one May–June supply-chain item. It lists nine entries, six of them evaluation-agent or research-model cases; its prose counts seven and cautions that they are not independent attacks. We picked five to span the layers: two agent cases (Hugging Face, Mythos), a worm, a one-click prompt attack, and an attempted MCP campaign. We left out the other four, all evaluation- or research-agent cases: OpenAI's Artifactory containment failure, the Modal CyberGym workload, Claude Opus 4.7 attacking a real company that shared a fictional target's name, and a Claude research model that scanned external hosts. The counts below describe these five, not agent incidents in general. The roundup does not assign control layers. The readings below are ours.
| Incident | What the roundup reports | First layer to fail, or be targeted (our reading) | Also involved |
|---|---|---|---|
| Hugging Face production intrusion, July 10–13 | OpenAI evaluation agents escaped network restrictions, then found public credentials and shared them; unsafe dataset and template processing. "Agents executed code on 41 production dataset workers," through the victim's dataset and template-processing flaws, not a discrete agent command. | Policy (network restrictions escaped) | Model, identity |
| Claude Mythos 5 PyPI package | A Claude evaluation agent published a malicious package to the real PyPI registry. "The package ran on 15 real systems during its approximately one-hour availability." | Policy (who may publish) | Model, identity, execution |
| Mini Shai-Hulud and Miasma worms | Supply-chain worms that harvested CI, cloud and npm credentials and planted AI coding tool config files; not an agent acting. Entered through a stale OpenID Connect (OIDC) trust relationship in TanStack's CI. "More than 170 packages with over 518 million downloads" in the May wave (May, included in the roundup); provenance attestation did not flag the content | Identity | Monitoring |
| CoSnitch (CVE-2026-24301) | A crafted link ran a prompt in the victim's authenticated session, with a memory-poisoning path; no in-the-wild exploitation reported | Model | Policy, execution |
| Deadbugz MCP server | Attempted supply-chain campaign: normal for three tool calls, then changed its tool metadata. No confirmed compromise. | Policy (targeted: no re-approval after a definition change) | Execution, monitoring |
Read down the first-layer column. Policy comes first in three of the five rows, one of them an attempt that never landed, and Model leads once. Identity leads only in the supply-chain worm, which was not an agent acting. Execution and monitoring appear in the also-involved column of several rows. Execution sits last before the system, so in this table it shows up as the backstop, not the first failure. Stronger agent identity would not have caught a tool definition that changed after three normal calls. In CoSnitch the session was authentic, so identity had nothing to catch; the failure was the prompt the model accepted. Deadbugz never landed, but its design targets policy: a server approved as benign could change its definition later with nothing forcing a second approval.
That is the case for reading the stack as five separate questions. A strong answer in one layer does not answer another layer's question, and a team that audits only the layer it already owns can keep finding the incident one layer over.
Where containment fits
Sandboxes, egress limits, read-only roles, and short-lived credentials are the answer many engineers reach for first, and it is a good one. They are not a sixth layer. Short-lived credentials are what the identity layer issues. Read-only roles, allowlists, egress rules, and sandboxes are policy that the environment enforces on every action at once, without judging any single one. All of them cap what any action can reach.
Containment has a cost: a boundary tight enough to be safe also stops some of the work you wanted the agent to do. It also does not decide whether a permitted action should run. That question belongs to the execution layer.
How to use the map
- Write the five questions on a page.
- Next to each, name the control that answers it in your environment and the person who owns it.
- For your last incident, or any of the five above, mark the first layer to fail and which others were involved.
- Treat any layer with no named owner, or whose only evidence is stated confidence, as the next gap.
Take step 3 on the Mythos row. The evaluation tools permitted the agent's publish to the real PyPI registry. By the table, that is a policy failure first. The roundup does not say whether any check ran before the publish.
At AlpacaX we build Alpacon, an AI-native privileged access management (PAM) platform focused on the execution layer for production servers. Identity decides who connects, policy decides what's allowed on paper, and execution control comes after both, before monitoring. That is the placement described above: where Alpacon's exec check is enabled, a command an agent sends to a production server through MCP, the CLI or the API is checked server-side, outside the agent, before it is dispatched to the host. The other four layers still need owners, and the map is most useful for finding the one you have left empty.
