Between December 2025 and June 2026, agent security went from a debate to a pair of documents. Ask how to secure an AI agent in 2024 and you got improvisation; ask now and there is a numbered risk list and a 514-requirement checklist to point at. Most teams shipping agents haven't caught up with that shift. This is the plain-language tour: what each framework is, how they differ, and what to do with them.
Start with why they exist at all. The protocol layer most agent stacks are built on ships with four structural gaps: authentication is delegated to the transport, there is no per-tool authorization, no standard agent identity, and no standard audit-log format. None of those is a bug some vendor will patch — they are properties of the protocol, inherited by every deployment on day one. Software that holds real credentials and acts at machine speed, running on a layer with those gaps, fails in ways classic application security frameworks never had to name.
In 2025 and 2026, the naming happened.
What is the OWASP Agentic Top 10?
The OWASP Top 10 for Agentic Applications is the industry-consensus list of the ten most serious security risks in AI systems that can plan, decide, and act — labeled ASI01 through ASI10. Released December 9, 2025 by the OWASP GenAI Security Project and peer-reviewed by more than a hundred experts, it is the closest thing agent security has to a shared threat model.
The provenance matters, because top-ten lists are cheap to write and this one wasn't. The review board included people from NIST, Microsoft's AI red team, and the Alan Turing Institute, and the list is already cited inside major vendors' own agent-security frameworks. More importantly, every entry responds to failure patterns already observed in production — this is a catalog of things that have happened, not things someone imagined.
The distinction it captures is blast radius. A chatbot that fails gives someone a wrong answer. An agent that fails takes a wrong action — with real credentials, on real systems, at machine speed. That is why agents got their own Top 10 instead of a footnote on the LLM list.
Here are all ten, one line each:
- ASI01 — Agent Goal Hijack: hidden instructions in ordinary content — a web page, an email, a document — quietly redirect what the agent is working toward.
- ASI02 — Tool Misuse & Exploitation: the agent's legitimate tools get bent to destructive ends; nothing is "hacked," capabilities are simply misused.
- ASI03 — Identity & Privilege Abuse: agents hold broader credentials than the task needs, so one compromised step acts with all of them.
- ASI04 — Agentic Supply Chain Vulnerabilities: poisoned servers, tools, or skills enter the stack at runtime, from ecosystems that change weekly.
- ASI05 — Unexpected Code Execution: natural-language paths become code-execution paths the original design never drew.
- ASI06 — Memory & Context Poisoning: seeded memory or retrieval content reshapes the agent's behavior long after the malicious interaction ends.
- ASI07 — Insecure Inter-Agent Communication: spoofed or tampered agent-to-agent messages misdirect whole clusters.
- ASI08 — Cascading Failures: one false signal propagates through automated pipelines, gathering blast radius as it goes.
- ASI09 — Human-Agent Trust Exploitation: confident, polished output walks a human approver into signing off on the wrong thing.
- ASI10 — Rogue Agents: compromised, misaligned, or simply drifting agents that keep operating outside monitoring.
We'll publish a fuller plain-language entry on each of the ten; until then, each link above lands on the row of the mapping table that pairs the risk with the controls that counter it. If you run agents, this list is your threat model whether or not you've read it. Your attackers have.
What is AISVS and who needs it?
AISVS — the OWASP AI Security Verification Standard, released June 2026 — is a checklist of 514 testable 'verify that…' requirements across 14 chapters covering the AI layer of your stack. Any team running AI agents or MCP servers in production needs it, because it converts 'we take security seriously' into checks an engineer can run and an auditor can confirm. Most production systems should target Level 2.
AISVS 1.0 shipped at OWASP Global AppSec in Vienna, built by the lineage behind ASVS — the verification standard web-application auditors have relied on for years — and it inherits the house rule: if you can't check it, it doesn't belong in the standard. Every requirement is written as a "verify that…" statement at level 1, 2, or 3, which is what separates a verification standard from a best-practices essay.
One example shows the character of the whole document. AISVS's MCP chapter requires that authorization be validated on every tool call — not once when the session starts. That single requirement encodes a real attack pattern (sessions that outlive the permissions they were opened with), states the control precisely, and can be handed to an engineer on Monday and audited on Friday. Multiply that specificity by 514 and you have the standard.
The fourteen chapters run from training-data integrity through input validation, model lifecycle, infrastructure, access control, supply chain, model behavior, memory and vector databases, agentic orchestration, MCP security, adversarial robustness, privacy, monitoring, and human oversight. For a mid-market agent deployment, six of them do most of the work: C05 access control, C08 memory, C09 agentic orchestration, C10 MCP security, C13 monitoring and logging, C14 human oversight.
Just as telling is what AISVS refuses to cover. General application security stays with ASVS; infrastructure hardening stays with the CIS benchmarks and NIST 800-53. AISVS fences itself to the AI layer on purpose — a discipline worth copying. Any review claiming one standard covers your whole stack is a review to be suspicious of.
How are the Agentic Top 10 and AISVS different?
The Agentic Top 10 is a threat list — it names what goes wrong. AISVS is a verification standard — it specifies what to check so those failures don't happen. One is a map of attacker behavior, the other a checklist of controls. They're built to be used together: findings named in Top 10 terms, fixes verified as AISVS requirements.
The two documents answer different questions, and the pairing is where the value is. A threat list without a verification standard leaves you knowing what to fear but not what to do about it; a checklist without a threat model turns into compliance theater, boxes ticked with no sense of which ones matter. Read together, each risk on the Top 10 points at the AISVS chapters that counter it:
| The risk (Agentic Top 10) | What you verify (AISVS 1.0) |
|---|---|
| ASI01 Goal Hijack — untrusted content redirects the agent | C02 input validation · C07 model behavior |
| ASI03 Privilege Abuse — credentials scoped to convenience | C05 access control — per-agent, per-tool least privilege |
| ASI04 Supply Chain — poisoned components at runtime | C06 model supply chain · C10 MCP security |
The full ten-row mapping — every ASI, its failure pattern, the AISVS chapters that verify the counter, and the NIST AI RMF function it reports under — lives on our method page. It's open; take it and use it.
Which framework should you assess against first?
Assess against the OWASP Agentic Top 10 first — it tells you where you're exposed today — then verify your fixes against the six AISVS chapters that form the working core of an agent review. Those six are access control (C05), memory (C08), agentic orchestration (C09), MCP security (C10), monitoring and logging (C13), and human oversight (C14).
The honest longer answer: don't start by reading either document cover to cover. Start with the four-step spine both frameworks converge on, because it sequences the work:
- Inventory — enumerate every agent, MCP server, tool, credential, and memory store. You can't secure what you haven't listed, and in most deployments the tool list in the config is not the tool list in production.
- Scope — size credentials to the task, not the convenience. An agent that can't call a tool can't be tricked into misusing it.
- Gate — put a human in front of irreversible, high-blast-radius actions, and let reversible, contained ones run. Gating everything just trains approvers to rubber-stamp.
- Log — build the receipts the protocol layer doesn't give you: which agent, which version, which tool call, which outcome.
Work the spine with the Top 10 open as your threat model, and you'll find the exposures that matter. Then use AISVS to turn each fix into something checkable — that's what makes the remediation defensible to an auditor, a customer, or a board rather than a pile of good intentions. If your team only has a week, spend it on inventory and scope; those two steps shrink more blast radius per hour than anything else on this page.
How do these map to NIST AI RMF?
The OWASP frameworks plug into NIST AI RMF's four functions: findings map into Map and Measure, remediation and gating decisions into Manage, and ownership, policy, and accountability into Govern. NIST AI RMF gives boards, auditors, and insurers the language; the OWASP layers supply the technical substance underneath it. Together they let one assessment speak to engineers and directors at once.
NIST's AI Risk Management Framework is voluntary, but it is the de facto vocabulary of AI accountability in the US — the language directors, auditors, and insurers already use when they ask how AI risk is handled. It deliberately doesn't tell you which tool-authorization checks to run; that's not its layer. It asks whether someone owns the risk (Govern), whether you know where it lives (Map), whether you're measuring it (Measure), and whether you're acting on it (Manage).
That is exactly why the combination works. OWASP findings give Map and Measure real content; the spine's scoping and gating decisions are what Manage looks like in practice; and the assignment of ownership for each agent and its credentials is Govern made concrete. One layer down sits the legal clock — the Colorado AI Act has been live since February 2026 for high-risk AI systems, and EU AI Act high-risk obligations land December 2, 2027 — and enterprise customers are already pushing both into vendor due-diligence questionnaires ahead of the deadlines. The full four-layer stack — attack, verification, governance, legal — is laid out on the method page.
What does an assessment against these frameworks produce?
An assessment against these frameworks produces a findings list in OWASP ASI terms, controls verified as AISVS requirements, and a posture summary in NIST AI RMF language — evidence, not opinions. Concretely: an inventory of what your agents can do, per-finding severity with a fix direction, and a remediation order — artifacts you can hand to an auditor, an insurer, or your own engineers.
The practical difference from a generic security review is that nothing rests on "trust us." A finding tagged ASI03 can be looked up; a control phrased as an AISVS requirement can be re-checked by anyone; a readout structured Govern / Map / Measure / Manage needs no translation for the people who approve budgets. The framework tags are what make the deliverable portable — the same document works for your engineers, your auditor, and your customer's due-diligence questionnaire.
That's also the standard you should hold any provider to, including us. If you're evaluating an agent security review — ours or anyone's — ask which framework the findings are named in, which verification standard the controls were checked against, and what language the summary reports in. If the answers aren't specific, you're buying opinions. What a review looks like when it's built this way, scope and pricing included, is on our Agent Security Assessment page.
The frameworks are public, the mapping is on our method page, and the spine is four words long. The era when agent security was a matter of taste ended with page numbers — the teams that internalize that early get to treat it as an advantage rather than hear it from an incident report.
