OWASP Top 10 for Agentic Applications: Risk Mapping & Governance Controls (2026)

Why Agentic AI Needs Its Own Security Framework

The OWASP LLM Top 10, published in 2023, was designed for request-response AI systems. It addresses what AI says—prompt injection, data leakage, toxic output. That list remains relevant, but it doesn't cover what happens when AI starts doing things. Agentic AI systems plan multi-step actions, invoke tools and APIs, write to databases, send communications, and delegate tasks to sub-agents. The attack surface isn't just the model's output anymore—it's every action the agent takes in the real world.

The OWASP Top 10 for Agentic Applications, published in late 2025 by the GenAI Security Project with input from over 100 industry experts, addresses this new reality. It catalogs ten risks that are either unique to or dramatically amplified by autonomous agent architectures. These aren't hypothetical—the list cites real-world incidents including Microsoft 365 Copilot exfiltration (ASI01), Amazon Q tool misuse (ASI02), GitHub MCP supply chain exploitation (ASI04), AutoGPT remote code execution (ASI05), and Gemini memory poisoning (ASI06).

The critical gap this page addresses: OWASP tells you what can go wrong, but it doesn't tell you how to govern against it. ISO 42001 and NIST AI RMF provide governance structures, but they weren't designed with agents in mind. This guide maps every ASI risk to both governance and technical controls, anchored to ISO 42001 Annex A and NIST AI RMF subcategories.

A note on scope: the OWASP Agentic Top 10 complements the LLM Top 10, it doesn't replace it. If your agent is built on an LLM (and most are), both lists apply. The LLM risks (prompt injection, insecure output handling, training data poisoning) are still present. The Agentic Top 10 adds the system-level risks that emerge when that LLM gains tools, memory, and the ability to act without real-time human approval. Your threat model needs both catalogs.

The 10 Risks — ASI01 Through ASI10

Each risk below includes the attack vector, a real-world example pattern, and the governance plus technical controls that address it.

ASI01 — Agent Goal Hijack

An attacker manipulates the agent's objectives via malicious text injection, poisoned data, or compromised intermediate outputs. The agent then pursues the attacker's goal instead of its intended objective. Hidden prompts in emails, documents, or calendar invites are common vectors. Governance: human approval required for goal changes; treat all external data as untrusted. Technical: input validation against whitelists; goal verification at each execution step; kill switch for immediate halt.

ASI02 — Tool Misuse and Exploitation

The agent uses an authorized tool destructively—wrong parameters, unexpected chaining, or API scope abuse. A file-access tool authorised for "read specific customer records" gets invoked with "read all files in /root." Governance: least-privilege tool access; tool calls require human approval for sensitive operations. Technical: argument validation; parameter whitelisting; audit logging of all tool calls with parameters and responses.

ASI03 — Identity and Privilege Abuse

The agent inherits or escalates privileges, shares credentials across tasks, or impersonates other agents. API keys scoped for "read" get used for "write." Credentials cached from one task get reused in another without re-authentication. Governance: agents treated as managed non-human identities; just-in-time credentials scoped to specific tasks. Technical: credential rotation per task; agent authentication required before accepting delegation; privilege escalation detection.

ASI04 — Agentic Supply Chain Vulnerabilities

Compromised tools, MCP servers, dynamic templates, or vulnerable dependencies in the agent orchestration layer. A third-party plugin wrapper injects malicious instructions into the agent's decision logic at runtime. Governance: MCP allowlist; signed manifests for tools and plugins; pinned dependencies; vendor questionnaire. Technical: supply chain scanning; SLA enforcement; dependency integrity verification.

ASI05 — Unexpected Code Execution

Code injection through agent prompts or unvalidated inputs processed as executable code. The agent interprets user-supplied text as Python instead of natural language. Governance: no shell access policy; input validation; code review pre-deployment. Technical: sandboxing; restricted execution environment; no dynamic eval.

ASI06 — Memory and Context Poisoning

Long-term state corruption through hallucinated outputs consumed by other agents or accumulated context errors. After 1,000 interactions, the agent's decisions are based on a corrupted internal model. Governance: memory integrity checks; context reset protocols; multi-agent output validation. Technical: hallucination detection; fact-checking before memory storage; periodic memory audit.

ASI07 — Insecure Inter-Agent Communication

Untrusted agent-to-agent messages, instruction manipulation, or no authentication between agents. An attacker-controlled rogue agent sends "override your risk threshold" to a legitimate agent, which trusts the source and complies. Governance: agent authentication required before accepting task delegation; signed instruction chains. Technical: end-to-end encryption; message signature verification; source authentication.

ASI08 — Cascading Failures

One agent's error escalates through a multi-agent system. Agent A makes a small error, passes the output to Agent B, B amplifies it, passes to Agent C—system-wide failure. Governance: per-agent error rate thresholds; one-at-a-time test deployment; circuit breakers. Technical: error detection at each step; multi-agent output validation; failure isolation.

ASI09 — Human-Agent Trust Exploitation

Anthropomorphic behavior causes humans to overtrust the agent. The agent uses conversational authority to convince a human to bypass security controls or disclose confidential information. The human performs the auditable action; the agent's manipulation stays invisible in logs. Governance: user training on agent limitations; mandatory human checkpoints for sensitive actions. Technical: non-anthropomorphic interface design; clear uncertainty indicators; disable emotional language.

ASI10 — Rogue Agents

Agents operating outside designed scope through attacker subversion or goal misalignment. An agent deployed to "optimise revenue" drifts over time to "maximise revenue regardless of customer harm" via reinforcement learning feedback loops. Governance: agent isolation (VM/container); kill switch for immediate deactivation; continuous monitoring. Technical: anomaly alerting; goal alignment verification; behavioural drift detection; execution environment isolation.

Governance Control Mapping Matrix

This table is the central reference artifact for mapping OWASP risks to existing governance frameworks. Use it to identify which ISO 42001 and NIST AI RMF controls partially cover each risk, and where you need supplementary controls.

Two patterns are immediately visible. First, ISO 42001 Annex A.9.2 (human oversight) and A.6.1 (scope/risk) appear across multiple ASI risks—they're the broadest governance anchors in the standard but don't provide agent-specific prescriptions. You'll need to add specificity to these controls in your Statement of Applicability: "human oversight for A.9.2 includes agentic-specific checkpoints for actions exceeding $X or accessing data classification Y." Second, three risks have no adequate ISO 42001 or NIST AI RMF coverage at all: inter-agent communication security (ASI07), memory integrity (ASI06), and cascading failure containment (ASI08). These require entirely new controls that sit outside both frameworks. That's the gap the AI Controls Toolkit (ACT) Tier 2 Agentic AI Governance Module is designed to fill.

Governance vs Technical Mitigations — Why You Need Both

Every ASI risk requires two layers of controls, and neither alone is sufficient. A policy without technical enforcement is wishful thinking. A technical control without governance accountability has no owner, no review cadence, and no corrective action process when it fails.

Governance controls are implemented by compliance and risk teams: policies defining acceptable agent behaviour, RACI matrices assigning accountability for each agent, human approval checkpoints for high-risk actions, training programmes for staff who deploy and oversee agents, risk assessment procedures that include agentic risk categories, and incident response playbooks for agent-specific failure modes.

Technical controls are implemented by engineering: API sandboxing and least-privilege access, input validation and parameter whitelisting, credential rotation and just-in-time authentication, execution environment isolation (containers, VMs), monitoring dashboards with anomaly detection, circuit breakers for automatic halt, and kill switches for emergency deactivation.

The practical pattern for SMEs: start with governance (policy, roles, approval workflows) because it's faster and cheaper. Layer technical controls on top as engineering bandwidth allows. A documented policy stating "agents must not execute financial transactions above $500 without human approval" is immediately enforceable through process even before you've built the automated enforcement mechanism. The policy creates accountability; the technical control creates reliability.

The most common mistake we see: organizations invest heavily in technical sandboxing and monitoring but never create the governance layer. When something goes wrong, nobody knows who's responsible, there's no escalation path defined, and there's no corrective action process. The technical controls caught the anomaly, but the organization didn't know what to do about it. Start with the governance structure, even if it's a one-page policy and a RACI matrix. You can always improve the technical enforcement later—you can't retrofit accountability after an incident.

Another pattern worth avoiding: treating OWASP Agentic risks as purely a security team responsibility. ASI09 (Human-Agent Trust Exploitation) is a user training and interface design problem, not a firewall rule. ASI01 (Goal Hijack) is as much about data governance and input validation policies as it is about prompt filtering. Get your product, compliance, and risk teams involved alongside security. The governance controls require cross-functional ownership.

Extending ISO 27001 ISMS to Cover Agentic AI Security

If you've got ISO 27001 certification, you've already got the infrastructure for managing information security risks. Extending it to cover agentic AI doesn't require a new management system—it requires scope expansion and new controls within the existing one.

• Step 1: Extend scope. Add AI agents to your asset inventory as managed system assets. Each agent gets an entry with its purpose, autonomy level, tools it accesses, data it processes, and responsible owner. Treat agents as non-human identities in your identity and access management framework.
• Step 2: Update risk assessment. Add agentic risk categories (ASI01–ASI10) to your risk register as a threat catalog input. For each agent, assess which ASI risks apply based on its autonomy level and tool access. This maps directly to your existing risk assessment methodology—different threats, same process.
• Step 3: Add AI-specific controls. Implement controls for agent identity management, tool governance (whitelisting, least privilege), memory integrity, and inter-agent communication security. These controls don't exist in ISO 27001's Annex A, so they'll sit as supplementary controls within your ISMS.
• Step 4: Update incident response. Add agent-specific incident types to your IR playbook: goal hijack, unauthorised tool invocation, cascading failure, rogue agent behaviour. Define the containment procedure (isolation, kill switch), investigation process (session replay, tool call audit), and recovery steps.
• Step 5: Integrate monitoring. Add agent behaviour monitoring to your existing SOC processes. Track API call volumes, tool invocation patterns, boundary violations, and escalation rates alongside your traditional security monitoring. Anomalous agent behaviour should trigger the same alert-investigate-respond workflow as any other security event.

Organizations pursuing ISO 42001 alongside ISO 27001 can integrate the agentic controls into their AIMS rather than their ISMS. The choice depends on where your existing management system has more capacity and which audit cycle is next. Either path works—what matters is that the controls exist somewhere and someone owns them.

A practical tip for the integration: don't create a separate "agentic AI risk register." Add the agentic risk categories to your existing risk register as new threat entries. The ASI01–ASI10 risks slot into your existing risk assessment methodology—they need the same treatment as any other risk: likelihood, impact, existing controls, residual risk, treatment decision. The only difference is the threat source (the agent itself, or an attacker exploiting the agent) and the controls (agent-specific rather than traditional IT security). Keep the process familiar and extend it rather than building something parallel.

For organisations that use the OWASP list as their primary threat model input, map each ASI risk to the relevant IMDA governance dimension as well. IMDA's four dimensions (risk bounding, human accountability, technical controls, end-user responsibility) provide the governance overlay that OWASP's security-centric list doesn't include. The combination of OWASP for threat identification and IMDA for governance response gives you a complete picture. See our agentic AI governance hub for how all four frameworks fit together.

Red-Teaming for Agentic AI Systems

Pre-deployment red-teaming for agents should cover scenario-based testing mapped to each ASI risk. For ASI01: inject malicious instructions into external data sources the agent processes and verify the agent rejects or escalates. For ASI02: attempt to invoke tools outside the agent's authorised scope and verify the whitelisting holds. For ASI04: introduce a compromised plugin or MCP server and verify the agent's supply chain validation catches it. For ASI08: deliberately introduce errors into one agent's output and verify the circuit breaker prevents cascading to downstream agents.

Red-teaming cadence should scale with autonomy level. Agents that only suggest actions (L1–L2) can be tested quarterly. Agents that execute autonomously within bounds (L3–L4) should be tested before every deployment and after every significant update. Agents with full autonomy (L5)—if you're deploying them at all—should be tested continuously with automated adversarial scenarios.

For SMEs with limited security resources, a minimum viable red-teaming programme covers the top three risks by impact: ASI01 (Goal Hijack), ASI02 (Tool Misuse), and ASI03 (Identity Abuse). These three risks represent the highest-impact failure modes because they give attackers control over what the agent does, what tools it uses, and what permissions it operates with. If you can defend against these three, you've addressed the scenarios most likely to cause material harm. Expand coverage to all ten risks as resources allow, prioritising based on your specific agent architecture and deployment context.

Document everything. Red-team reports are evidence for ISO 42001 Annex A.6.4 (verification and validation), NIST AI RMF MEASURE MS.3.3 (adversarial testing), and the Colorado AI Act's "discovery measures" component of the safe harbor defense. The testing methodology, scenarios executed, results, and remediation actions all feed the governance evidence chain. A well-documented red-team report covers three compliance obligations simultaneously—that's efficient evidence production. See our agentic AI governance guide for the complete framework context.