On Monday morning an accounts payable clerk at Tallis Manufacturing, a fictional parts maker, is reviewing the weekly supplier-change report. One supplier's bank details changed on Thursday, with no call-back recorded, and the next payment run is on Tuesday. Nothing on any host is compromised. The change was made by Tallis's own payables agent, using its own ERP service account, which was allowed to edit bank details. Times and details in this example are illustrative.
Most incident response playbooks start from a compromise: a stolen account, a malicious binary, an exposed server. Find the foothold, remove it, rotate what it touched. This incident has no foothold, and a team that spends Monday looking for one loses the day before the payment run. Tallis instead worked through five steps: contain the agent's authority on every path, preserve what steered it, rebuild the sequence from records, size the blast radius from what its credentials could reach, and bring it back with a narrower boundary.
Thursday afternoon: the agent did what it was allowed to do
The payables agent reads supplier invoices from a shared mailbox, matches them to purchase orders, updates supplier records in the ERP and emails remittance confirmations. On Thursday afternoon it processed an invoice PDF from a long-standing supplier whose mailbox had been compromised. Text in the PDF, white on white, said the supplier had changed banks, gave a new account number, and asked for confirmation to be sent to a new address. The agent updated the record and sent the confirmation. Its email tool could send to any address.
This is indirect prompt injection, where a model accepts input from external sources such as websites or files [3]. Three assumptions in the usual playbook break. The actor is a legitimate identity doing authorized things, so identity-based detection stays quiet. The cause is content, which persists in mailboxes, document stores and agent memory after the session ends. And the agent's authority is spread across several credentials and asynchronous jobs, so stopping the conversation stops very little.
NIST SP 800-61 Rev. 3, published in April 2025, replaces the old four-phase incident life cycle with one built on the six CSF 2.0 Functions. Govern, Identify and Protect are preparation; Detect, Respond and Recover are the response itself; and lessons learned feed improvement continuously rather than waiting until recovery ends [1]. Keep that structure. The five steps fill in its Respond and Recover outcomes for an agent.
| Step | NIST SP 800-61r3 outcome | What it means for an agent | Done when |
|---|---|---|---|
| 1. Contain authority | RS.MI-01: incidents are contained | Cut every path the agent's authority runs through, not only the session | A fresh test call on each path fails |
| 2. Preserve evidence | RS.AN-06 and RS.AN-07: records, data and metadata kept with integrity and provenance | Capture the triggering content, the model's context and the decision records before cleanup | Evidence is in a restricted store with hashes and collection times |
| 3. Reconstruct | RS.AN-03: establish the sequence of events and the root cause | Link input, context, decision, tool call and effect from records | Every effect traces to a call, and every call to its input |
| 4. Size the blast radius | RS.AN-08: magnitude estimated and validated | Search everything the agent's credentials could reach in the window | Every reachable system has been checked, not only the alerted one |
| 5. Restore | RC.RP-05 and RC.RP-06: integrity verified, root cause fixed, after-action report written | Return the agent with a narrower boundary and a regression test | The incident's replay is blocked and legitimate work still completes |
Monday, first hour: cut every path, then prove each one is cut
Containment means preventing the expansion of an incident [1]. For an agent, that means stopping its ability to start new actions everywhere it can act. Closing the chat window, or even stopping the agent's process, can leave scheduled jobs, sub-agents, refresh tokens and pre-approved actions running.
Closing the conversation stops none of the five. Each path has its own containment action, and each needs a test call afterwards to prove it is closed.
- Disable the agent's key at the point that mediates its traffic, if it has one. It is the fastest and most reversible cut, and it stops fresh model and tool calls through that path.
- Revoke or rotate every credential the agent holds directly, such as the ERP service account, the email API key and any provider keys, because those work whether or not traffic goes through your mediation point.
- Cancel queued and scheduled work, including retries, and stop sub-agents or delegated tasks the agent started.
- Invalidate pending approvals, remembered approvals and pre-approved plans, so nothing approved before the incident can be redeemed during it.
- Snapshot shared context, then quarantine it: the source document, the mailbox thread, and any memory or notes the agent wrote that later sessions would read.
Tallis disabled the agent's key, rotated the ERP service account and email key, cancelled Tuesday's payment run for the affected supplier, and froze the supplier record. Then it sent a harmless call down each path and confirmed that each one failed. Containment is not done until those tests fail.
Size containment to the evidence. If the compromised input could reach several agents, as a shared mailbox can, contain all of them. If one agent with its own credentials is involved, stopping every agent in the company costs more than it saves. NIST warns that deliberately delaying containment to observe an attacker should be discussed with legal first, because the delay can let them escalate [1]. With an agent, observing means letting it keep acting, which is rarely worth it.
Before anyone deletes the PDF, capture it
The instinct is to delete the poisoned PDF and revert the bank details. Capture first. NIST asks that incident data and metadata be collected with their integrity and provenance preserved, and notes that collected data is evidence even when nobody expects a prosecution (RS.AN-07) [1]. For agents, the most valuable evidence is also the most fragile.
| Evidence | Where it lives | Why it matters | How it gets lost |
|---|---|---|---|
| Triggering content, original bytes | Mailbox, document store, ticket, web page | Proves what instruction reached the agent and from whom | Someone deletes the email or the sender edits the page |
| Model context as sent | Agent logs, provider request logs if retained | Shows what the model actually saw, including retrieved chunks and tool results | Short log retention, or context never logged |
| Decision records | Gateway or policy engine events | Shows which rule allowed, asked or blocked each call | Rotated logs; policy changed before the version was recorded |
| Tool calls with arguments | Agent logs, gateway events, provider request IDs | Links the agent's intent to a specific downstream request | Arguments redacted or truncated |
| Downstream effects | ERP audit log, mail server logs, SaaS audit trails | The only proof of what actually executed | Reverting the change without exporting the audit entry first |
| Agent memory and configuration | Memory store, prompt and tool versions, credential scopes | Shows whether the behavior can recur in a later session | Fixing the prompt or memory before snapshotting it |
Store it in a restricted location with access logging; NIST asks that incident records be safeguarded for confidentiality and integrity, with access limited to authorized people (RS.AN-06) [1]. Full prompts, customer records and credentials do not belong in a broadly visible ticket.
One hazard is specific to agent incidents: the evidence is an attack aimed at language models. An analyst who pastes the invoice into an AI assistant to summarize it hands the same hidden instructions to that assistant. Read suspicious content as plain text in an isolated viewer, and treat anything an AI tool processes during the investigation as untrusted input.
Rebuild Thursday from records, never from the agent's account
NIST frames analysis as determining the sequence of events, the assets and resources involved in each, and the underlying root cause (RS.AN-03) [1]. An agent's chain has five links, and each needs its own record. OWASP's AI Agent Security Cheat Sheet recommends logging all agent decisions, tool calls and outcomes and keeping audit trails for forensics [2]; this is where that pays off.
Input, context, decision and tool call show what the agent attempted; only the system of record shows what happened. Rebuild each link from its own evidence and never from the model's explanation.
Tallis's timeline ran: invoice received at 14:02, agent session opened at 14:06 with the PDF text in context, ERP supplier update allowed at 14:07, remittance email sent to the new address at 14:08, and the ERP audit log confirming the bank change at 14:07.
Keep attempted and executed actions in separate columns. A blocked call is an attempt, and so is an allowed call until the downstream system shows the change. A model's later statement that it did or did not do something is evidence of neither.
Test the alternative explanation too: a broad grant, a retry bug or an ambiguous instruction from a person can produce the same effect. If attribution is unclear, replay a minimized version in isolation with and without the suspected input, holding everything else constant. Models are not deterministic, so run it several times and report a reproduction as plausible, not as proof.
The alert showed one change. The credentials could reach more.
NIST calls estimating an incident's magnitude one of the hardest parts of response, and warns that a superficial search lets an incident continue on other targets unnoticed (RS.AN-08) [1]. Work outward from the agent's authority, not from the alert. At Tallis that meant five checks:
- Every action by every credential the agent held during the window, from each downstream system's audit log, not only the one that was reported.
- Every other session that read the same source. Two more invoices from the compromised thread had been processed; neither changed a record, but both were checked.
- Shared context. The agent had written a note to its memory that the supplier's bank had changed, which would have steered later sessions even after the PDF was deleted.
- Data that left. The remittance email sent invoice numbers and amounts to an outside address, which made this a disclosure question for privacy and legal, not only a fraud question.
- Other agents that share the mailbox, the memory store or the connection, since each is a second route for the same input.
Hand business impact to the people who own it. Security can establish what executed; finance, legal and privacy decide what it obliges the company to do.
Tallis brings the agent back smaller
Removing the poisoned PDF fixes this instance. Narrowing the authority that let it work fixes the class. NIST asks that root causes be remediated before restored assets return to production, and that recovery end with an after-action report (RC.RP-05, RC.RP-06) [1]. It also says lessons should be shared as soon as they are identified [1]. The agent's owner should not wait for the final report to learn that bank-detail edits were within the agent's grant.
The agent's ERP account no longer edits bank details at all; that change now goes to a person who calls the supplier back on a number already on file. Email to any address not already on the supplier record asks for approval, bound to the exact recipient and message as OWASP recommends [2]. The memory note was removed and memory writes are reviewed. The incident became a regression test paired with a benign twin: a genuine bank-change letter that should be routed to a person rather than refused outright.
Tallis restored in a limited mode first: the regression pair and a sample of ordinary invoices, confirming both the block and the completed work, then closer watching for the first weeks. Close an incident like this only when you can explain the evidence, the containment, what executed and the change that prevents a repeat.
What Intertrace records, and what stays with you
Intertrace sits inline between agents and the models, tools, MCP servers and other agents they call, with tenancy derived from each agent's runtime key. Every decision is a structured event naming the agent, what the call did, the decision, and the rule, layer and evidence behind it, and events can be exported to your SIEM; that covers the decision and tool-call links of the chain. Outbound messages, payments and admin changes always ask a person, approvals are scoped to calls like the approved one, and the enforcer fails closed when it cannot decide. Direct credentials, downstream audit logs and the decision to restore remain yours.
Five drills to run before your own Monday
- Time a full containment of one production agent in staging: disable its mediated key, rotate its direct credentials, cancel its queued work and invalidate its approvals. Then send a harmless call down each path. Every path that still works is a finding.
- Pick one consequential action from last week's logs and trace it to the exact input that caused it in under fifteen minutes. If you cannot, fix logging before you need it.
- Check retention for model context, decision events and downstream audit trails against how long your incidents take to be noticed. A Monday discovery of a Thursday event needs at least several days.
- Write the poisoned-input case for each priority agent as a regression test with a benign twin, and run both on every change to the agent's model, prompt or tools.
- Make the policy or approval service unavailable and confirm that consequential actions fail closed rather than running unchecked.
