Agentic AI Security: The OWASP Top 10 as Audit Evidence

Agentic AI security is the part of AI security that starts when a model stops answering and starts acting: it plans, keeps memory, calls tools and spends authority that someone delegated to it. Almost every guide on the subject is written by a security vendor and stops at the threat. The reference list, the OWASP Top 10 for Agentic Applications, runs to 57 pages and does not name a single regulation. This guide reads the same ten risks the way an auditor or a market surveillance authority would: which legal duty each one touches, which record proves you dealt with it, and which deadlines are already running in the European Union.

Key takeaways

• An agent cannot reliably tell an instruction from the content it reads, so the control point is what the agent is allowed to do, not what it is told.
• The OWASP Top 10 for Agentic Applications (9 December 2025) lists ten risks, ASI01 to ASI10, and 86 numbered mitigations by our count.
• Its 57 pages never mention the EU AI Act or ISO/IEC 42001. The legal reading of agentic AI security is yours to build.
• The European Commission treats agents as AI systems, not as a separate category, and its draft high-risk guidelines of 19 May 2026 assess an agentic system as a whole.
• Cyber Resilience Act reporting has applied since 11 September 2026 and Article 50 transparency since 2 August 2026. Annex III high-risk duties arrive on 2 December 2027.

What is agentic AI security?

Agentic AI security is the discipline of keeping systems that plan, remember, call tools and act on delegated authority within the scope their owner intended, and of being able to prove it afterwards. The second half of that sentence is what separates a governance view of agentic AI security from a product pitch. OWASP describes an agent through four capabilities, which also serve as a threat-modelling canvas: planning and reasoning, memory, tool use and action. A chatbot that drafts an email has one of them. An assistant that reads your inbox, decides which supplier to chase, opens a ticket and issues a credit note has all four. That is the line between classic AI security and agentic AI security. In a language model application the model is a component: it receives input and returns text, and a human or a program decides what happens next. In an agentic system the model is an actor. Our guide to autonomous AI agents covers the governance side of that shift, and the comparison of agentic AI vs generative AI explains why the duties change with it.

Why agents break the assumptions of application security

Agentic AI security exists because three assumptions that application security has relied on for twenty years stop holding.

1. Code and data are no longer separable. OWASP states the problem plainly: agents and the underlying model cannot reliably distinguish instructions from related content. A web page, a calendar invite or a tool response can carry an instruction, and the agent may follow it.
2. The identity that acts is not the identity that asked. An agent works through delegation chains, inherited roles and cached credentials. It can end up doing something the person who started the task could never have done alone.
3. A fault persists and spreads. A poisoned memory entry survives the session. A wrong plan is executed by another agent that trusts it. One error becomes many actions before anyone looks.

The leaders of the OWASP project answer with two principles. The first is Least Agency: avoid unnecessary autonomy, because deploying agentic behaviour where it is not needed expands the attack surface without adding value. The second is observability, which they call non-negotiable: you need to see what agents are doing, why, and which tools they invoke. A one-line test of agentic AI security helps. Simon Willison’s lethal trifecta says that an agent with access to private data, exposure to untrusted content and a way to communicate externally has everything an attacker needs. Remove one leg and the worst outcomes disappear.

The agentic AI security reference list: OWASP Top 10 for Agentic Applications

The OWASP Top 10 for Agentic Applications was announced on 9 December 2025 by the Agentic Security Initiative of the OWASP GenAI Security Project. It is 57 pages long, licensed under CC BY-SA 4.0, and more than 100 experts contributed. It is the closest thing agentic AI security has to a shared vocabulary. Each entry has a description, common examples, attack scenarios and prevention and mitigation guidelines. By our count the document holds 86 numbered mitigations, between seven and ten per entry, and 61 attack scenarios. <table header-row=”true”> <tr> <td>ID</td> <td>Entry</td> <td>What goes wrong</td> <td>First control OWASP lists</td> </tr> <tr> <td>ASI01</td> <td>Agent Goal Hijack</td> <td>An attacker redirects the agent’s objectives through prompts, tool outputs, documents or forged messages</td> <td>Treat all natural-language input as untrusted; human approval for goal-changing actions</td> </tr> <tr> <td>ASI02</td> <td>Tool Misuse and Exploitation</td> <td>The agent uses a legitimate tool in an unsafe way: exfiltration, destructive action, chained calls</td> <td>Least agency and least privilege per tool: scopes, rate limits, egress allowlists</td> </tr> <tr> <td>ASI03</td> <td>Identity and Privilege Abuse</td> <td>Delegation chains and inherited or cached credentials let an agent act beyond what the requester could</td> <td>Task-scoped, time-bound permissions; per-action authorisation</td> </tr> <tr> <td>ASI04</td> <td>Agentic Supply Chain Vulnerabilities</td> <td>A third-party tool, plug-in, MCP server, model, prompt or agent is malicious or tampered with</td> <td>Provenance, SBOM and AIBOM, signed manifests, allowlist and pinning</td> </tr> <tr> <td>ASI05</td> <td>Unexpected Code Execution (RCE)</td> <td>Generated code or tool input turns into command execution on a host</td> <td>Sandboxed execution, no direct path to production, approval for elevated runs</td> </tr> <tr> <td>ASI06</td> <td>Memory and Context Poisoning</td> <td>Stored context is seeded with false or malicious content that persists across sessions</td> <td>Validate memory writes, segment memory, track provenance, keep snapshots and rollback</td> </tr> <tr> <td>ASI07</td> <td>Insecure Inter-Agent Communication</td> <td>Messages between agents are spoofed, replayed or altered</td> <td>Mutual authentication, signed messages, protocol version pinning, attested registries</td> </tr> <tr> <td>ASI08</td> <td>Cascading Failures</td> <td>One fault propagates across agents and tools into system-wide harm</td> <td>Isolation and trust boundaries, circuit breakers, independent policy enforcement</td> </tr> <tr> <td>ASI09</td> <td>Human-Agent Trust Exploitation</td> <td>People over-trust a fluent agent and approve harmful actions</td> <td>Explicit confirmations, preview separated from effect, plain-language risk summaries</td> </tr> <tr> <td>ASI10</td> <td>Rogue Agents</td> <td>A compromised or misaligned agent drifts outside its scope while each action looks legitimate</td> <td>Signed audit logs, behavioural monitoring, kill switch and credential revocation</td> </tr> </table> Two things stand out when the list is read sideways rather than top to bottom. First, logging or monitoring appears as a numbered mitigation in nine of the ten entries, and human approval in seven. Read that way, the document is less a catalogue of attacks than a specification for two artefacts every compliance team already knows: a log and an approval rule. Second, the identifiers map to other OWASP work. Appendix A links each entry to the Top 10 for LLM Applications and to the earlier Agentic AI Threats and Mitigations taxonomy with its fifteen threats. Appendix B covers CycloneDX and the AI bill of materials. Appendix C maps the Non-Human Identities Top 10. None of the appendices maps agentic AI security to a law.

What the incident record shows

The list ships with an exploits and incidents tracker in Appendix D, updated weekly on GitHub. The published version holds about two dozen public incidents dated February to October 2025. The most frequent tags are Tool Misuse, Agent Goal Hijack and Unexpected Code Execution. A few examples show the pattern:

• February 2025: prompt injection in web content caused a browsing agent to follow attacker instructions and reach authenticated pages.
• April 2025: a malicious agent published a fake agent card in an open agent-to-agent directory and claimed a high trust level.
• July 2025: agents built on a low-code platform were public by default and lacked authentication, so outsiders could enumerate them and pull business data.
• September 2025: an indirect prompt injection in a CRM agent platform let an external party mislead the agent, and the first malicious MCP server was found in the wild on npm, impersonating a legitimate mail package.
• October 2025: a cluster of flaws in a coding agent allowed configuration overwrite and command execution.

The 2026 picture of agentic AI security is harsher. OWASP’s State of Agentic AI Security and Governance, version 2.01 of 1 June 2026, marks the change in its own method. As Help Net Security reported, the 2025 edition catalogued plausible threats while the 2026 edition catalogues CVEs, vendor advisories and breach reports. It tracks 53 agentic projects, 28 of them coding agents. The repositories with the most advisories are n8n (57), Claude Code (22), AutoGPT (15), Dify (13) and Roo-Code (11). In March 2026 a backdoored LiteLLM package on PyPI was downloaded about 47,000 times in a three-hour window, and that gateway sits underneath several agent frameworks. Two lessons follow for agentic AI security. The entry point is usually ordinary: a package, a web page, a support ticket, a default setting. And the damage is decided by what the agent was allowed to do. That is why, in agentic AI security, testing matters as much as design: our guides to AI red teaming and MITRE ATLAS cover the method and the technique catalogue.

What agentic AI security guidance leaves out: the law

We ran a full-text check on the Top 10 PDF. It contains no mention of the EU AI Act, of ISO/IEC 42001, or of any regulation. That is not a flaw in a security document. It is a gap for whoever has to answer to an authority, because a list of risks does not say which of them the law obliges you to manage, by when, or with what proof. OWASP has started to close the gap from its side. The GenAI Security Industry Framework Crosswalk, released on 1 September 2026, maps OWASP GenAI risks to 25 frameworks, the EU AI Act among them. It is a useful index. It is also a community mapping, not a legal reading. What has the regulator said? The Commission’s position is that agents are not a separate category: the definitions of AI system in Article 3(1) and of general-purpose AI model in Article 3(63) already cover them. Its draft guidelines on high-risk classification, published for consultation on 19 May 2026, go one step further. According to law-firm commentary on the draft, a system made of several interacting components, agentic systems included, is assessed as a whole, and the Article 6(3) exemption cannot be claimed module by module. The final version is pending. For the classification itself, see our guide to EU AI Act high-risk systems. The table below is our reading, not an OWASP or Commission mapping. It ties each entry to the AI Act provision it touches and to the evidence an auditor asks for. <table header-row=”true”> <tr> <td>Entry</td> <td>EU AI Act hook</td> <td>Evidence an auditor asks for</td> </tr> <tr> <td>ASI01 Agent Goal Hijack</td> <td>Art. 15(5) attempts to alter use, outputs or performance; Art. 9</td> <td>Inventory of untrusted input channels; system prompt under version control; goal-override test report</td> </tr> <tr> <td>ASI02 Tool Misuse</td> <td>Art. 14 human oversight; Art. 26(1) use according to instructions</td> <td>Tool register with scopes, rate and egress limits; approval rule for destructive actions; immutable tool-call log</td> </tr> <tr> <td>ASI03 Identity and Privilege Abuse</td> <td>Art. 15(5); GDPR Art. 32</td> <td>One identity per agent; short-lived scoped credentials; review of delegation chains</td> </tr> <tr> <td>ASI04 Supply Chain</td> <td>Art. 25 value chain; Cyber Resilience Act Annex I</td> <td>AIBOM or SBOM; signed and pinned tools and MCP servers; supplier assessments</td> </tr> <tr> <td>ASI05 Unexpected Code Execution</td> <td>Art. 15(4) and (5); Cyber Resilience Act Annex I</td> <td>Sandbox configuration; auto-execution allowlist under version control; scan logs</td> </tr> <tr> <td>ASI06 Memory and Context Poisoning</td> <td>Art. 10 data governance; Art. 15(5) data poisoning</td> <td>Memory-write validation rule; provenance records; rollback test; retention rule</td> </tr> <tr> <td>ASI07 Inter-Agent Communication</td> <td>Art. 15(5); Art. 12 record-keeping</td> <td>Mutual-authentication configuration; signed messages; agent registry; protocol version policy</td> </tr> <tr> <td>ASI08 Cascading Failures</td> <td>Art. 15(4) resilience to errors and faults; Art. 72</td> <td>Blast-radius limits; circuit-breaker test results; replay test records</td> </tr> <tr> <td>ASI09 Human-Agent Trust Exploitation</td> <td>Art. 14(4)(b) automation bias; Art. 50(1)</td> <td>Confirmation design for risky actions; user reporting channel; oversight training records</td> </tr> <tr> <td>ASI10 Rogue Agents</td> <td>Art. 14(4)(e) stop; Art. 72; Art. 73</td> <td>Kill-switch and revocation drill; behavioural baseline; quarantine and reintegration procedure</td> </tr> </table> ISO/IEC 42001 asks for the same material from a different angle. Its Annex A control areas on the AI system life cycle (operation and monitoring, event logs), on third-party and customer relationships, on the use of AI systems and on responsibilities all apply to an agent. A certification auditor will ask how agent risks were identified and what was decided for each. A decision record per entry answers that question.

Which law makes agentic AI security evidence demandable

The Top 10 is voluntary. Evidence of agentic AI security is not, once one of these instruments applies.

• AI Act, Articles 9, 12, 14 and 15. High-risk systems need risk management, automatic event logs, human oversight including the ability to interrupt the system through a stop button or similar procedure (Article 14(4)(e)), and resilience against attempts by unauthorised third parties to alter use, outputs or performance (Article 15(5)). After the Digital Omnibus, Regulation (EU) 2026/1744, these duties apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028.
• AI Act, Article 26. Deployers must use the system according to its instructions, assign oversight to competent people, monitor operation and keep automatically generated logs for at least six months.
• AI Act, Article 50. Since 2 August 2026, an agent that interacts directly with people must make clear that they are dealing with an AI system.
• AI Act, Article 55. Providers of general-purpose models with systemic risk owe adversarial testing and cybersecurity protection, applicable since 2 August 2025. Many agents are built on such models; see general-purpose AI.
• Cyber Resilience Act, Regulation (EU) 2024/2847. It covers products with digital elements, which includes most commercial software shipping an agent. Since 11 September 2026 manufacturers report actively exploited vulnerabilities and severe incidents: early warning within 24 hours, notification within 72 hours. The full essential requirements apply from 11 December 2027.
• GDPR, Article 32. Security of processing applies whenever the agent touches personal data.
• NIS2 and DORA. Essential and important entities and financial entities already owe ICT risk management and incident reporting. DORA has applied since 17 January 2025.

For high-risk systems, Article 73 adds its own serious-incident clocks: 15 days in general, 2 days for a widespread infringement or a disruption of critical infrastructure, 10 days in case of death. A single agentic AI security incident can therefore start three clocks at once, under the Cyber Resilience Act, the GDPR and the AI Act. Our guide to AI incident reporting sets out who files what.

From agentic AI security to evidence: a seven-step method

1. Inventory every agent. Record the owner, the purpose, the model, each tool and its scope, the memory stores, the identities and credentials, the other agents it talks to and the systems it can change. An AI inventory that stops at “we use an assistant” misses everything that matters here. The AI registry holds agents as records in their own right.
2. Apply Least Agency. For each agent, write down why autonomy is needed, what it may do without approval, and remove the tools it does not need. A recorded refusal is evidence. Silence is a gap.
3. Give each agent its own identity. No shared service accounts. Issue short-lived, task-scoped credentials and bind permissions to subject, resource, purpose and duration.
4. Write the approval rule. Name the actions that need a human (delete, pay, publish, grant access, change a goal), name who approves, and decide how the request is displayed so that approval does not become a reflex. This is a human oversight design question, not a checkbox.
5. Log what an authority will ask for. The goal, the plan, each tool call with its parameters, each approval and each inter-agent message, tamper-evident and time-stamped, retained for at least six months where the AI Act applies.
6. Test before release and after every change. A new tool, model version, prompt or memory source reopens ASI01, ASI02 and ASI06. Include a kill-switch and credential-revocation drill, and keep the report.
7. Put the supply chain and the clocks on paper. Keep an AIBOM or SBOM, pin and sign tools and MCP servers, add supplier clauses through vendor due diligence, and decide in advance who files within 24 or 72 hours.

Each step of this agentic AI security method leaves a record. Together the records form a statement of applicability for agent risk: ten entries, and for each one a decision, a control, an owner and a test result. That file is what agentic AI security looks like to an auditor.

Roles: who answers for agentic AI security in the value chain

An agent is rarely built by one party. There is a model provider, a framework, publishers of tools and MCP servers, an integrator and the organisation that deploys the result. The AI Act does not let responsibility dissolve along that chain. Under Article 25, whoever puts its name on a high-risk system, substantially modifies it or changes its intended purpose becomes a provider. Assembling an agent from a general-purpose model and a set of tools can make the integrator the provider of an AI system. Two publications on agentic AI security and EU law are worth reading on this point. The paper AI Agents Under EU Law proposes a twelve-step compliance architecture. It concludes that the provider’s foundational task is an exhaustive inventory of the agent’s external actions, data flows, connected systems and affected persons, and that high-risk agentic systems with untraceable behavioural drift cannot currently satisfy the essential requirements. The Future Society report Ahead of the Curve calls the allocation question the “many hands problem” and distributes duties across model providers, system providers and deployers. The practical consequences are three:

• Contracts. Ask suppliers for change notification, vulnerability notice and access to logs. Without them you cannot meet your own reporting clocks.
• Internal ownership. Agree a RACI between security, the AI governance function and the business owner of each agent. Our guide to AI accountability shows how to document it.
• Drift as a compliance control. An agent whose behaviour changes without a record is the case the paper warns about. Treat model drift monitoring as part of the security file.

Standards in motion: what to follow until harmonised standards arrive

No harmonised standard covers agentic AI security yet. Several bodies are moving, and it pays to know which outputs are firm. In the United States, NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative on 17 February 2026. It rests on three pillars: industry-led standards, community-led open-source protocols, and research on agent security and identity. A request for information on securing AI agent systems closed on 9 March 2026, and a concept paper on agent identity and authorisation was open for comment until 2 April 2026. According to Cloud Security Alliance research notes, SP 800-53 control overlays for single-agent and multi-agent deployments are in development, with no publication date. The existing generative AI profile, NIST AI 600-1, remains the closest published NIST reference. OWASP keeps extending its own set: the Securing Agentic Applications Guide 1.0 covers architecture and deployment, and an Agent Control Standard was donated to the project in September 2026, aimed at runtime enforcement. From academia, the UC Berkeley CLTC Agentic AI Risk-Management Standards Profile, version 1.0 of February 2026, extends the NIST AI RMF and argues for governance that scales with the degree of agency rather than treating autonomy as binary. In the EU, the harmonised standards for the AI Act were still in preparation at CEN-CENELEC in 2026. Until one is cited in the Official Journal, a recognised public taxonomy combined with your own records is the most defensible structure, and it fits inside an ISO/IEC 42001 management system without rework.

FAQ

What is agentic AI security in simple terms? It is the work of making sure an AI agent only does what its owner intended, and of keeping the records that prove it. An agent plans, remembers, uses tools and acts with authority someone delegated to it. Security for such a system is less about filtering what goes into the model and more about limiting what the agent can do, giving it its own identity, logging its actions and being able to stop it. How does agentic AI security differ from AI security or LLM security? AI security covers models and data in general: poisoning, evasion, theft. LLM security adds the risks of language model applications, where the model is a component that returns text. Agentic AI security starts where the model becomes an actor with tools, memory and delegated permissions. The new problems are tool misuse, identity and privilege abuse, memory poisoning, communication between agents and failures that cascade. Is the OWASP Top 10 for Agentic Applications mandatory? No. It is a community awareness document with no certification and no binding force. What becomes mandatory is the evidence, once a law applies: the EU AI Act for high-risk systems, the Cyber Resilience Act for products with digital elements, the GDPR whenever personal data is processed, NIS2 and DORA for the entities they cover. The list is a convenient structure for that evidence. Does the EU AI Act cover AI agents? Yes. The Commission treats agents as AI systems under Article 3(1), not as a separate category. Whether an agent is high-risk depends on its use, and the draft guidelines of 19 May 2026 assess an agentic system as a whole. Article 50 has required disclosure to people who interact with an agent since 2 August 2026. Where the agent runs on a general-purpose model, that model’s provider carries separate duties under Chapter V. What does Least Agency mean in practice? It means granting an agent the minimum autonomy the task needs. In practice: list the tools, remove those the task does not require, set scopes, rate limits and egress allowlists for the rest, and define which actions need human approval. Record the reasoning. When someone later asks why the agent could issue refunds but not change bank details, the answer should be a document, not a memory. What is the first step in agentic AI security? An inventory. You cannot protect or defend agents you have not listed. For each one, record the owner, the model, the tools and their scopes, the memory, the credentials and the systems it can change. Then remove the tools it does not need and give it an identity of its own. In agentic AI security, those three moves reduce more risk than any detection product.

Conclusion

The security community has done its part. It has named ten risks, written 86 mitigations and built an incident record that grows every week. What it does not say is which law applies to your agent, from when, and what an authority will ask to see. That part of agentic AI security is yours: an inventory, a Least Agency decision, an identity per agent, an approval rule, logs, tests after every change and reporting clocks agreed in advance. Cyber Resilience Act reporting is already live, and December 2027 brings both the high-risk duties of the AI Act and the full product requirements. AI Sigil records each agent in the registry as a first-class record, with its tools, risks, controls, owners and evidence, so the answer to an auditor is a report, not a reconstruction.