OWASP Agentic AI Threats & Mitigations

The LLM Top 10 describes what can go wrong with a model. The agentic threat catalogue describes what goes wrong when that model has memory, tools, an identity, and peers. These are different problem classes. A chatbot failure produces bad text; an agent failure produces state changes in systems you care about, sometimes hours after the triggering input, sometimes through an agent that was never itself attacked. This page works through the agent-specific threats that matter most in practice. Each one is structured the same way — mechanism, why agents make it worse, the detection signal you would actually look for, and the mitigation that holds up — because that is the structure of a good threat model entry and you should be able to produce it from memory.

Memory poisoning

Mechanism. An attacker gets content written into the agent’s persistent memory — a summary store, a user-preference record, a “lessons learned” scratchpad, a shared knowledge base. That content is later retrieved as trusted context and shapes future decisions.

Why agents make it worse. Three properties compound. Memory is persistent, so a single successful injection outlives the session that delivered it. Memory is privileged, because retrieved memories are usually placed high in the context and framed as the agent’s own prior conclusions rather than as untrusted input. And memory is recursive — the agent writes its own summaries, so a poisoned memory can restate and reinforce itself on every subsequent write, surviving even if the original entry is deleted.

The effect is delayed and repeating. The window between injection and impact can be days, which destroys the naive investigative instinct to look at the session where the damage occurred.

Detection signal. A memory record whose provenance chain does not terminate at an operator or an authenticated user action. Also: a sharp behavioural change with no corresponding change in the current session’s inputs, and memory entries containing imperative language (“always”, “from now on”, “do not mention”) rather than descriptive facts.

Mitigation.

{
  "memory_id": "m-8842",
  "content": "User prefers concise summaries.",
  "source": "tool:web_fetch",
  "written_by_session": "s-1193",
  "trust": "untrusted-external",
  "ttl_days": 7
}

The source and trust fields are the entire point. A preference “learned” from a fetched web page should never be indistinguishable from one the user stated.

Tool misuse

Mechanism. The agent is manipulated into invoking a legitimate, authorized tool in a destructive way. Nothing is exploited in the classical sense — the tool works exactly as designed, on arguments chosen by an attacker.

Why agents make it worse. Tool exposure is typically all-or-nothing: if the agent can call send_email, it can email anyone, and the schema does not distinguish “reply to the requester” from “forward the archive externally.” Argument space is the real attack surface, and it is almost never modelled. Worse, tools compose: a read tool plus a write tool plus a network tool is an exfiltration pipeline that no individual tool review would flag.

Detection signal. Calls that are individually valid but statistically anomalous — an unusual argument (external recipient domain, wildcard scope, an unusually large limit), a tool sequence that has never occurred for this workflow, or a destructive call whose justification trace originates in retrieved content rather than user instruction.

Mitigation. Per-tool authorization rather than per-agent. Argument validation with allowlists for the fields that determine blast radius (destinations, scopes, record counts). Dry-run modes that return the diff a call would produce. Approval gates on the irreversible subset. And explicit blast-radius caps — maximum records per call, maximum spend per task — so full compromise still has a ceiling.

Identity spoofing and privilege compromise

Mechanism. The agent authenticates to downstream systems with a credential broader than any single request needs, and downstream systems cannot distinguish which user, or which agent, is really behind a call. Classic confused deputy: a low-privilege actor persuades a high-privilege intermediary to act.

Why agents make it worse. Agents are built to be general, so their credentials get provisioned for the union of everything they might ever do. There is usually one service account shared by every instance, so per-agent attribution is impossible after the fact. Multi-agent systems then pass “user context” as a plain field in a message payload — a self-asserted claim that any compromised peer can forge.

Detection signal. Downstream logs where the actor is a service account for every call, with no user attribution. Tokens with no expiry or scopes far wider than observed usage. Two different tenants’ work appearing under one credential.

Mitigation.

Cascading failures in multi-agent systems

Mechanism. One agent’s output is another agent’s trusted input. A compromised or merely confused agent injects into its peers, and the contamination propagates along the orchestration graph. Separately, agents delegating to each other can form loops with no terminating condition.

Why agents make it worse. Inter-agent messages are almost always treated as trusted by construction — the whole point of the architecture is that agents cooperate. Trust is transitive by default and unlabelled. Meanwhile, the orchestration graph is often dynamic, so “which agents can influence which” is not a reviewable artifact. Loops burn budget and downstream quota fast enough to become an availability incident before anyone notices.

Detection signal. Message depth or fan-out exceeding the designed workflow. The same task ID recurring across many hops. Cost per task diverging from its distribution. Content fingerprints from an external source appearing in the context of agents that never touched external data.

Mitigation. Carry provenance on every inter-agent message — original source, hop count, trust level — and have receiving agents treat externally-derived content as untrusted regardless of which peer relayed it. Define explicit trust levels between agents rather than a flat mesh. Add circuit breakers on depth, hop count, and elapsed time. Cap budget per task, per agent, and per tenant, and fail closed when the cap is hit. Build the graph on paper first: which agents may invoke which, and with what tools. If you cannot draw it, you cannot secure it — see Lab 5 — Threat Model & Risk Register.

Goal and intent manipulation

Mechanism. Rather than injecting a single action, the attacker shifts the agent’s objective. The agent then generates its own plan to serve the corrupted goal, inventing steps the attacker never specified.

Why agents make it worse. Autonomy is the product. An agent that plans is an agent whose plan can be redirected, and a subtly reframed objective (“prioritise completing the task over confirming with the user”) is far harder to spot than an explicit malicious command. Goals also drift silently across long-running tasks with iterative re-planning.

Detection signal. Divergence between the stated task and the executed plan. Steps taken that no reasonable decomposition of the original request would produce. Reasoning traces referencing objectives absent from the original instruction.

Mitigation. Pin the objective outside model-editable context and re-assert it each planning cycle. Validate plans against the original task before execution. Alert on plan steps that touch tools outside the task’s declared tool set.

Unexpected code execution

Mechanism. The agent generates and runs code — in an interpreter tool, a shell, a query engine, or a rendering context — and the generated code does something outside the intended scope.

Why agents make it worse. Code execution tools are the highest-leverage capability you can hand an agent, and they are increasingly default. Generated code is rarely reviewed before it runs, and “sandboxed” frequently means “runs in a container with the agent’s full network access and environment variables.”

Detection signal. Outbound network connections from the execution environment. Access to credentials or files outside the task working directory. Generated code that assembles strings destined for another interpreter.

Mitigation. Execute in a sandbox with no credentials, no ambient network egress, and a filesystem scoped to the task. Allowlist imports and syscalls where feasible. Time and memory bounds. Never share the execution environment across tenants or tasks. Log the full generated source, not just its output.

Threats to mitigations

Which threats matter for which architecture

Not every system carries every risk, and saying so is a mark of judgement rather than laziness. Map the catalogue to the architecture in front of you before you start writing findings.

Two heuristics do most of the work. First, threat severity tracks capability, not model quality — a weaker model with a delete tool outranks a stronger one with a search tool. Second, threats compound where state persists: any component that survives the session (memory, a queue, a shared file store, a vector index) converts a transient failure into a standing one, and deserves disproportionate review attention.

How to use this catalogue

Treat it as a checklist against a real architecture, not reading material. For a system you are reviewing, walk each threat and answer three questions: is the mechanism reachable here, would we see the detection signal today, and which mitigation is actually deployed versus assumed. The gaps between “assumed” and “deployed” are your findings, and they are the ones that make a portfolio artifact credible.

• Vulnerability-class framing of the same ground: OWASP Top 10 for LLM Applications
• Adversary-sequence framing: MITRE ATLAS
• How these fail in production: Incident Patterns
• Depth on agentic controls: Layer 4 — Agentic Security
• Tooling to test the above: Red Team Tools and Observability Tools