What a prompt injection incident actually looks like from the inside
The question that starts most of these conversations is not “were we attacked”. It is “can you tell us what it did”. A support assistant summarized a document, a record moved, a customer saw something they should not have — and the team discovers that the system produced a fluent, plausible answer at every step, wrote almost none of it down, and cannot now be asked what happened.
Published 22 September 2026. Written by the SecHB practice, Greater Vancouver, British Columbia.
The short version
The injection usually does not come from the user. It arrives inside content the system was asked to read — a document, a web page, an email, the response from a tool — and it reaches the model with the same standing as your own instructions, because to the model it is all text in one context.
This is LLM01:2025 Prompt Injection in the OWASP Top 10 for LLM Applications 2025. What makes it an incident rather than a curiosity is what the system was allowed to do next, which the same list treats as LLM06:2025 Excessive Agency, and what it was allowed to reveal, LLM02:2025 Sensitive Information Disclosure. Injection is the entry; agency and disclosure are the consequence.
How indirect injection arrives
The pattern is ordinary. Someone uploads a contract to be summarized, and somewhere in it — in white text, in a footnote, in a table cell, in document metadata — sits a line addressed to the machine rather than the reader. A crawler indexes a supplier page that carries the same thing. An assistant with a mailbox connector reads a message whose body is written for it. A tool the agent calls returns a field the developer assumed was data and the model reads as instruction.
None of those requires the attacker to touch your interface, hold an account, or know anything about your stack beyond the fact that a model will eventually read what they wrote. The attacker writes once and waits for your system to fetch it. That is what separates the indirect form from the demonstrations people are used to seeing typed into a chat box, and it is why access control on the chat interface does nothing about it.
Why it looks like normal operation
Consider the shape of the thing, described generically — this is an illustration of a class of failure, not an account of any engagement. A retrieval step returns three documents, one of which carries an instruction. The model, now holding that instruction, calls a tool it is entitled to call, with arguments that are individually valid. The tool returns success. The model composes a reply and the reply is returned.
Every component behaved correctly. The application log shows a request and a two-hundred response. The tool log shows an authorized call from a service that is allowed to make it. The model provider’s dashboard shows token usage in the normal range. There is no error, no exception, no failed authentication, and nothing that any alert was written to catch — because the system was not subverted in the technical sense. It was persuaded, and persuasion leaves no stack trace.
This is the honest, uncomfortable centre of the problem, and it is worth stating plainly: an AI incident cannot be reconstructed after the fact unless the telemetry to reconstruct it was designed in beforehand. There is no forensic technique that recovers a model’s reasoning from infrastructure logs. If the prompt, the retrievals and the tool arguments were not recorded at the time, they are gone, and no amount of investigative effort brings them back.
The first signals a team actually notices
Usually from the consequence rather than the cause: a record changed that nobody meant to change, a customer receiving content about another customer, a support reply quoting an internal document. The prompt-injection step itself looks like a normal, successful request in almost every log a team keeps.
- A downstream record changed — a ticket reassigned, a refund issued, a calendar cleared — that no human can account for.
- Content in an output that the recipient should not have been able to see, often noticed by the recipient rather than by you.
- An assistant answering off-pattern for one class of input: the same document type, the same supplier, the same inbox.
- A tool call rate that changed shape without a release to explain it.
- An inbound support contact from someone describing content your assistant sent them and they did not expect.
Note what these have in common. Every one of them is a consequence observed somewhere else, days later, by someone who was not looking for a security event. That lag is the thing to design against.
What you will wish you had logged
The prompt as sent to the model, the documents or tool responses retrieved and their sources, every tool call with its arguments and result, the output returned, and the identity each step ran under — correlated by a session identifier so the sequence can be replayed as one trajectory. Six things, and the reason each one matters when somebody asks the question you cannot currently answer:
| What to capture | Specifically | Why it decides the answer |
|---|---|---|
| The prompt as sent | The assembled prompt, not the user’s typed text. | The injected instruction lives in the retrieved or tool-supplied portion. Logging only the user turn hides the entire cause. |
| Retrievals and their sources | Which documents or pages were pulled in, with identifiers and versions. | Tells you which artifact carried the instruction, and therefore what else it reached. |
| Tool calls | Each call, its arguments, its result, and whether it succeeded. | This is where consequence happens. Arguments matter more than the call name. |
| The output returned | What the user or downstream system actually received. | Establishes exposure. Without it you are guessing at what left the boundary. |
| Identity per step | Which principal each retrieval and each tool call ran under. | Separates “the assistant could reach this” from “this user could reach this”, which is the question that decides severity. |
| A session identifier | One key correlating every row above. | Without it the rows exist but the sequence does not, and the sequence is the evidence. |
Two cautions come with this. The first is that these records contain whatever your users and documents contain, so the store holding them inherits the sensitivity of everything the assistant ever touched, and needs retention limits and access control accordingly. The second is that logging all of it and never reading it is a cost without a control. Someone has to be able to pull a session and read it.
Reconstructing the session
With that telemetry, the work is methodical. Pull the trajectory for the affected session and read it in order: what came in, what was retrieved, what the model was asked, what it called, what came back, what went out. Identify the artifact carrying the instruction. Then pivot — that artifact was almost certainly retrieved by other sessions, and the scope question is which ones.
From there the boundary is drawn by identity. For each tool call, establish whether it ran as the user or as a service principal with broader reach, because that determines whether the event stayed inside what the user could already do or crossed into what they could not. That single distinction usually decides the severity of the whole incident.
What the trajectory will not tell you is why the model complied. There is no log line for that, and a reconstruction that claims to explain the model’s reasoning is telling you a story. What it does tell you — reliably, and sufficiently — is what the system read, what it did, under whose authority, and what left the boundary. That is what a response is built on.
Containment, and who is allowed to decide
Containment for these systems is unusually blunt: disable the tool, revoke the credential, quarantine the document or the source, or take the assistant down. Each of those is a business decision with a customer-visible cost, which is why the useful preparation is not technical at all. Decide now, in writing, who is permitted to turn the assistant off at three in the morning without convening anyone, and make sure the mechanism to do it exists and has been tried. A kill switch nobody has authority to pull, or that has never been exercised, is not a control.
The moment a finding bears on notification, contractual obligation or regulatory exposure. Establishing what the system did is engineering; deciding what that obliges the organization to do is counsel’s. They reduce it; they do not close it. A guardrail is a classifier reading text, and the instruction it is meant to catch can be rephrased, split across documents, encoded, or placed in a language or format the classifier handles poorly. Treat input filtering as a mitigation that lowers volume, and put the boundary somewhere an attacker cannot talk their way past — in what the tools are permitted to do, and under whose identity.
How to be ready before it happens
Almost everything that makes one of these tractable is cheap and has to exist in advance: the trajectory logging above; a named owner for each assistant; per-tool credentials scoped so that a compromised step cannot reach past its job; a written and exercised path to disable a tool or a model; and a tabletop run with the people who would actually be in the room. The OWASP Agentic AI – Threats and Mitigations guide, published on 17 February 2025 by the project’s Agentic Security Initiative, is the reference to read alongside this if the system in question calls tools or acts on its own initiative.
A technical investigation of the system and its telemetry is engineering work, and SecHB does that alongside the client. Where the law requires it, investigation or forensics is delivered with appropriately licensed partners, and decisions about notification and legal exposure rest with the client’s counsel, not with the people reading the logs.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Can guardrails stop this?
They reduce it; they do not close it. A guardrail is a classifier reading text, and the instruction it is meant to catch can be rephrased, split across documents, encoded, or placed in a language or format the classifier handles poorly. Treat input filtering as a mitigation that lowers volume, and put the boundary somewhere an attacker cannot talk their way past — in what the tools are permitted to do, and under whose identity.
How would we know it happened at all?
Usually from the consequence rather than the cause: a record changed that nobody meant to change, a customer receiving content about another customer, a support reply quoting an internal document. The prompt-injection step itself looks like a normal, successful request in almost every log a team keeps.
Who investigates an incident like this?
A technical investigation of the system and its telemetry is engineering work, and SecHB does that alongside the client. Where the law requires it, investigation or forensics is delivered with appropriately licensed partners, and decisions about notification and legal exposure rest with the client’s counsel, not with the people reading the logs.
What should we be logging before it happens?
The prompt as sent to the model, the documents or tool responses retrieved and their sources, every tool call with its arguments and result, the output returned, and the identity each step ran under — correlated by a session identifier so the sequence can be replayed as one trajectory.
Where does the technical work stop and counsel begin?
The moment a finding bears on notification, contractual obligation or regulatory exposure. Establishing what the system did is engineering; deciding what that obliges the organization to do is counsel’s.
Where to go from here
If nothing is in place yet, AI incident readiness is the engagement that puts the telemetry, the ownership and the containment path there before you need them, and AI security monitoring is what turns those records into something that raises its hand. If the system calls tools or acts autonomously, agentic AI security covers the permission and identity design that decides how far an injection gets. The architectural side — where the broker sits, how credentials are held, what egress is allowed — is a secure AI environment, and the specific case of retrieval returning documents the user cannot see is RAG tenant isolation. Other pieces are indexed under Writing.
Describe the assistant, what it can read and what it can call, and the reply will say what you would be able to reconstruct today.