The OWASP Top 10 for Agentic Applications is OWASP's risk list for AI agents that take action. It covers software that plans toward a goal, holds memory across steps, calls tools and APIs, coordinates with other agents, and acts with delegated authority. It extends the LLM Top 10 rather than replacing it, because most agent systems are also LLM applications and inherit those model-layer risks. For CISOs, identity architects, and the AI platform owners now running agents in production, the list is a practical map of where autonomous access can go wrong.
Why OWASP built a dedicated agentic list, and why it points to runtime authorization
The LLM Top 10 reads a model as a component that receives input and produces output. The agentic list goes further, because an agent does not act alone.
An agent plans toward a goal, keeps memory across steps, calls tools and APIs, and hands work to other agents. Each of those moves is a point where authority can spread further than intended, and those patterns do not map cleanly to the model-layer risks.
Agent behavior is dynamic, but enterprise permissions cannot be. OWASP even names the goal Instead, the goal should be least agency, granting an agent only the autonomy a bounded task needs. An agent should not carry broad, inherited authority simply because a user or service handed it a task.
Runtime authorization sets that boundary at every step. It evaluates the human, agent, and sub-agent identities, the delegation chain, the requested tool or action, the target resource, and the current risk context, then allows, denies, filters, or masks. The check runs at each transition, so a hijacked or compromised agent cannot turn one task into an open channel to data and external systems.
Mapping PlainID to the OWASP Top 10 for Agentic Applications (2026)
The mapping below shows PlainID's core strength: enforcing identity-aware, context-aware boundaries throughout an agentic workflow, including delegation, tool use, data retrieval, inter-agent calls and consequential actions.
ASI01: Agent Goal Hijack
An attacker may redirect an agent's objective through direct or indirect instructions, poisoned content or malicious tool output. PlainID independently authorizes each resulting access and action, so manipulated intent does not create permission.
PlainID capabilities: Runtime authorization; purpose-aware policy; tool/API controls; parameter restrictions; data filtering; approval for high-risk actions.
Coverage boundary: Behavior security tools detect malicious instructions; PlainID contains the operational impact.
ASI02: Tool Misuse and Exploitation
PlainID controls which tools an agent can discover and invoke, which operations are permitted, and which parameters, resources and destinations are acceptable for the current task. PlainID can also adjust the parameter content according to the policies and mask outputs from the tool response.
PlainID capabilities: MCP and tool authorization; function/action allowlisting; parameter-level policy; API controls; contextual least privilege; human approval.
Coverage boundary: Tools must still validate inputs and be securely implemented; PlainID governs whether and how they may be used.
ASI03: Identity and Privilege Abuse
PlainID treats agents as governed identities rather than allowing them to inherit broad user or service permissions. Authority is bounded across the human-agent-sub-agent delegation chain.
PlainID capabilities: Distinct identity context; scoped delegation; privilege intersection; tenant isolation; zero standing privilege; step-up; complete identity-chain audit.
Coverage boundary: Authentication, credential issuance and secrets protection remain complementary identity-platform responsibilities.
ASI04: Agentic Supply Chain Vulnerabilities
PlainID can prevent unapproved or high-risk agents, MCP servers, tools and models from receiving enterprise access, using registry, ownership, provenance, approval and risk metadata.
PlainID capabilities: Agent/tool registry; sanctioned-component policies; environment controls; administrative authorization; rapid access revocation.
Coverage boundary: Package scanning, model integrity verification, signing and software composition analysis remain specialized supply-chain controls.
ASI05: Unexpected Code Execution
Before an agent can invoke a code interpreter, shell, workflow engine or execution API, PlainID can authorize the tool, operation, target, parameters and execution context.
PlainID capabilities: Execution-tool allowlisting; operation and parameter controls; resource boundaries; environment policy; approval for privileged execution.
Coverage boundary: Sandboxing, secure coding, input validation and endpoint/runtime protection remain necessary to prevent code-level exploitation.
ASI06: Memory and Context Poisoning
PlainID can control who or what may write, approve, retrieve or use persistent memory, RAG content and contextual stores, and can restrict actions produced from high-risk context.
PlainID capabilities: Separate read/write/approve permissions; security-trimmed retrieval; trusted-source attributes; context-risk policies; auditable repository access.
Coverage boundary: PlainID does not semantically identify every poisoned memory entry; content integrity and AI-security analysis remain complementary.
ASI07: Insecure Inter-Agent Communication
PlainID can authorize every agent-to-agent transition using the calling agent, receiving agent, represented user, delegated purpose, requested capability and resource context.
PlainID capabilities: A2A authorization; bounded delegation; caller/callee identity; action scope; policy obligations; traceable delegation chain.
Coverage boundary: Channel authentication, encryption, message integrity and schema validation remain protocol and platform controls.
ASI08: Cascading Agent Failures
PlainID inserts independent control points between agents, tools, APIs and data so a failure in one component does not automatically inherit authority or propagate through the workflow.
PlainID capabilities: Per-hop authorization; privilege attenuation; risk-adaptive decisions; kill/revoke capability; transaction limits; approval gates; audit correlation.
Coverage boundary: Resilience engineering, circuit breakers, testing and operational recovery remain necessary for broader system reliability.
ASI09: Human-Agent Trust Exploitation
Even when persuasive agent output influences a user, PlainID can independently constrain the requested business action and require meaningful approval or stronger assurance.
PlainID capabilities: High-impact action authorization; explicit approval; step-up; amount/destination constraints; purpose and risk policy; explainable decisions.
Coverage boundary: User education, interface design and manipulation detection remain essential to ensure informed human decisions.
ASI10: Rogue Agents
PlainID can discover and classify agents, restrict unsanctioned or compromised agents, continually evaluate their access, and revoke permissions without depending on the agent to cooperate.
PlainID capabilities: Agent discovery and registry; approval/risk metadata; runtime least privilege; anomaly-informed policy; access revocation; auditable decisions.
Coverage boundary: Behavioral detection is stronger when PlainID consumes signals from agent observability, AI security and SOC platforms.
How PlainID Strengthens Agentic Security
1. Every agent receives bounded, contextual authority PlainID can calculate effective access from the intersection of the user's authority, the agent's permissions, the delegated purpose, the requested action and the current risk context. Agents do not need broad standing privilege.
2. Identity and delegation remain visible across the chain The decision can include the human, primary agent, sub-agent, workload and tool identities. This prevents implicit delegation from silently propagating the original user's full authority through a multi-agent workflow.
3. Tool access is controlled at action and parameter level Authorization does not stop at whether an agent may connect to an MCP server or API. PlainID can govern the specific tool, operation, target resource, destination, transaction amount, parameters values/instructions and returned data.
4. Independent checkpoints limit cascading failures Policies can be enforced at each agent-to-agent, agent-to-tool, tool-to-API and agent-to-data transition. A compromised component cannot automatically transfer its authority to the next component in the chain.
5. Control is centralized; enforcement is distributed where required Governed policies can be enforced across applications, agent frameworks, MCP servers, API gateways, microservices, data platforms and RAG pipelines while maintaining consistent business rules and audit evidence.
Where runtime authorization fits the OWASP Top 10 for Agentic Applications
OWASP describes how autonomous agents get hijacked, overprivileged, misdirected, or turned rogue. Authorization decides whether any of those failures becomes real access or a real action.
The agentic list raises the stakes, because authority now moves across a chain of agents, tools, and APIs. A control that only checks the front door cannot see those transitions.
PlainID sets an independent decision point at each one: human to agent, agent to sub-agent, agent to tool, tool to API, and agent to data. It maps directly to the tool, identity, and inter-agent risks, contains the ones it cannot detect, and names the controls it does not replace.
If you want to see where authorization fits your own agent workflows, from delegation to tool call to data to action, our team can walk you through it.
