Note on OWASP guidance status
OWASP's agentic AI security guidance continues to evolve through community review. Confirm current category definitions and recommended mitigations directly from OWASP's published project documentation before using any named taxonomy as a fixed audit checklist.
Why Agentic AI Requires a Distinct Risk Model
Traditional LLM security guidance, including the established OWASP Top 10 for LLM Applications, focuses largely on single-turn risks: prompt injection, output handling, and training data exposure within one request-response cycle.
Agentic AI systems change this shape significantly. An agent plans a sequence of steps, invokes external tools or APIs, retains state across those steps, and takes actions with real downstream effects. This shifts the attack surface away from model output review alone and into tool invocation, permission scope, and cross-step state management.
Security teams evaluating agentic AI guidance should expect coverage of autonomy, tool access, and agent identity in addition to prompt-level risks. Because this guidance area is still maturing, teams should confirm the current published scope and category definitions directly from OWASP's project documentation before using any version as a fixed audit checklist.
Agent Workflow Stages and Where Risk Concentrates
Risk in agentic systems does not distribute evenly. It concentrates at the boundaries where the agent transitions from planning to action, where it acquires or delegates permissions, and where it reads from or writes to persistent state. Understanding those inflection points is a prerequisite for prioritizing controls.
- Planning stage: The agent interprets instructions and formulates a sequence of steps. Adversarial inputs introduced here can redirect the entire downstream plan.
- Tool invocation stage: The agent calls external APIs, functions, or services. This is where malformed calls, schema drift, and unchecked side effects manifest.
- State and memory access: The agent reads from and writes to short-term context or long-term memory stores. Manipulation at this stage can affect future sessions, not just the current one.
- Multi-agent coordination: One agent delegates to or communicates with another. Trust boundaries between agents are a primary source of privilege escalation risk.
- Result delivery and action execution: The agent writes files, sends messages, or triggers workflows. The blast radius of errors or compromise is determined largely by the permissions held at this point.
Common Risk Domains in Agentic AI Security
Across current agentic AI security discussion, including OWASP's evolving work, several risk domains recur consistently. The table below summarizes each domain and its primary concern.
| Risk Domain | Primary Concern |
|---|---|
| Tool Invocation | Agents invoking tools or APIs with insufficient input validation, schema drift, or unchecked side effects, allowing unintended or malicious actions to execute. |
| Excessive Agency | Agents granted broader permissions or autonomy than a given task requires. If the agent is compromised or misdirected, the blast radius is larger than necessary. |
| Identity and Permissions | Agents operating without a distinct identity, scoped permissions, or an audit trail. Without per-agent attribution, it is difficult to contain or attribute a given action. |
| Memory and Context Integrity | Persistent memory or retrieved context being manipulated to alter agent behavior in future sessions, not just in the current interaction. |
| Multi-Agent Trust | Interactions between autonomous agents introducing privilege escalation paths, coordination failures, or trust boundary violations across agent-to-agent delegation. |
Treat these as durable working categories rather than a substitute for the finalized OWASP text. The domain names and scopes may shift as community review progresses, but the underlying concerns they describe are stable.
Mapping Risk Domains to Runtime Controls
Each risk domain maps to a category of enforceable runtime control. The goal is not to address every domain with a separate tool, but to recognize which control mechanisms address which risks, and to prioritize accordingly.
Tool-call governance
Validates tool-call schemas before execution, allow-lists permitted tools and parameters, and sandboxes execution so that a malformed or malicious call cannot reach production systems unchecked. Directly addresses tool invocation risk.
Least-privilege enforcement
Each agent instance operates under a scoped, time-bound permission set rather than a broad, standing credential shared across tasks. Directly addresses excessive agency and identity risk.
Per-agent identity and attribution
Assigns a distinct identity to each agent instance, enabling access controls, audit trail linkage, and containment if an agent is compromised or behaves unexpectedly.
Audit logging
Records every tool invocation, permission change, and agent decision in a tamper-evident log. Supports post-incident review and is the primary visibility mechanism for memory and multi-agent risk.
Context and memory integrity checks
Validates inputs to persistent memory stores and retrieved context before an agent acts on them. Reduces the attack surface for indirect prompt injection through stored state.
Agent-to-agent trust boundaries
Enforces explicit authorization checks before one agent can invoke or delegate to another, preventing privilege escalation through agent coordination chains.
Verification Status and Practical Next Steps
The taxonomy landscape for agentic AI security is still evolving across the industry, including OWASP-affiliated projects, and category names, scope, and version status can change as work moves through community review.
Security teams should treat any named taxonomy as a reference point for prioritization, not as a finalized compliance standard. Confirm exact category definitions and recommended mitigations from primary OWASP documentation before using them in an internal audit.
In the interim, the risk domains outlined here provide a workable structure for prioritizing runtime controls, independent of how the formal naming develops. The practical control categories, runtime policy enforcement, least-privilege permission scoping, distinct agent identity, and audit logging, are stable regardless of taxonomy version.
Frequently Asked Questions
Why doesn't the existing OWASP LLM Top 10 cover agentic AI risks?
The OWASP Top 10 for LLM Applications was designed around single-turn request-response interactions. It covers risks such as prompt injection, insecure output handling, and training data exposure within one cycle. Agentic AI systems operate differently: they plan sequences of steps, invoke external tools across multiple turns, retain and write persistent state, and may coordinate with other agents. These behaviors introduce risk categories, particularly around tool invocation, permission scope, and cross-agent trust, that do not map cleanly onto a single-turn model. OWASP's ongoing agentic AI work is intended to address this gap.
What makes excessive agency a distinct risk from standard privilege escalation?
Traditional privilege escalation involves an attacker gaining access they were not supposed to have. Excessive agency describes a configuration problem: the agent was legitimately granted permissions broader than its task requires. If that agent is then misdirected through prompt injection, a compromised tool response, or a flawed plan, it can take high-impact actions using permissions it should never have held in the first place. The distinction matters for control design: excessive agency requires proactive least-privilege scoping at deployment time, not just detection of unauthorized access after the fact.
How does memory integrity risk differ from standard data integrity concerns?
Standard data integrity concerns focus on whether stored data is accurate and unmodified. Memory integrity risk in agentic systems is specifically about whether persistent context retrieved by an agent can be used to manipulate the agent's future behavior across sessions. An attacker who can write to an agent's memory store may not need to compromise the model or the infrastructure directly. They can instead plant instructions or false context that the agent retrieves and acts on autonomously in a later session, potentially with no visible trigger at the point of compromise.
How should security teams handle the evolving state of OWASP's agentic AI taxonomy?
Treat it as a living reference rather than a stable standard. The risk domains described across current OWASP-affiliated agentic AI discussions, including tool invocation, excessive agency, identity, memory integrity, and multi-agent trust, are durable and useful for prioritizing controls today. However, the specific category names, numbering, and scope may change as community review progresses. Before using any version of the taxonomy in a formal audit or compliance mapping, confirm the current published definitions directly from OWASP's project documentation. Internal teams can begin control implementation based on the risk domains now without waiting for taxonomy finalization.
Which risk domain should security teams prioritize first?
For most organizations deploying agentic AI in production, tool invocation risk and excessive agency are the highest-priority starting points. Tool-call governance prevents a misconfigured or compromised agent from executing unintended actions against real systems. Least-privilege enforcement limits the blast radius when something does go wrong. Both controls are achievable at the infrastructure and policy layer without requiring model-level changes. Audit logging should be established in parallel, as it provides the visibility needed to detect and respond to incidents in the other risk domains.