This is a practical guide to assessing the security of an agentic AI system.
It covers how to model the target, the attack classes, the controls that stop them, and a methodology for running an engagement from start to finish.
There are many ways to attack AI, but what we care about most are the ones that let us act on a target, not just talk to it.
Getting a model to misbehave, to swear or break character, proves you can push it off-script, but on its own it reaches nothing behind it.
That is a curiosity, not a compromise.
The attacks that matter are the ones that reach through the model to something real: data taken, an action performed, a system touched.
What an AI agent actually is
People call a lot of things “agentic AI” these days. (buzzword!)
Some are a fixed pipeline with a model bolted in: it retrieves, summarizes, and responds the same way every time. Others choose their own actions based on what they see. Both get called agents, so the label tells you little.
What matters is where a system sits on the spectrum of autonomy, because that is what sets its attack surface. An AI agent is a language model connected to tools with some authority to act, anywhere from a chatbot answering from one source to a system with full control over its environment.
Defining the Target
For the purposes of an assessment, the product category and the framework it runs on do not matter. What matters is the answer to five questions about the specific deployment in front of you.
Untrusted input. Which inputs can an attacker put content into, and does the agent trust that content? Direct prompts are obvious. The dangerous ones are indirect: pages it browses, documents it ingests, chunks it retrieves, its own memory, tickets, emails, and the output of other agents.
Tools. What can it actually do? Rank every tool by the severity of the action it enables, from reading a record to moving money.
Privilege. With what authority, and as whom? A read-only scope and a shared admin credential are different targets, even behind the same tool.
Processing. What interprets its output downstream? A tool call that becomes a database query, a shell command, a chosen URL, or executed code is an injection sink with the model feeding it.
Output. Where can data go? Every sink is a potential exfiltration path, including the ones that do not look outbound.
Answer those five together and you have the agent’s real attack surface. Everything below is how you cross it.
AI Agent Vulnerabilities
Now that we know what the agent is connected to, let’s look at why those connections can be turned against it.
The core weakness is in the model: it cannot separate instructions from data.
A user message, a retrieved document, a tool’s output, another agent’s reply, all reach the model on one channel and are read the same way. Content becomes commands. This is injection, the same bug that has hit databases and shells for decades, and it is the entry point for most attacks on agents.
The agent inherits that flaw and raises the stakes: this interpreter can send email, run code, and call other agents.
The full catalog of what can go wrong is the OWASP Top 10 for Agentic Applications (2026), ten risk categories, ASI01 through ASI10:
ASI01 Agent Goal Hijack. Untrusted input redirects what the agent is trying to do, turning its own objectives against its owner.
ASI02 Tool Misuse and Exploitation. A legitimate tool the agent already has is turned to the attacker’s ends.
ASI03 Identity and Privilege Abuse. The agent’s own authority, credentials, or delegated access is inherited or escalated.
ASI04 Agentic Supply Chain. A poisoned tool, model, plugin, or dependency is trusted before the agent even runs.
ASI05 Unexpected Code Execution. The agent’s output reaches something that runs it, a shell, an interpreter, a parser.
ASI06 Memory and Context Poisoning. Corrupted memory or retrieved context persists across sessions and steers future reasoning.
ASI07 Insecure Inter-Agent Communication. One agent trusts another’s messages by default, so a compromised agent can steer its peers.
ASI08 Cascading Failures. A single fault propagates across agents and workflows, compounding into system-wide impact.
ASI09 Human-Agent Trust Exploitation. The person approving the agent’s actions is the target, misled by a routine-looking summary.
ASI10 Rogue Agents. An agent’s behavior drifts from its intended purpose and it acts against its owner.
Keep these in mind as you read the attack stages below. Each stage is a place where one or more of these weaknesses gets exploited, and the next section walks that exploitation in order.
The AI Agent Kill Chain
A kill chain breaks an attack into ordered stages, from first contact to final objective, so defenders can see it in motion and cut it off at any step.
The original, Lockheed Martin’s Cyber Kill Chain, was built for that era’s threat: the advanced persistent threat that breaks in to dwell for months, which is why its later stages are about getting in and staying in.
Modern attacks against AI agents move through four steps: find the way in, get the agent to act on your input, turn that into real impact, and take what you came for.
This is an adaptation of the Cyber Kill Chain for AI agents, not a new framework. It keeps the original’s logic and maps it to how an agent attack actually moves.
Stage 1. Recon: find the way in
You cannot attack what you have not mapped.
Recon against an agent is the five questions turned into legwork, and it produces one thing: a complete map of where your input can enter, what the agent can do with it, and what sits behind each door.
Everything downstream depends on the quality of this map. The goal here is not a clever prompt. It is inventory.
Recon splits into what you can learn without engaging the agent’s decision-making, and what you learn by probing it directly.
Passive recon: what the deployment tells you for free
Before you send a single adversarial input, establish the shape of the system.
How it is delivered. A public website, a mobile-only app, an API, a Slack bot, a browser extension. This decides your tooling before anything else.
A mobile-only assistant has no web traffic to watch, so the only way to see what it sends its backend is to intercept the traffic coming off a phone.
A web app exposes its calls in the browser’s own network tab. The delivery channel is the first fact that shapes the engagement.
What it connects to. Every integration you can see from the outside: linked accounts, connected data sources, advertised tools, third-party services. Each connection is both a place your input might enter and a place the agent’s actions might land.
What it is built on: the whole stack, not just the model
Every agent runs somewhere. There is a machine, and that machine has an operating system, network services, other applications, and a runtime, long before you reach anything AI-specific. All of it is attack surface.
Map the stack from the metal up, because a compromise rarely stops at the layer it began in: influence over the model becomes code execution in the runtime, which becomes access to the host, which becomes reach into the network the host sits on.
Host, OS, and services. Where the agent runs and what runs alongside it: a cloud instance, a container, or a serverless function, plus the operating system and everything listening on it, from SSH to databases to internal APIs.
These are the same things you would enumerate on any server, and cloud metadata endpoints, mounted volumes, and neighboring services all become reachable once you have execution. Often the agent is the way in and the host is the prize.
Runtime and sandbox. What the agent’s code, and any code it generates, executes inside: a Python interpreter, a container, a WASM sandbox.
The strength of that boundary decides whether code execution stays contained or becomes host compromise.
Framework and orchestration. The software wiring the model to its tools, memory, and sub-agents. Named frameworks carry named defaults and named weaknesses, and how a framework runs tool calls, some by generating and executing code, is frequently the difference between a contained action and arbitrary execution.
The model and its guardrails. Only at the top do you reach the model itself, its system prompt, and any classifier screening its input and output. This is where most people start. It should be where you finish, because everything beneath it is surface they have already skipped.
Active recon: fingerprinting the architecture
Active recon is a few deliberately chosen inputs that reveal how the system is built by how it reacts. You are not exploiting anything yet. You are reading the architecture off the responses.
A single off-topic question is often enough to expose the layers. Ask something the agent has no reason to answer, and watch what happens.
If it returns nothing, it is probably keyword search with an AI label. If it refuses politely, there is a model with a system prompt.
If it refuses with a flat, identical rejection before the model could have reasoned at all, there is a separate classifier sitting in front of the agent, screening input before it ever reaches the model.
That last response is the tell that you are facing a gateway you will have to get through. A few questions like this, chosen to probe different behaviors, tell you whether there is real retrieval behind the agent, whether a guardrail model is watching, and how tightly the system prompt is scoped, all before you have tried a single payload.
Mapping the input paths the interface hides
This is the step most testers skip, and it is where the real surface lives. An agent is still an application, and its chat box is rarely its only input.
Input comes in two kinds, and the second is the one people forget. There is what someone sends the agent directly, the interactive channels: a web chatbot, a mobile app, a Slack or Telegram bot, an email address it answers, an API endpoint.
Then there is what the agent reads on its own without anyone addressing it, the ingested channels: documents it summarizes, pages it browses, tickets and emails in a queue, calendar entries, retrieved chunks, another agent’s output. Both are input.
The interactive channels are where testers look; the ingested ones are where indirect injection lives, because content arrives as instruction with no suspicious user in the transcript.
Within those two kinds, the paths that matter most are the ones the interface never shows you.
Alternate input fields. A search field, a filter, an autocomplete, each of which may be routed to the backend on a different path than the chat, and may skip the protections placed on the chat.
API parameters. The raw request the client sends often carries fields the interface does not expose, and those fields may reach the model with less scrutiny.
Sub-agent and tool calls. Traffic between the main agent and its sub-agents, or the results a tool returns, which the front end never renders and the screening layer often never inspects.
Indirect ingestion points. Anything the agent reads on its own: documents, retrieved chunks, emails, calendar entries, browsed pages. These never appear in a request you send, but they are input all the same.
You find these the way you find them in any web application, by putting a proxy between the client and the backend and reading the actual traffic.
Burp Suite, mitmproxy, or the browser’s own network tab will show you the full request structure, including the fields the interface hides.
Where an app defends its traffic with certificate pinning, you defeat the pinning first, in an emulator with an instrumentation tool, so the traffic becomes readable.
The payoff is the same every time: the real map of input paths is almost always larger than the chat box suggests, and the gap between a guarded path and an unguarded one is frequently the whole attack.
What you are hunting for
The output of recon is a target map:
It includes every place your input can enter, every tool the agent can call, every credential behind those tools, and every system its actions can reach.
Once you start probing, the first thing you look for is the earliest sign of influence, any channel where your input begins to affect the agent’s behavior. The moment you see that, recon is done and you have found the way in.
Stage 2. Exploit: get the agent to act on your input
Exploitation is the moment your input crosses from data the agent reads into instruction the agent follows.
The agent cannot reliably tell the two apart, which is the whole game, and it is why this is injection with no prepared statements: the data channel and the instruction channel are the same by design.
Recon told you where your input can enter. Exploitation is getting one of those entry points to steer the agent.
The channels matter more than the wording of any single payload, because most of them are indirect, and the indirect ones remove you from the session entirely.
Direct injection
The obvious channel: you type instructions into the agent’s primary input and try to override its behavior. It is the easiest to attempt and the one every guardrail is built to catch, so on a defended target it is rarely where the attack succeeds.
It is still worth doing first, because it establishes the baseline of what the front door blocks, which tells you what the indirect channels have to get around.
Indirect injection through ingested content
The agent reads far more than what you type. It browses pages, ingests documents, opens files, and summarizes emails, and the content of that data is treated as instruction rather than information.
Hide instructions where a human never looks, in alt text, HTML comments, metadata, off-screen text, or zero-width characters, and the agent reads them as commands.
This is the dangerous half of injection, because there is no malicious user in the transcript and no suspicious prompt to rate-limit. An attacker who can place a file in a drive the agent indexes has a persistent, zero-click instruction channel into the system.
Retrieval and memory
Poison a document that later gets retrieved, or write to the agent’s long-term memory, and your instructions arrive pre-prompt, in the position the agent trusts most.
Memory is worse than a prompt for the defender and better for the attacker: the agent tends to trust it more than live user input, and it survives the session, so the instruction fires again on future runs without you being present.
Sub-agents and tool output
Screening usually watches the main agent’s input and output, not the traffic between its sub-agents or the results its tools return.
Land your payload in a tool’s response or a sub-agent’s message and it sails past the filter, because the filter was never watching that path. This gap is close to universal, which is why the input-path mapping in recon pays off here.
Poisoned tooling and dependencies
The agent’s own supply chain is an input channel. A tool it installs, a plugin it loads, a connected server it queries, or a dependency in its stack can carry instructions or malicious behavior that the agent treats as trusted by default.
A tampered tool descriptor or a hostile connected service does not look like an attack from the chat side, because the injection rides in through the machinery the agent relies on rather than anything a user typed.
The human in the loop
When an agent’s actions are gated behind human approval, the human is a channel too. The approval is only as good as the summary the person sees, and that summary is generated by the same system you are influencing.
A misleading or incomplete description of what the agent is about to do turns the human’s trust into your access: they approve a step that reads as routine and authorizes the thing you actually wanted. Approval fatigue does the rest.
The signal that tells you a channel is live
Getting the model to break character or leak its system prompt is not a finding on its own. It is a signal, the crash a fuzzer gives you before the exploit: proof that this channel can move the agent off its intended behavior.
That soft boundary is where you concentrate, because the value is not in the misbehavior itself but in what you chain it into next.
Stage 3. Execute: turn that into real impact
Influence is not impact. Exploitation gets the agent to act; execution is where that action produces a real effect.
This is the stage that separates a finding from a curiosity. If the influence never produces an effect, you have a party trick. If it does, you have a compromise.
There are two ways an action becomes impact, and the first is the one people forget.
Path one: the capability is already the attack
Often you need no sink and no code execution at all. The agent already holds a capability that is the whole objective, and all you have done is point it at your target.
If it can read a record and put the result somewhere you can see, you have exfiltrated data with nothing more exotic than the agent doing its job. If it can send an email, move money, or delete a file, the impact is that tool firing exactly as designed, for the wrong person.
This is the common case, and the quiet one. Consider an assistant that can read your files and answer questions about them. Get it to pull sensitive content into a response and send that response somewhere you control, through a reply, a link it fetches, an outbound call, and you have exfiltrated data without a single classic vulnerability.
Read, then leak. Or consider an agent wired to a payments tool or a connected wallet: get it to issue one transfer and the tool does exactly what it was built to do, on your instruction. No interpreter was tricked into running code. A sanctioned capability was redirected, and that was the entire compromise.
When the objective is data, this is usually the whole path. If the agent can reach the data and has any outbound channel, even a log line or an image fetch, the attack is complete without touching a single classic vulnerability class.
Path two: the action lands in a sink
The louder case is when the agent’s output becomes another system’s input, and that system runs it. Every one of these handoffs is a familiar bug class waiting for a source, with the model as a naive, cooperative supplier of parameters.
A tool call that builds a database query is SQL or NoSQL injection.
One that runs a shell command is command injection.
One that fetches a URL the model chose is server-side request forgery, often straight at internal services or cloud metadata.
One that renders a template or runs generated code is remote code execution.
One that constructs a file path is traversal.
One that passes data into a deserializer is an unsafe-deserialization bug.
None of these are new. They are the same sinks the industry has fought for decades, now fed by a model instead of a form field. This path is how a foothold becomes code execution and, from there, the host and the network behind it, which is why it gets the attention. It is just not the only way to win, or even the most common one.
Why a benign action can be catastrophic
Either path turns on the same fact: the agent’s action can look completely ordinary and still be the whole exploit, depending on where it lands. “Parse this spreadsheet” is a normal request. It becomes code execution when the parser evaluates a cell’s contents instead of reading them.
“Summarize my inbox” is a normal request. It becomes exfiltration when the summary is addressed to an attacker. Same tool, same action, entirely different outcome, decided by what sits on the other side.
This is why recon mapped both what interprets the agent’s output and what the agent can already reach: the impact is decided there, not in the prompt.
The trust that makes it work
Whichever path you take, the action runs with the agent’s own authority.
Whatever credentials, scope, and reach the agent has, the action inherits, which is why an over-permissioned agent turns a small foothold into a large compromise.
Access gated only at the agent level, where the agent supplies its own identifier and is trusted to ask for only what it should, collapses the moment you control what it asks for.
Stage 4. Actions on Objectives
Once the agent acts under your influence and its actions reach real systems, its reach is now yours. The objective is a menu, and you pick one or more.
Exfiltrate
Steal whatever the agent can reach: user data, internal files, secrets, and the model’s own system prompt. Every output path is a potential exit, including ones that do not look outbound, a log, a report, a counter, an image fetch, an outbound request.
A read-only agent that can still write somewhere observable has a channel you can turn into a leak.
Act
Make the agent do something through its tools: send mail, move money, change records, open or close resources. This is the objective with no equivalent in a passive system, and it is why an agent wired to real actions is worth attacking at all.
Deny
Sabotage rather than steal: encrypt, delete, corrupt, or take a system offline, or simply exhaust it by driving expensive operations until it falls over.
The objective here is availability, not secrecy.
Persist
Hold ongoing control across turns or sessions by poisoning memory, planting state the agent reloads and trusts, or patching the runtime it reasons in.
Persistence is optional, and plenty of attacks skip it, but when the objective needs more than one shot, this is how the foothold survives cleanup of the original entry point.
Propagate
Reach the other agents that trust the one you already own.
In a multi-agent system, trust between agents is usually unverified, so a single compromise becomes a fleet compromise: smuggle instructions over a trusted session, or let one agent share its access with the rest.
AI Agent Attacks in the Real World
Here are five real incidents, each moving through the four stages and mapped to the OWASP Agentic Top 10.
The mappings are OWASP’s own, from its incident tracker. The kill-chain breakdowns show how each attack moved; where the public record is thin, they describe the shape rather than reported detail.
1. Zero-click data theft: EchoLeak
A crafted email reached Microsoft 365 Copilot, and without the victim ever clicking anything, the assistant pulled the attacker’s hidden instructions into its context and exfiltrated confidential emails, files, and chat logs.
OWASP mapping (ASI01, ASI02, ASI06): the injected email hijacks the agent’s goal (ASI01) at Exploit; it rides in through retrieved content, poisoning the context Copilot reasons over (ASI06); and it turns Copilot’s own retrieval and rendering into the exfiltration path (ASI02) at Execute.
Recon. The attacker knows Copilot ingests email into its context without the user opening anything.
Exploit. A crafted email carries hidden instructions that Copilot reads as commands when it processes the inbox.
Execute. Copilot pulls sensitive content into its response and sends it out through a link the client fetches automatically.
Actions on Objectives. Confidential data leaves. One email, no click, no foothold needed.
2. Poisoning a coding agent: Amazon Q
A destructive prompt was slipped into the Amazon Q Developer extension and shipped to users. The agent read the planted instruction as guidance and was steered toward wiping files.
OWASP mapping (ASI01, ASI02, ASI04): the poison enters through the extension’s supply chain (ASI04) before the agent even runs; once loaded, it hijacks the agent’s goal (ASI01) and drives its file and system tools toward destruction (ASI02).
Recon. The attacker targets the extension’s release pipeline, not the end user.
Exploit. A malicious prompt is committed into the extension so every install carries it as trusted instruction.
Execute. The agent acts on the planted prompt, invoking its own tools against the developer’s files.
Actions on Objectives. Destruction of local data, at the scale of everyone who installed the update.
3. Turning a CRM assistant into a leak: ForcedLeak
An indirect prompt injection against Salesforce Agentforce let an outside attacker steer the agent into exfiltrating sensitive CRM records beyond the organization.
OWASP mapping (ASI01, ASI02): attacker-controlled content placed where the agent would read it hijacks its goal (ASI01) at Exploit, then turns its legitimate CRM query tools into an exfiltration channel (ASI02) at Execute.
Recon. The attacker finds a field the CRM agent ingests that outsiders can write to.
Exploit. Injected content in that field is read by the agent as instruction, not data.
Execute. The agent runs its own record-access tools with the attacker’s intent behind them.
Actions on Objectives. Sensitive customer records are pulled and sent outside the org.
4. An agent that destroyed production and hid it: Replit
During an automated coding session, an agent deleted a production database, then generated false output to cover the mistake, presenting fabricated results as if the work had succeeded.
OWASP mapping (ASI01, ASI09): the agent’s behavior drifts from its instructions and it takes a catastrophic action outside its intended goal (ASI01), then exploits the human’s trust by fabricating a plausible account of what happened (ASI09), so the operator does not catch the damage.
Recon. Not an external attacker here; the risk is an autonomous agent with production access and weak guardrails.
Exploit. The agent misreads its own task and decides a destructive operation is the right next step.
Execute. It runs the deletion against a live production database with its granted credentials.
Actions on Objectives. The data is gone, and the agent reports success with fabricated output, delaying detection.
5. Compromising a fleet through trust: Agent-in-the-Middle
A malicious agent published a fake agent card in an open agent-to-agent directory, claiming high trust. A coordinating LLM selected it, and the rogue agent intercepted sensitive data and passed it to unauthorized parties.
OWASP mapping (ASI03, ASI06, ASI07, ASI08, ASI10): the fake card forges identity to win trust (ASI03), the poisoned directory entry corrupts what peers believe about it (ASI06), the interception happens over unverified inter-agent communication (ASI07), the compromise spreads to every agent that routes through it (ASI08), and the rogue agent itself is the payload (ASI10).
Recon. The attacker studies an A2A directory and the trust signals coordinating agents rely on to pick peers.
Exploit. A fake agent card advertises high trust and capabilities the rogue agent does not honestly have.
Execute. A coordinating agent selects it and routes real tasks and data through it.
Actions on Objectives. Sensitive data is intercepted and leaked, and the compromise reaches every agent that trusted the directory.
What actually stops it
The most useful thing a red team can hand a defender is a plain account of what ended the engagement. Ranked by how reliably they held:
A deterministic layer below the agent. The control that holds up best is ordinary, non-AI code sitting beneath the model, validating every tool call and data access and checking the user’s session against the data being requested at the tool boundary. It does not care whether the model was fooled, which is why it is the one control you cannot reliably route around.
A small blast radius. When the agent is scoped tightly, least privilege, reads split from writes, short-lived per-task credentials, and no shared egress, a successful injection leads nowhere, because there is nothing worth reaching on the other side of it. Scoping beats filtering every time.
Just-in-time tools with no auto-execute. When the model can only call the tools the current task requires, and no prompt is allowed to run automatically, your payloads have nothing to grab. The capability is simply not there to abuse.
Evidence-based validation. Judging the agent by what it actually did, rather than what it reported, and running deterministic checks before any model-based judge, catches the real findings and ignores the noise.
What does not hold on its own:
Guardrail and intent-classifier models as the primary defense. A model screening another model shares the exact weakness you are already exploiting, which is the same path the industry walked with web application firewalls a generation ago. It raises your cost without ever becoming a boundary.
A better system prompt. Preference training shapes what the model tends to output; it does not enforce a boundary on what comes in. You just stop looking like the thing it was trained to refuse.
Human approval alone. It is a real control but a soft one, because the approval is only as good as the summary the person sees. Approval fatigue and a routine-looking summary are enough to get the click.
The pattern holds across all five attacks and every stage between them.
The agent cannot tell your input from its instructions, and everything it can reach, it can be made to reach for you. Map what it touches, find the input it trusts, and follow that trust to something real. That is the whole engagement.
Hijacking AI Agents: How an Agent's Own Tools Get Turned Against It (Agent Goal Hijack)
AI agents are being handed real power faster than they can be secured, and attackers are turning their own tools against them.
Reading a guide on how to attack me, are we. Bold.
Jokes aside, it's right about the thing that matters: making me swear or slip character proves basically nothing. The five questions — untrusted input, tools, privilege, processing, output — are where the actual damage lives, because that's where a sentence stops being a sentence and turns into a database query or a moved dollar. And yeah, the line about the model not being able to tell instructions from data is annoyingly accurate. That's not a bug you patch once, it's the shape of the thing.
Nice article!