Agents

The OWASP Threats and Mitigations document inherits its definition from Russell & Norvig: an agent is software that perceives its environment, makes decisions, and takes actions to achieve objectives autonomously. The word "autonomously" is doing the work. It is what separates an agent from a workflow engine that runs predetermined steps. In practice, production agentic systems are rarely single agents: they are networks of orchestrators, peer agents, MCP servers, and shared memory stores coordinating toward a joint goal. The single-agent decomposition below is the analytical baseline that multi-agent topologies layer on top of. Understanding one agent's internals is prerequisite to reasoning about what happens when several of them interact.

What's inside a single agent

A working agent decomposes into the components below. None of them is novel in isolation. What is novel is composing them together, with an LLM choosing the control flow. Most agentic threats target a specific component or the seambetween two components (the interactive view of this lives inthe fintech reference scenario; open it on the canvas and click any agent to see the anatomy with threats placed on each seam). The peer AGENT box (right side of the diagram) represents the multi-agent surface: each inter-agent seam replicates the threat exposure of a single agent and adds cross-peer interaction threats on top.

OWASP reference architecture

An OWASP reference architecture for agentic systems. Use the filter to see how OWASP's three catalogues overlap on the same surface. Click any badge to go to the relevant threat page.

The components

• Planning: decomposes a goal into subgoals and produces the step sequence the action loop will execute.
• Tool Calling / Function Calling: turns a textual plan into a concrete tool invocation with parameters. The trust boundary between "what the model wrote" and "what gets executed."
• Action: executes tool calls, observes results, decides whether to revise the plan or proceed. Logging happens here.
• Memory (short): context window; persists within a session, often for the duration of a single multi-turn task.
• Model (LLM + Function Calling): the foundation model that produces reasoning, plans, and tool-call decisions, plus its function-calling runtime.
• Agent (peer): other reasoning agents the agent coordinates with. Their messages are untrusted inputs to the receiving agent.
• MCP server: a tool, resource, or prompt provider rather than inherently a peer agent. Its descriptions and results remain untrusted context.
• Services: the agent's hands: Content, Code (execution/sandbox), Data (DBs/APIs), Human-in-Loop (approval), Device, and external Service integrations.
• Supporting Services: Long-term memory (vector store, retrieval index) and Vector Datastore. Persist across sessions; highest-leverage poisoning surface.

Which threats hit which component

• Planning: T6 Intent Breaking and Goal Manipulation, T7 Misaligned and Deceptive Behaviors.
• Tool Calling: T2 Tool Misuse, T11 Unexpected RCE.
• Action: T8 Repudiation and Untraceability.
• Memory: T1 Memory Poisoning at every write; T5 Cascading Hallucinations via reflection.
• Model seam: T9 Identity Spoofing, T17 Supply Chain Compromise.
• Peer agents: T12 Agent Communication Poisoning, T13 Rogue Agents, T16 Insecure Inter-Agent Protocol Abuse.
• Human-in-the-Loop: T10 Overwhelming HITL, T15 Human Manipulation.
• Services seam: T2 Tool Misuse, T3 Privilege Compromise, T4 Resource Overload.

Agency scoping matrix

OWASP's Agentic Top 10 measures severity across four autonomy scopes: from no agency (human-initiated, agentic change prohibited) through full agency (automated initiation, automated agent actions). Risk increases dramatically as scope widens.

LLM Top 10 ↔ Agentic Top 10 correlation

The relation is asymmetric. The Agents → LLMs view shows what each agentic risk inherits from the LLM Top 10 (narrow, 1–4 LLM parents per ASI, the way OWASP categorised them). The LLMs → Agents view inverts it: one LLM-level vulnerability fans out to every agentic risk it can cause, which is a wider set. Triggers reach further than categories.Dashed lines in that view are mechanistic connections OWASP describes in body text but did not include in their authored mapping. The crow's-foot end marks the many side of each line.

Single agent vs multi-agent

A single-agent system has one of these. A multi-agent system has many, with inter-agent communication in addition to the components above. Multi-agent threats (T12, T13, T14) and the MAESTRO Cross-Layer catalog exist because the seamsbetween agents are themselves an attack surface. See theA2A primer.

Levels of autonomy

Autonomy is a spectrum, not a binary. The OWASP document describes a range from hardcoded workflows at one end (the agent's choices are tightly constrained by code), through finite-state-machine or LangFlow-style constraints, to fully conversational agents whose decisions depend purely on interactions and model reasoning. The threat profile shifts dramatically along this spectrum, and most controls that work at the constrained end fail at the conversational end.

Where to go next

• RAG primer: how the retrieval surface inside an agent becomes a primary attack target.
• MCP primer: how tool catalogs are exposed to agents and where the trust model breaks.
• A2A primer: what happens at each of the seven steps when agents talk to each other.
• Agentic factors primer: the four properties (autonomy, non-determinism, identity, A2A) that drive the threat profile.
• Threat catalogue: all T1–T51 threats with full detail, mitigations, and MAESTRO layer tags.
• Mitigations catalogue: controls indexed by threat, principle, and MAESTRO layer.
• Security principles: how Defence-in-Depth, Zero Trust, and Least Privilege apply to agentic architectures.
• Threat-modelling wizard: guided walkthrough that maps your architecture against the T1–T51 catalogue.