Prompt injection has become the most common way an AI agent gets turned against the organization running it — the leading vector behind ASI01 Agent Goal Hijack in the OWASP Top 10 for Agentic Applications. When it happens, the urgent question is not whether the model was “jailbroken” — it is forensic: once the agent absorbed a hostile instruction, what did it actually do, and can you prove it? This is a playbook for answering that, working from the logs you already have.
What counts as a prompt-injection incident
A prompt-injection incident is one where hostile instructions, smuggled into content an agent reads, cause it to act against its operator’s intent. The payload can arrive directly — an attacker typing instructions into a chat the agent processes — but the dangerous, common case is indirect injection: the malicious text is planted in data the agent later ingests on its own, such as a document, a web page, an email body, a support ticket, or the response from an upstream tool.
It is an incident, not a bug, for one reason that shapes the whole investigation: the agent acted through its own legitimate credentials. Nothing trips an “unauthorized access” alarm, because from every downstream system’s point of view the access was authorized. The data it read, the actions it took, and anything it sent out are real — they just wear the agent’s valid identity.
Why prompt-injection incidents are hard to investigate
Three things make these cases harder than an ordinary account compromise:
- The instruction isn’t in your code. It lives in data the agent read — often external or ephemeral — so the usual instinct to audit configuration and source turns up nothing. The evidence is in the agent’s inputs.
- Legitimate identity hides the activity. The agent used real keys and tokens, so its actions blend into normal traffic. Telling malicious from routine is a matter of reconstruction and sequencing, not a permission error you can grep for.
- The agent is a subject, not a witness. Its own reasoning trace and output cannot be trusted as the record of what happened — manipulating exactly that was the attack, and a model under pressure will also confabulate. The account has to be built from independent logs.
The investigation, step by step
The shape mirrors classic DFIR, adapted for an actor that reasons and acts on its own. In practice it runs in this order:
1. Scope and preserve
Identify the agent and every identity it operated through, and fix the time window. Preserve the relevant logs immediately and with integrity — content-addressed hashing and a tamper-evident record — before they roll off or the agent runs again and muddies the trail.
2. Reconstruct what the agent read
Because the payload lives in inputs, the first real forensic move is to recover the exact content the agent ingested during the window: retrieved documents, tool and API responses, web fetches, memory reads. Whatever redirected it is somewhere in that material — so you have to reassemble what the agent saw, not just what it did.
3. Locate the injection — patient zero
Within that ingested content, find the hostile instruction and the vector it arrived through: a poisoned document, a scraped web page, an email, a record returned by a compromised upstream service. This is root cause. Skip it and you are cleaning up symptoms while the same channel stays open for the next run.
4. Reconstruct what it called, changed, and decided
Build the action timeline forward from the injection: the tools the agent invoked, what it wrote or modified, where it moved data — and the decision path behind each step, separating what the agent was legitimately tasked to do from what the injected instruction steered. The split between pre-injection and post-injection behavior is usually the spine of the whole account.
5. Resolve identity and authority
A single agent acts through an API key, a service principal, a role, an OAuth token. Stitch those non-human identities (NHIs) back into one actor so the activity reads as a single story, and establish which permissions made the damage possible — prompt injection turns dangerous in direct proportion to the agency the agent was granted.
6. Establish the blast radius
Determine what data was read and moved, which systems were touched, what was exfiltrated and to where, and what persists after the fact — a planted memory entry, a created credential, a scheduled task. This is the part counsel, regulators, and a customer’s security team will actually ask about.
7. Rate confidence, then report
A defensible account never overstates the evidence. Each finding should carry its confidence and be labeled as attested by the logs or inferred from them, with genuine ambiguity stated plainly. The result has to be reproducible and backed by an intact chain of custody — an account an examiner can defend line by line.
What to collect
A prompt-injection investigation is only as strong as the sources it fuses. The ones that matter most, and what each tells you:
| Source | What it tells you |
|---|---|
| Model-provider request logs | The prompts and completions — what the agent was told, and how it responded |
| Retrieval / RAG / vector-store logs | The documents the agent pulled — where indirect injection usually hides |
| Tool / function-call logs | Which tools it invoked, and with what arguments |
| Cloud audit logs (CloudTrail, etc.) | Actions taken through the agent’s cloud identity |
| Identity-provider events | Token issuance and use across the agent’s identities |
| Application & data-access logs | What data it read, wrote, or moved out |
No single source tells the story; it emerges only once they are normalized and fused onto a common timeline. More sources mean a higher-confidence reconstruction, but the method degrades gracefully when only a few are available.
Common mistakes
- Trusting the agent’s own account. Treating the model’s reasoning or output as the record of events — when manipulating exactly that was the attack.
- Hunting in the wrong place. Auditing code and configuration for the payload instead of the data the agent read.
- Stopping at the jailbreak. Confirming the model was redirected but never tracing the resulting actions and blast radius — the part that actually has consequences.
- Equating authorized with benign. Assuming activity was harmless because the credentials behind it were valid.
- Investigating live. Letting the agent keep running, or waiting until logs roll off, before anything is preserved.
Where Agent Autopsy fits
Agent Autopsy runs this playbook as a product. Pointed at the logs you already have, it reconstructs what a prompt-injected agent read, called, changed, and decided; resolves its identities into a single actor; traces the chain back to the injected input that started it; and produces a confidence-rated account backed by a tamper-evident chain of custody — agentless and vendor-neutral. It is one application of the broader discipline of AI agent forensics. See how it works end to end, how it is validated against a known-truth benchmark, or where it fits in the wider AI-agent incident-response process.
Frequently asked questions
Can you investigate a prompt-injection incident without agent-specific logging in place?
Yes — that is the normal case. A dead-box approach works from the ordinary logs you already have (model-provider, retrieval, cloud, identity, application), so the investigation does not depend on a sensor you would have needed to install before the incident.
The injection came from a document or web page — how do you find it?
You recover the content the agent actually ingested during the window, from retrieval and tool-call logs, and locate the hostile instruction inside what it read. The injection is rarely in your own systems; it is in the material the agent pulled in.
The agent used valid credentials — how do you separate malicious activity from normal?
By reconstructing the timeline and decision path and splitting pre-injection from post-injection behavior. A legitimate identity does not make an action authorized in intent — the sequence and the originating instruction are what distinguish the incident from routine work.
Why not just read the model’s logs?
Model logs are one source, and a manipulated one. A forensic account fuses them with cloud, identity, and application evidence, rates each finding’s confidence, and produces something that holds up for security, legal, and leadership — not a single stream the attack may have shaped.