For the last two years, every enterprise AI security conversation collapsed into one question: is the model going to leak or hallucinate something it shouldn't? That question hasn't gone away — but as of December 2025, it's no longer the most operationally urgent one.
On December 9, 2025, the OWASP Gen AI Security Project published the OWASP Top 10 for Agentic Applications 2026 — a peer-reviewed framework that names the failure modes that show up not when models generate, but when agents act. Most of these don't look like security incidents from inside the model. They look like the agent doing exactly what was asked, using the right tools and the right identity, and producing an outcome no human at the company would have approved.
What OWASP actually published
The official OWASP page describes the list as "a globally peer-reviewed framework that identifies the most critical security risks facing autonomous and agentic AI systems," developed with "more than 100 industry experts, researchers, and practitioners." This isn't a vendor white paper relabeled as a framework — it's the OWASP-track output for agentic systems, and it will become shared vocabulary the way the original Web Application Top 10 did fifteen years ago.
Microsoft's AI Red Team helped review the list before publication. In a Microsoft Security Blog post on March 30, Vice President Efim Hudis of Microsoft's Security CTO Office summarized the ten risks with the official ASI numbering:
- Agent goal hijack (ASI01) — redirecting an agent's goals or plans through injected instructions or poisoned content.
- Tool misuse and exploitation (ASI02) — misusing legitimate tools through unsafe chaining, ambiguous instructions, or manipulated tool outputs.
- Identity and privilege abuse (ASI03) — exploiting delegated trust, inherited credentials, or role chains to gain unauthorized access or actions.
- Agentic supply chain vulnerabilities (ASI04) — compromised or tampered third-party agents, tools, plugins, registries, or update channels.
- Unexpected code execution (ASI05) — turning agent-generated or agent-invoked code into unintended execution, compromise, or escape.
- Memory and context poisoning (ASI06) — corrupting stored context (memory, embeddings, RAG stores) to bias future reasoning and actions.
- Insecure inter-agent communication (ASI07) — spoofing, intercepting, or manipulating agent-to-agent messages due to weak authentication or integrity checks.
- Cascading failures (ASI08) — a single fault propagating across agents, tools, and workflows into system-wide impact.
- Human–agent trust exploitation (ASI09) — abusing user trust and authority bias to get unsafe approvals or extract sensitive information.
- Rogue agents (ASI10) — agents drifting or being compromised in ways that cause harmful behavior beyond intended scope.
Read as a set, the list makes one point repeatedly: agentic failures are rarely "bad output." They are bad outcomes that look correct from inside the model. Pete Bryan, Principal AI Security Research Lead on Microsoft's AI Red Team, put it directly: "Agentic AI delivers a whole range of novel opportunities and benefits. However, unless it is designed and implemented with security in mind, it can also introduce risk."
What the list actually demands: runtime, not pre-flight
Read the ten risks with one filter — can this be fixed before deployment, or only at runtime? The answer is almost always runtime. Goal hijack (ASI01) happens when the prompt the agent sees gets manipulated, after dev review. Tool misuse (ASI02) happens when the chain of tool calls executes, after permissions were granted. Memory poisoning (ASI06) happens when the context being recalled was corrupted by an earlier turn, after the RAG store was hardened. Each is a behavioral failure mode that depends on what crosses the agent boundary at execution time.
The follow-on question is: what controls do we have at the agent boundary, in real time, when the agent is about to act? Most stacks today have three answers:
- Identity and access controls — solid coverage for ASI03 and parts of ASI07, especially in Microsoft Entra Agent ID-class platforms. The most mature layer of the stack today; the Copilot Studio mitigation guidance maps Agent 365 controls to multiple ASI numbers.
- Lifecycle governance for agent definitions — predefined actions, connectors, capabilities, isolated environments, publication gates. The layer that prevents an agent from rewriting its own toolset (ASI10) without re-publishing.
- Behavioral and supply-chain scanning — the OWASP Agentic Top 10 itself, plus CSA's AI Agent Resource Management (AARM) workgroup output and the broader Protocol-Gateway pattern industry is converging toward.
The complementary layers are improving fast. Containment.AI is aligned with — and working toward Core conformance with — the CSA AARM Protocol-Gateway pattern as it stabilizes; an AGT (Agent Governance Toolkit) adapter is in design. None of those layers, including ones we contribute to, fully cover one risk surface: what data the agent is allowed to put in front of the model at the moment of the call.
The gap: data crossing the LLM boundary
ASI01 (goal hijack), ASI06 (memory and context poisoning), and ASI09 (human–agent trust exploitation) share a common substructure: untrusted content reaches the model and changes what happens next. The injected instruction in a fetched document, the poisoned record in a RAG store, the social-engineered approval — these aren't model bugs. They are data-boundary failures. The model is doing exactly what it's trained to do with the inputs it received. The inputs were wrong.
The same is true on the way out. When an agent is about to send an email, write to a CRM, push a commit, or call an API, the question for regulated environments isn't "did the model decide correctly?" It's "is this payload allowed to cross this boundary, in this context, for this user, under this regulation?" That question is not answerable inside the model. It is answerable only at the boundary where data crosses.
That's the layer Containment.AI focuses on. Our proxy and browser extension inspect what's about to leave the organization at the prompt and response boundaries, evaluate it against the customer's policy (HIPAA category, SOC 2 scope, NIST AI RMF profile, FedRAMP boundary, NAIC bulletin scope, FERPA student-record class, etc.), and allow, redact, or block the data movement in real time — with an audit trail that survives an examiner's question six months later.
That doesn't replace identity governance, lifecycle controls, or red-team frameworks. Those layers govern what an agent does next. The data-boundary layer governs what crosses the LLM at all. Both are required. Neither alone is sufficient.
What to do this week
Three concrete steps for teams operationalizing the OWASP Agentic Top 10:
- Map your existing controls to the ten ASI numbers. Microsoft's Copilot Studio mitigation guidance is a useful template — most enterprises find solid coverage on ASI03, ASI04, ASI05, ASI10, and visible gaps on ASI01, ASI06, ASI09.
- Inventory your agent-data boundaries. For every agent in production or pilot, list where untrusted content enters (web, email, RAG, customer chat) and where data leaves (API, CRM, Slack, email). Most teams under-count both.
- Decide where runtime enforcement lives. Identity controls govern the agent. Lifecycle controls govern the agent definition. Something needs to govern the data at the boundary in real time. "The model will refuse" is not a defensible answer in front of an examiner.
The teams that use the list as an operational tool — not just a board-deck slide — will be the ones who can answer the question regulators are already asking: when your agent took the action that caused the harm, what did your runtime controls actually do?