⭐ Star on GitHub

Summary: Summary of the OWASP Agentic Security Initiative’s first report, v1.1 (December 2025) — a threat-model-based reference for agentic AI covering 17 threats, 6 mitigation playbooks and 3 worked threat models.

Sources: raw/Agentic/Agentic-AI-Threats-and-Mitigations-1.1.pdf (50 pp., ~14,800 words)

Last updated: 2026-07-29


What it is

The first in a planned series from the OWASP Agentic Security Initiative (ASI), a workstream of the same OWASP Top 10 for LLM Apps & Gen AI project that produces the Top 10. Co-led by John Sotiropoulos (Kainos) and Ron F. Del Rosario (SAP), with core contributors from SAP, Palo Alto Networks, Zenity, Intuit, Cloudsec.ai, Raft and Commerzbank; reviewed by NIST’s adversarial AI lead, the Alan Turing Institute and the Linux Foundation ML Security project (source: Agentic-AI-Threats-and-Mitigations-1.1.pdf, p. 50). Licensed CC BY-SA 4.0.

Version 1.1 is dated December 2025. The widely-cited v1.0 was February 2025 and carried 15 threats; v1.1 adds T16 Insecure Inter-Agent Protocol Abuse and T17 Supply Chain Compromise. Anything citing “the OWASP agentic 15” is referring to the older revision.

Scope, stated plainly

The document restricts itself to LLM-based agents and to threats that are new or agentically-varied. It explicitly defers general application, API and ML threats to other OWASP material — the Top 10 2021, API Top 10 2023, the LLM Top 10 2025, the AI Exchange, MITRE ATLAS and NIST AI 100-2 (p. 13). Audience is builders and defenders: developers, architects, platform and QA engineers, security professionals.

It also declines to adopt a threat-modelling methodology. STRIDE and PASTA are “rooted in traditional cyber vulnerabilities”; CSA’s MAESTRO is acknowledged as “a comprehensive extension to STRIDE to handle Agentic AI” with a layered architectural lens, but rejected here on two grounds — that “methodologies can impose cognitive barriers,” and that MAESTRO’s coverage of traditional ML and application threats is broader than ASI’s deliberately agentic-only focus (p. 12). Instead the document uses its own reference architecture as the canvas. It recommends practitioners evaluate MAESTRO on its merits.

The four contributions

  1. A reference architecture for single- and multi-agent systems, mapping agent capabilities to deployable components.
  2. The threat taxonomy — T1 through T17, with a six-step decision path for scoping which apply.
  3. Six mitigation playbooks, each split proactive / reactive / detective.
  4. Three worked example threat models — Enterprise Co-Pilots, Agentic IoT (smart-home cameras), and Agent-driven RPA for expense reimbursement (pp. 43–49). The introduction says four; only three appear.

What the framing gets right

Agency is the variable, not the architecture. The document’s central move is to treat autonomy as a spectrum — “hardcoded to constrained via code or finite-state machine workflows (LangFlow) and fully conversational, where decisions depend purely on interactions and model reasoning” (p. 7). Threats attach to capabilities, so the decision path prunes cleanly.

Memory and tools are named as the two key attack vectors. “Agent Memory and Tools integration become two key attack vectors susceptible to memory poisoning and tools misuse especially in contexts of unconstrained autonomy” (p. 13). Both get the vault’s fullest treatment: memory-poisoning and tool-misuse.

The confused deputy is named explicitly. An agent with higher privileges than its user, “tricked into performing unauthorized actions on the user’s behalf,” arising when the agent “cannot distinguish between legitimate user requests with proper authorizations and adversarial injected instructions” (p. 13). This is the cleanest statement of the agentic authorisation problem in the corpus — see identity-and-privilege-threats.

Non-Human Identities get first-class treatment. Machine accounts, service identities and agent API keys “may lack session-based oversight, increasing the risk of privilege misuse or token abuse” (p. 14).

Where it is thin

  • T7 (Misaligned & Deceptive Behaviors) is conceded to be “at an early stage.” Its evidence base is a mix of published lab work and anecdote, including the widely-repeated and officially-denied military drone simulation story (p. 22, Scenario 4). Treat that scenario as illustrative, not documented.
  • Mitigations are stated at the level of intent, not implementation. “Implement memory content validation,” “deploy agent trust scoring,” “require probabilistic truth-checking.” Almost none carry a reference implementation, threshold or tool. The playbooks are a requirements list to hand an architect, not controls to deploy.
  • Several mitigations assume capabilities that do not exist. The document is honest about one: for T13 it notes “cryptographic attestation mechanisms for LLMs do not yet exist” and falls back to controlled hosting (p. 18). Others — “behavioral consistency analysis,” “truthfulness verification models,” “probabilistic truth-checking” — are named without that caveat.
  • RAG is deferred wholesale to LLM08 (p. 14), which is defensible but leaves retrieval-time poisoning underdeveloped relative to the vault’s own treatment.