OWASP agentic Top 10
OWASP Top 10 for Agentic Applications: the ten risks and the controls
The ten entries of the OWASP Top 10 for Agentic Applications 2026, each with the control that addresses it and a plain status for what Swfte has built.
The OWASP Top 10 for Agentic Applications is a list of ten risks for systems that plan, use tools and act, published by the OWASP GenAI Security Project as version 2026 in December 2025. Entries are numbered ASI01 to ASI10. This page lists all ten by their OWASP titles, names the control for each, and says what Swfte has built, using Built, In progress, Designed for or Not claimed.
Last verified 2026-10-07. Sources are listed at the end of the page.
What is the OWASP Top 10 for Agentic Applications?
It is a peer-reviewed list from the OWASP GenAI Security Project, produced by its Agentic Security Initiative. The document is titled OWASP Top 10 for Agentic Applications 2026 and is marked Version 2026, December 2025. OWASP announced it on 2025-12-09. The document is licensed under CC BY-SA 4.0.
Each entry has a description, common examples, example attack scenarios and mitigation guidance. The authors say they aim to simplify and connect existing guidance, and that the list maps to their longer Agentic AI Threats and Mitigations taxonomy. The document says it does not constitute legal advice.
What are the ten risks, and which control addresses each?
Titles follow the headings of the OWASP document. Its summary diagram abbreviates "and" as an ampersand in some of them. The descriptions are paraphrased. The control column follows OWASP's own mitigation guidance in short form. The last column is Swfte's status for that risk, based on what is built today. It is not a claim that Swfte covers or prevents the risk.
| OWASP entry | What it describes | Control that addresses it | Swfte status |
|---|---|---|---|
| ASI01 Agent Goal Hijack | An attacker redirects an agent's goals, task choice or decision path through injected text, tool output or poisoned data, because the agent cannot reliably tell instructions from content. | Treat all natural-language input as untrusted, give tools least privilege, require human approval for goal-changing or high-impact actions, log and monitor. | Built in part. Nexus applies a policy gate (allow, deny, ask) and audit to Claude Code and Codex tool calls. Connect detects secrets and personal data with a redact action. Not claimed: detection of injected instructions. |
| ASI02 Tool Misuse and Exploitation | An agent uses a legitimate tool in an unsafe way, for example deleting data, over-calling costly APIs or leaking information, within privileges it legitimately holds. | Per-tool least-privilege profiles, approval for each high-impact call, sandboxes and egress allowlists, an enforcement layer that treats model output as untrusted. | Built for coding agents (Nexus allow, deny, ask on the call) and for Cortex tool calls (in-app approvals bound to the exact call). For the MCP gateway, access is decided per server by API-key scope. Per-tool allow and deny rules are Designed for. |
| ASI03 Identity and Privilege Abuse | Attackers exploit delegation, inherited credentials and cached context so an agent acts beyond its intended access, because it lacks a distinct governed identity. | Short-lived, task-scoped credentials, per-agent identities, per-action authorisation by a central policy engine, human approval for privilege escalation. | Designed for. The Trust Profile as one record per AI system (owner, risk, models, data, actions) is a design concept, and approver identity and roles are listed as gaps. Built: Nexus records the approval decider from the authenticated principal. |
| ASI04 Agentic Supply Chain Vulnerabilities | Third-party models, tools, plug-ins, prompts, agents and registries, including those loaded at run time through MCP or A2A, are malicious, compromised or tampered with. | Signed manifests and inventories, allowlisted and pinned dependencies, curated registries, runtime re-validation and a revocation kill switch. | Not claimed for tool or MCP server signing, pinning or attestation. The Model Vault records a sha256 manifest and versions for model weights you bring (Built), which covers model artefacts only. |
| ASI05 Unexpected Code Execution (RCE) | Agents that generate and run code can be pushed into remote code execution, host compromise or sandbox escape, with code that is often created at run time. | No eval in production agents, sandboxed containers with network limits, separation of code generation from execution, approval for elevated runs, scanning and logging. | Built in part. The Nexus policy gate decides on each tool call a coding agent proposes. In progress: an OS-level sandbox in the Nexus harness, where the runtime is implemented, release acceptance is incomplete and the sandbox is proven on macOS only. |
| ASI06 Memory & Context Poisoning | Adversaries corrupt stored context, memory, embeddings or retrieval stores so later reasoning, planning or tool use is biased or unsafe. | Validate memory writes, segment sessions, allow only curated sources, require provenance, expire unverified memory, support rollback. | Not claimed. Access rules on retrieval exist in places, but nothing in the facts read for this page detects or quarantines poisoned memory. |
| ASI07 Insecure Inter-Agent Communication | Messages between agents lack authentication, integrity or semantic validation, so they can be spoofed, replayed or altered. | Mutual authentication, signed messages, anti-replay protection and protocol-level capability policies. | Not claimed. Swfte states no inter-agent message signing or mutual authentication. |
| ASI08 Cascading Failures | A single fault, such as a hallucination, poisoned memory or corrupted tool, spreads across agents and workflows and compounds into system-wide harm. | Isolation and trust boundaries, an independent policy engine, quotas and circuit breakers, rate limiting and monitoring, output validation and human gates. | Built for model traffic limits: Connect budgets, usage caps and a concurrent-request limit. The platform policy engine has allow, redact, ask and deny verdicts, but enforcement applies only to runs that have a policy attached. Not claimed: cross-agent circuit breakers. |
| ASI09 Human-Agent Trust Exploitation | Fluent, confident agents mislead people into approving harmful actions or sharing data, and the human performs the final audited step. | Explicit confirmations, immutable logs, plain-language risk summaries not generated by the model, trust calibration and reviewer training. | Built in part. Cortex approvals are bound to the exact call, and approvals and outbound-data decisions go into a hash-chained audit. Designed for: four-eyes review. No self-approval check exists today. |
| ASI10 Rogue Agents | Compromised or drifting agents deviate from their authorised function, acting harmfully or deceptively even when single actions look legitimate. | Immutable signed audit logs, trust zones, behavioural monitoring, kill switches and credential revocation, per-agent attestation. | Built for audit: Nexus audit and a hash-chained, append-only run ledger for platform runs, whose optional tamper seal is not enabled in the configuration read. Not claimed: behavioural drift detection and a kill switch. |
OWASP titles, descriptions and mitigations are from the OWASP document read on 2026-10-07. Swfte status is from the repository facts files and the Swfte SecOps pages as of the same date. See the trust centre for what is in place and what is not claimed.
How should I read the Swfte status column?
- Built means the capability exists in code and is in use, within the stated scope. It does not mean the risk is removed.
- In progress means implemented or partly implemented without finished release acceptance.
- Designed for means a design or a page concept exists but no shipped enforcement was found.
- Not claimed means Swfte makes no statement that it addresses the entry.
- No row says Swfte covers or prevents a risk. Each row says what a control addresses and where it stops.
How does it differ from the OWASP Top 10 for LLM Applications?
The LLM Top 10 covers applications that use a model. The agentic list covers systems that plan, decide and act across steps and systems on behalf of users. The authors say agentic apps are part of building an LLM app, so most entries cite LLM entries. ASI01 differs from LLM01 because LLM01 focuses on altering a single model response, while ASI01 covers manipulated input that redirects goals and multi-step behaviour.
ASI02 relates to LLM06 Excessive Agency, and ASI03 is described as the agentic evolution of Excessive Agency. The agentic list also introduces least-agency, the advice to avoid unnecessary autonomy, and treats observability as non-negotiable. Use both lists: the LLM list for the model layer, the agentic list for the layer that acts.
How do you use the list in practice?
1. Inventory your agents
Record each agent, its owner, the tools it can call and the data it can read. See AI inventory management.
2. Apply least-agency first
Remove autonomy you do not need. Fewer tools and narrower scopes shrink ASI01, ASI02, ASI03 and ASI08 together.
3. Map one control to each entry
For each of the ten, name the control, its owner and the evidence it produces. Mark entries with no control as open, not as accepted.
4. Gate high-impact actions
Route sends, payments, deletions and publishing through approval. See human in the loop and MCP and tool security.
5. Test and keep evidence
Run red-team exercises against each entry and keep the audit trail. See AI red teaming and the AI audit trail.
Where Swfte fits
Swfte's relevant controls are Nexus policy and approvals for coding agents, Cortex approvals bound to the exact call, Connect budgets and content-policy detectors, and audit records. The table says where each one addresses an entry and where it stops. Several entries, including supply chain, memory poisoning and inter-agent messaging, are not claimed.
You do not need a platform to start. A written agent inventory, least-privilege tool scopes and a human approval step for destructive actions address a large part of the list in any stack. Use MCP security best practices for tool servers. Governance and evidence become important when many agents act at once. Swfte does not claim certification or alignment audited by OWASP, and it is not a statement of compliance with any rule or regulation.
Sources and last verified
Every dated or technical fact on this page was read from the pages below on 2026-10-07. Anything that could not be confirmed is left out or marked as not verified.
- OWASP Top 10 for Agentic Applications for 2026 (resource page). The official resource page for the document and its edition name.
- OWASP Top 10 for Agentic Applications 2026 (PDF download). The ten entry titles, descriptions, mitigations, licence and version, read from the PDF.
- OWASP announcement, 2025-12-09. Publication date and the list of ten entries.
- OWASP Agentic Security Initiative. The project that maintains the list and its resources.
- OWASP LLM01 Prompt Injection. The LLM-list entry that ASI01 is compared with.
Frequently asked questions
What is the OWASP Top 10 for Agentic Applications?
It is an OWASP GenAI Security Project list of ten risks for AI agents that plan, use tools and act. The document is titled OWASP Top 10 for Agentic Applications 2026 and is dated December 2025, with entries ASI01 to ASI10. Each entry has a description, examples, attack scenarios and mitigations.
When was it published and which edition is current?
OWASP announced it on 2025-12-09, and the document is marked Version 2026, December 2025. The title carries 2026 although it was released in December 2025. This page does not state whether a newer version exists. Check genai.owasp.org for updates, because the list is versioned.
What is ASI01 in the OWASP agentic list?
ASI01 is Agent Goal Hijack. It describes an attacker manipulating an agent's objectives, task selection or decision path, through prompts, tool outputs, forged agent messages or poisoned data, because agents cannot reliably tell instructions from content. OWASP separates it from LLM01, which concerns altering a single model response.
How is it different from the OWASP Top 10 for LLM applications?
The LLM list covers applications built on a model. The agentic list covers systems that plan, hold memory, call tools and act, so it adds risks such as inter-agent communication and rogue agents. The two are linked: agentic entries cite LLM entries, and ASI03 is called the agentic evolution of Excessive Agency.
Does Swfte cover or prevent these risks?
Swfte does not claim to cover or prevent any entry. Its controls address parts of some: a policy gate and audit for coding agents, approvals bound to the exact call in Cortex, and Connect budgets. Supply chain, memory poisoning and inter-agent communication are not claimed. The table on this page gives the status of each.
Is there a certification for the OWASP agentic list?
The document read for this page presents itself as a reference list with mitigation guidance and describes no certification scheme. Swfte does not claim certification or an OWASP audit. Mapping controls to the list produces evidence for your own risk work, not a pass mark, so describe it as a mapping.