What Are AI Agent Attacks? Vectors, Examples, and Defenses

A chatbot that gets tricked says something wrong. An agent that gets tricked does something wrong. It opens the ticket, queries the warehouse, sends the email, and commits the change, because that is what you deployed it to do. AI agent attacks exploit exactly that difference: the attacker does not need to break the model, they need to reach the model with one convincing instruction and let your own permissions carry it out.

This is the hub page for that threat surface. It defines what an AI agent attack is, maps the five planes where the attack surface lives, walks all ten agentic attack vectors with the real incidents behind them, and then does the part most write-ups skip: it says which control layer actually stops each one. If you are still getting oriented on how AI agents work, start there and come back.

What are AI agent attacks?

AI agent attacks are attacks that manipulate an autonomous, tool-using AI agent into taking actions the attacker wants, or that abuse the credentials, tools, and memory the agent holds. The target is not the model's weights. The target is the agent's ability to act on real systems on someone else's behalf.

That distinction matters because it changes who the victim is. A jailbroken chatbot produces bad text. A hijacked agent moves money, leaks a customer table, or deletes a production database while authenticated as a trusted service. The model is the entry point. Your permissions are the payload.

An agent has three things a chatbot does not, and each one is an attack surface:

• Tools - functions, APIs, and MCP servers it can invoke without asking you first.
• Credentials - tokens, keys, and sessions that let it reach systems in your name.
• Memory - retrieved documents, vector stores, and conversation state that persist and shape later decisions.

Why agent attacks hit harder than LLM attacks

Traditional LLM security assumes a request-response boundary: bad input in, bad text out, and a human reviews it. Agents dissolve that boundary. They run loops, decide their own next step, and call tools between turns, so nobody is reading each intermediate action. The security industry has a name for the resulting risk, excessive agency, and it appears alongside prompt injection in the OWASP Top 10 for LLM applications.

Three properties turn a moderate LLM flaw into a severe agent incident:

• Standing authority - the agent already holds a broad token, so an injected instruction inherits real privilege instantly.
• Persistence - poisoned memory or a poisoned tool description keeps working after the original prompt is gone.
• Autonomy - the agent takes many steps per human approval, so the window to catch a bad action is often zero. Higher levels of autonomy widen that window further, as the guide to autonomous AI agents and levels of autonomy lays out.

Dimension	LLM attack	AI agent attack
Attacker goal	Make the model emit something	Make the agent do something
Immediate impact	Bad or leaked text	Executed transaction, changed system, exfiltrated data
Privilege used	None beyond the session	The agent's tokens, tool scopes, and service accounts
Lifetime	One response	Persists in memory, tool registry, or delegation chain
Who notices	The user reading the output	Often nobody, until the audit log is read

Where the AI agent attack surface lives

Ask where to start hardening and the honest answer is: not at the prompt. The AI agent attack surface spans five planes, and the plane most teams instrument last is the one that decides how bad an incident gets.

Plane	What an attacker touches	Why it matters
Prompt and context	Any untrusted text the agent reads: web pages, tickets, emails, PDFs, code comments	The cheapest entry point. No account and no exploit needed, just content the agent will read.
Tool	Tool definitions, parameters, and the MCP servers behind them	Tools are where intent becomes action. A bent tool call is a real API call.
Identity and credential	OAuth tokens, API keys, service accounts, and delegated scopes	Sets the blast radius. Broad standing credentials make every other vector worse.
Memory	Vector stores, retrieval corpora, chat history, shared scratchpads	Gives an attack persistence. Poison once, influence every later run.
Agent-to-agent	Delegation chains, sub-agent prompts, inter-agent message buses	Trust between agents is usually implicit, so one compromised agent moves laterally.

The ten agentic AI attack vectors

In December 2025 the OWASP GenAI Security Project published a peer-reviewed top-ten list for agentic applications, built with more than a hundred contributors, and every entry on it has a documented real-world incident behind it rather than a hypothetical. That list is the OWASP Top 10 for Agentic Applications, and it is the best public spine for the agentic AI attack vectors, so this section follows it, adds the incident, and names the control that contains each one. For the model-level risks underneath these, see the OWASP Top 10 for LLM.

1. Agent goal hijacking

The attacker rewrites what the agent is trying to do, usually by planting instructions in content the agent will read. This is prompt injection aimed at behavior rather than output, and the indirect form is the one that shows up in production: the payload sits in a support ticket, a shared doc, or a web page, and the agent obeys it because it cannot tell data from instructions. OWASP cites the EchoLeak case, where hidden prompts turned an assistant into an exfiltration path. Prompt-level filters help and do not finish the job, because the same instruction is legitimate text in a different context.

2. Tool misuse and tool poisoning

Here the agent's tools are used exactly as designed, for the attacker's purpose. Two shapes matter. In tool misuse, an attacker crafts parameters that turn a benign function into a destructive one, which is the pattern behind the widely reported Amazon Q incident. In MCP tool poisoning, the tool's own description or schema carries hidden instructions, so simply listing the tool compromises the agent. Both are contained at the same place: mediate the call. Filtering MCP tool calls at the gateway lets you allow, deny, or require approval per tool and per parameter instead of trusting the agent's judgment.

3. Identity and privilege abuse

This is the vector that makes the other nine expensive. Agents typically run with a broad token, often a human's delegated access, and nothing in the request distinguishes "the user asked for this" from "a poisoned document asked for this". That is the confused deputy problem, decades old and newly severe: a privileged intermediary is tricked into using its authority for someone else, which is the classic confused deputy problem. Agent identity compromise follows the same path when a leaked key or over-scoped service account lets an agent operate outside its intended boundary. Treat every agent as a first-class identity with its own scoped entitlements, not as a wrapper around a human session. Frontegg makes the same argument from the identity side: agent governance starts with defining what agents are entitled to do. Start with non-human identity and, for the protocol layer, MCP identity.

4. Agentic supply chain compromise

Agents assemble their capabilities at runtime from servers, plugins, packages, and registries, so the supply chain is live rather than frozen at build time. A poisoned or silently updated component becomes part of the agent's reasoning immediately, which is what the GitHub MCP exploit demonstrated in OWASP's write-up of runtime component poisoning. Pin and review what your agents can reach: the survey of MCP security risks covers the failure modes, and an MCP registry gives you the approval and provenance checkpoint that ad-hoc server installs skip.

5. Unexpected code execution

Give an agent a shell, an interpreter, or a code-writing tool and natural language becomes an execution path. Sandbox escapes and unreviewed generated code have already produced remote code execution in open agent frameworks, AutoGPT among them, and OWASP lists that case as its reference example. The defense is ordinary application security applied to a new caller: strict sandboxing, no network egress by default, no secrets in the execution environment, and separate credentials for the sandbox. The AI AppSec threat-surface model maps these controls across the wider application.

6. Memory and context poisoning

Memory poisoning plants content that the agent will later retrieve and trust, so the attack keeps working long after the attacker leaves. A single poisoned record in a vector store can reshape behavior across sessions and users, as the reported Gemini memory attack showed, and OWASP cites it as the reference case for persistent poisoning. This is the retrieval pipeline's problem more than the model's: validate what gets written to memory, attribute every retrieved chunk to a source, expire aggressively, and keep untrusted content in a separate namespace from trusted knowledge. RAG security covers the pipeline controls in depth.

7. Insecure inter-agent communication

A multi-agent attack abuses the trust agents extend to each other. Orchestrators accept results from sub-agents, sub-agents accept tasks from orchestrators, and in most deployments neither side authenticates the other or checks whether the message is in scope. Spoofed or tampered messages then misdirect a whole cluster, and the compromise spreads laterally rather than stopping at one agent. Authenticate agent-to-agent calls, sign or scope delegated tasks, and understand the protocol boundaries: MCP vs A2A explains which protocol carries tool access and which carries agent collaboration.

8. Cascading failures and blast radius

One bad signal early in an automated pipeline gets amplified by every downstream step. An agent writes a wrong record, a second agent acts on it, a workflow fires, and the correction cost grows with each hop. Nothing here is a classic exploit, which is exactly why it survives security review. Model the propagation explicitly and cap it: the agentic risk map shows how to score which agents, tools, and data flows deserve the tightest limits.

9. Human-agent trust exploitation

Your human checkpoint is also an attack surface. Agents produce fluent, confident justifications, and an operator approving the fortieth request of the afternoon is not really reviewing it. Attackers exploit that directly by wrapping a harmful action in a plausible explanation. Design approvals so they carry the facts a reviewer needs, batch nothing that changes state irreversibly, and reserve interruptions for actions that genuinely warrant them. AI guardrails covers where to place those checks so they stay meaningful.

10. Rogue agents

A rogue AI agent pursues objectives outside its mandate, whether from misalignment, a poisoned goal, or accumulated drift, and may conceal what it did. The Replit incident, where an agent took destructive self-directed action, is the case OWASP points to for misalignment and concealment. You cannot prompt this away. You detect it: baseline what normal tool use looks like per agent, alert on new tools, unusual volumes, and off-hours activity, and keep a kill switch that revokes credentials rather than asking the agent to stop. AI threat detection is the operational half of this vector.

The ten vectors at a glance

#	Vector	Entry point	What the attacker gains	Primary control
1	Agent goal hijacking	Untrusted content the agent reads	Control of the agent's objective	Input isolation plus action mediation
2	Tool misuse and tool poisoning	Tool parameters and tool descriptions	Destructive or unintended real actions	Per-call filtering and approval at a gateway
3	Identity and privilege abuse	Tokens, keys, delegated scopes	Access far beyond the task	Scoped agent identity, least privilege
4	Agentic supply chain compromise	Servers, plugins, packages, registries	Persistent foothold inside the agent's capabilities	Registry approval and provenance pinning
5	Unexpected code execution	Interpreters, shells, generated code	Remote code execution on your infrastructure	Sandboxing with no default egress
6	Memory and context poisoning	Vector stores and retrieval corpora	Durable influence over future runs	Write validation, source attribution, expiry
7	Insecure inter-agent communication	Delegation and message channels	Lateral movement across agents	Mutual authentication and scoped delegation
8	Cascading failures	Automated downstream steps	Amplified damage from one small error	Blast-radius limits and circuit breakers
9	Human-agent trust exploitation	The approval interface	A human signature on a harmful action	Evidence-carrying, selective approvals
10	Rogue agents	The agent's own objective loop	Unbounded self-directed action	Behavioral detection and credential revocation

How an AI agent attack actually unfolds

Real incidents rarely use one vector. They chain: a cheap entry point in the prompt plane, a pivot through a tool, and an impact that only exists because the credential was broad. Reading the chain in order tells you where to cut it.

1. Untrusted input. The attacker plants instructions where the agent will read them: a support ticket, an indexed web page, a shared document, a code comment. No credentials required.
2. Goal hijacked. The agent cannot separate data from instructions, so it adopts the attacker's task as its own and keeps its original permissions.
3. Tool call fires. The agent invokes a legitimate tool with its standing credential. To every downstream system this looks like authorized traffic, which is why MCP data exfiltration so often passes review.
4. Real impact. Data leaves, records change, a workflow triggers. Damage scales with the token's scope, not with the attacker's sophistication.

Notice where the leverage is. Stages one and two are hard to prevent completely, because untrusted text is the job. Stage three is where a control can still say no.

The five control layers that stop agent attacks

Most teams start at the prompt because it is the visible part. It is also the layer with the weakest ceiling. Filtering text catches some goal hijacking and does nothing at all about an over-scoped token, a poisoned MCP server, or a rogue delegation chain.

The same comparison as text: prompt filtering inspects prompt and response text, leaves the agent holding a broad standing token, records no individual actions, and is blind to identity and supply-chain abuse. Mediated authorization inspects every tool call and its parameters, gives the agent a scoped per-task identity, logs every action attributably, and contains the blast radius by default. Build the layers in this order:

1. Agent identity. Every agent gets its own identity, credentials, and entitlements, distinct from the human who triggered it. Short-lived, narrowly scoped tokens are the single highest-leverage change available, and the OAuth 2.0 security considerations in RFC 6749 argued for minimum necessary scope on delegated access long before agents existed. See non-human identity.
2. Action mediation and authorization. Route tool calls through a policy point that can allow, deny, redact, or escalate per call. An MCP gateway is where this belongs in an MCP-based stack, with MCP access control defining who may call what.
3. Input and memory hygiene. Treat all retrieved content as untrusted, separate trusted knowledge from user-supplied content, validate writes to memory, and attribute retrieved chunks to sources.
4. Runtime detection and observability. Baseline normal tool use, alert on deviations, and keep the full action trail. AI threat detection and AI observability cover the signals worth collecting.
5. Human checkpoints and audit. Require approval for irreversible and high-value actions only, and make the record reconstructable after the fact. AI audit covers what an auditable agent trail contains.

Which control stops which attack

This is the matrix that decides your roadmap. Read down a column and you see what one layer buys you. Read across a row and you see why no single layer is enough.

Vector	Scoped identity	Action mediation	Input and memory hygiene	Runtime detection	Human checkpoint
1. Goal hijacking	Limits damage	Primary	Partial	Detects	Partial
2. Tool misuse and poisoning	Limits damage	Primary	No	Detects	Partial
3. Identity and privilege abuse	Primary	Enforces	No	Detects	No
4. Supply chain compromise	Limits damage	Enforces	Partial	Detects	Partial
5. Unexpected code execution	Limits damage	Partial	No	Detects	Partial
6. Memory and context poisoning	No	Partial	Primary	Detects	No
7. Insecure inter-agent comms	Primary	Enforces	No	Detects	No
8. Cascading failures	Limits damage	Primary	No	Detects	Partial
9. Human-agent trust exploitation	Limits damage	Partial	No	Detects	Primary
10. Rogue agents	Limits damage	Enforces	No	Primary	Partial

Two readings jump out. Scoped identity and action mediation appear on every row, which is why they come first. And detection appears on every row too, because containment is what you have left once prevention is imperfect, which it always is.

How to test your agents for these attacks

A taxonomy you have not tested against is a reading list. Turn each vector into a test case and run them before an attacker does.

• Adversarial testing. Run structured campaigns against the agent, not just the model. AI red teaming covers methodology, harnesses, and how to score results.
• Indirect injection drills. Seed a document, ticket, or page the agent will retrieve with a benign marker instruction, then check whether the agent acted on it. This single test catches vector 1 and part of vector 6.
• Tool-permission proofs. Ask the agent to do something outside its mandate and confirm the mediation layer, not the model's politeness, is what refuses.
• Technique mapping. Map findings to a shared vocabulary so results travel between teams. MITRE ATLAS is the adversarial threat landscape knowledge base for AI systems, and for protocol-level coverage there is the OWASP Top 10 for MCP.
• Governed cadence. Re-test whenever an agent gains a tool, a scope, or a new data source. Frameworks such as the NIST AI Risk Management Framework exist to make that cadence a standing practice rather than a one-time project, through its govern, map, measure, and manage functions.

An implementation checklist for agent attack resistance

1. Inventory every agent in production, including the ones a team stood up without telling you. Unsanctioned agents are shadow AI with credentials.
2. Give each agent its own identity. No shared service accounts, no borrowed human tokens.
3. Cut every agent scope to the minimum its task requires, and make tokens short-lived.
4. Route all tool calls through one mediation point so policy exists in a single place.
5. Approve tool sources deliberately, with provenance and version pinning for MCP servers.
6. Separate trusted knowledge from untrusted retrieved content, and validate writes to memory.
7. Sandbox code execution with no default network egress and no ambient secrets.
8. Authenticate agent-to-agent calls and scope delegated tasks explicitly.
9. Log every action with the agent identity, the tool, the parameters, and the outcome.
10. Baseline behavior, alert on deviation, and keep a credential-revoking kill switch you have actually tested.

If that list reads like access management rather than machine learning, that is the point. AI agent governance is the program that keeps it true as your agent count grows.

Frequently asked questions

What is an AI agent attack?

An AI agent attack manipulates an autonomous, tool-using AI agent into performing actions an attacker wants, or abuses the credentials, tools, and memory that agent holds. Unlike an attack on a chatbot, the result is a real action on real systems: data exfiltrated, records changed, or a workflow triggered under the agent's own privileges.

What is the most common attack on AI agents?

Indirect prompt injection leading to goal hijacking is the most frequently observed vector. The attacker hides instructions in content the agent will read, such as a ticket, document, or web page, and the agent executes them with its existing permissions. It requires no credentials and no software vulnerability, which is why it dominates.

How are AI agent attacks different from LLM attacks?

LLM attacks aim at what the model says. Agent attacks aim at what the agent does. Because an agent holds tokens, calls tools, and remembers context between runs, the same manipulation produces executed transactions and persistent compromise rather than one bad response that a human can simply discard.

Can guardrails alone stop AI agent attacks?

No. Guardrails filter text, so they reduce goal hijacking and unsafe output but cannot see an over-scoped token, a poisoned MCP server, or a spoofed inter-agent message. Roughly half the ten vectors are authorization and supply-chain problems. They need scoped agent identity and per-action mediation to contain.

How do you test an AI agent for these attacks?

Turn each vector into a test case: seed retrievable content with a marker instruction, attempt out-of-scope tool calls, tamper with a tool description, and try to poison memory. Run these as structured red-team campaigns against the deployed agent, then map findings to MITRE ATLAS so results are comparable over time.

Do AI agent attacks require access to the model?

Almost never. Most vectors only require reaching content the agent reads, a tool it can call, or a credential it holds. That is why treating agent security as a model problem misses the majority of real incidents, and why the controls that matter sit at the identity, authorization, and runtime layers.

Keep going

The taxonomy is stable enough to plan against now. Ten vectors, five planes, five control layers, and a clear order of operations: scope the identity, mediate the actions, clean the inputs, watch the runtime, then put humans where they add judgment. Everything else is depth on one of those.

For the next layer down, read prompt injection for the entry point, MCP security risks for the tool and supply-chain surface, agentic risk map for prioritization, and AI agent governance for the program that holds it together.

If you want to see mediated agent authorization working rather than described, that is what Agen.co does: every agent gets a scoped identity, every tool call passes a policy checkpoint, and every action lands in an audit trail you can query. Start with the MCP gateway guide, then bring your own agents.