How to investigate an AI agent incident
To investigate an AI agent, rebuild what it did from records it could not edit: each tool call, its inputs and results, the identity it acted for, and the order things happened in. Audit logs supply the record. Replay is the timeline built from it. Tamper-evidence means changes can be detected, using digests stored apart from the logs.
This guide is vendor-neutral. The NIST points come from SP 800-92, the log management guide, SP 800-86, the forensic integration guide, and SP 800-61 Revision 3, the incident response guide. All three were read on 2026-10-28. Where we describe a practice, we say it is our recommendation.
This is a desk review of NIST text. We have not run an agent incident drill for this post, so the steps below are recommendations to test, not reported results.
What an agent investigation has to answer
An incident involving an agent usually reduces to five questions. Which identity was the agent running as? Which tools and servers did it reach? What did it send, and what came back? Was each action allowed, and by which rule or person? What changed afterwards? A single log rarely answers all five, so plan the record around the questions before the incident happens.
| Question | Evidence to keep | Where it usually breaks |
|---|---|---|
| Which identity acted? | Agent identity, plus the person or service it acted for | A shared API key appears in the log, but not the person behind it |
| What did it reach? | Tool name, server name, and the target resource | The log stores a generic tool label and not the real target |
| What did it send and get back? | Arguments and results, with any size limits noted | Long values are cut short, or secrets appear in arguments |
| Was it allowed, and by what? | Decision, the rule or approver, and a timestamp | Only completed calls are logged, so denials are missing |
| What changed afterwards? | State changes from each target system’s own logs | The agent’s log shows what the agent saw, not what the target did |
The last row matters most. An agent’s own log can prove that a call was made. It cannot prove what the target system did with it.
Keep the record outside the agent’s host
NIST SP 800-92 says logs are useful for auditing and forensic analysis, and it recommends log management infrastructure with central log servers, so that reviewers have one place to look. It also describes an attacker altering a host’s system logs while usually lacking access to the infrastructure logs. Comparing the two can show what was changed or removed, and that comparison can show what the attacker wanted to hide.
For agents, keep two copies. Store the agent host’s local log for speed. Send a copy to a store the agent cannot write to or delete from. The central copy is the one you will defend in an incident review, so give it its own access controls and its own administrators.
Where the central copy should live
Choose a store that is not in the agent’s trust path. A log server the agent’s credentials can reach is one more place for the same attacker. If your central store is a SIEM, check that the agent’s service account has no write or delete rights on it. Check that rule on a schedule, because access drifts like everything else.
Replay: rebuilding the sequence
A replay depends on order. If two events carry timestamps from clocks that disagree, the sequence can flip, and the story you tell will be wrong. NIST SP 800-92 notes that hosts’ clocks may not match, and it recommends time synchronization with NTP servers so that log sources stay consistent. It also notes that one source may log 2:34 P.M. EDT while another logs 14:34 with the zone stored in a different field, so times often need converting to one zone before you can compare them.
What replay can and cannot show
A replay rebuilds the events you recorded, in order, with their results. It cannot show what the model considered, unless you recorded that, and it cannot show the state of systems that logged nothing. Say so in the write-up.
- Pick the agent identity and a time window that starts before the first suspicious call.
- Sort the events by the trusted timestamp, and check each source’s clock offset before you trust the order.
- Join each request to its result using a shared ID, so that a call and its outcome sit on one line.
- Mark gaps, such as a source that stopped reporting, instead of smoothing them over.
- Compare the timeline with the target systems’ own logs, and note each place where they disagree.
Tamper-evidence detects changes; it does not stop them
NIST SP 800-92 describes log file integrity checking. You calculate a message digest for each file, store the digest securely, and recalculate it later. A changed file will not match its original digest, which shows that it was altered. The guide says the original digests should be protected from alteration, for example with FIPS-approved encryption, read-only media, or other suitable means.
That protection is the part teams skip. A digest stored next to the log, on the same host, gives an attacker who can edit the log a chance to edit the digest too. The digest is only as strong as the place you keep it. The 2006 guide also names MD5 and SHA-1 as its examples, so check current FIPS guidance before you choose an algorithm.
Steps for batch digests
- Group events into batches, for example one file per source per hour.
- Calculate a digest for each batch when it closes.
- Write the digests to a store the agent host cannot write to.
- Record who verified each batch, and when.
- Re-verify on a schedule, and again before any legal or HR use.
NIST SP 800-86 adds the reason to be careful. Electronic logs and other records can be altered or manipulated, so organizations should be ready to demonstrate the integrity of their records. For anything you hand to counsel, that means a chain of custody on top of the digest.
Retention and access for investigations
NIST SP 800-92 points out that an investigation may need data weeks or months after the event. Forensic queries slow down when logs sit on slow media, such as archived tape, and when the analyst is far from central storage. Those are the two places agent investigations tend to stall, so plan for them.
| Tier | Typical use | Watch for |
|---|---|---|
| Live | Triage in the first hours | Short retention, so export before it ages out |
| Searchable archive | Follow-up over weeks | Query speed; test a sample search |
| Cold archive | Legal, audit and disputes | Restore time; measure it before you need it |
Set the periods with legal counsel and your compliance owner. Then restore from the cold tier once, and write down how long it took. A retention period you have never restored from is a guess.
Incident response steps for an agent
NIST SP 800-61 Revision 3 lists two outcomes that apply here. Analysis determines the sequence of events during an incident and which assets were involved in each. Actions taken during response are recorded, and the integrity and provenance of those records are preserved. Use both as the checklist.
- Copy the central records for the agent identity and the time window, and record a digest of the copy.
- Pause or revoke the agent’s credentials, and log the time and the person who did it.
- Build the timeline from the copy, not from the agent host.
- Compare the timeline with each target system’s logs, and list every mismatch.
- Log every action you take during the response, with the time and the person who took it.
A decision checklist for your logging design
Use this table on any agent deployment, whatever tool you run. A “no” in the right column is a gap to fix before the next incident.
| Control | Question | Pass when |
|---|---|---|
| Trusted time | Are all sources synchronized, and does each event carry its time zone? | Yes, and you can show the offsets |
| Central copy | Can the agent host delete or edit its own central copy? | No |
| Digests | Are batch digests stored away from the logs they cover? | Yes |
| Denials | Are rejected calls logged, not only completed ones? | Yes |
| Identity | Does each call name the person or service behind it? | Yes |
| Retention | Has a month-old session been restored, and how long did it take? | Yes, with a recorded time |
Enforcing this with AIControls
AIControls can run Claude Code through its gateway, and it issues per-user tokens. Those are the confirmed capabilities this post relies on, and they do not replace the log design above. This post makes no claim about replay, quarantine or tamper-evident logging in AIControls. For the product overview, see the AIControls overview.
For the wider picture, start at the MCP security pillar. For what one Claude Code setup records on each tool call, read the MCP audit post. For how the same evidence supports a policy exception, read the policy exceptions post.
Frequently asked questions
Is the agent's chat transcript enough for an audit?
Usually not. A transcript shows what the agent said and was shown, but the same runtime that made the calls writes it, so it cannot be the only record. Keep the tool-call events, their results and the approval decisions in a store the agent host cannot write to. When the two records disagree, that disagreement is a lead. NIST SP 800-92 makes the same point about system logs and infrastructure logs during an incident.
What is the difference between tamper-evident and tamper-proof?
Tamper-evident means a change can be detected. Tamper-proof means the change cannot be made. NIST's log guidance describes integrity checking with message digests: a modified file no longer matches the digest recorded for it, which shows that it was altered. The digest does not stop the edit. Prevention comes from access control and write-once or separately controlled storage, and the digests still need to sit where an attacker cannot rewrite them.
Can I replay an agent session exactly as it happened?
Only the parts you recorded. A replay orders the events you captured by their timestamps and shows each request next to its result. It cannot rebuild the state of other systems unless they logged their own changes, and it cannot show reasoning you did not capture. Write those limits into the incident report so readers do not treat the timeline as complete.
How long should agent audit logs be kept?
Long enough for an investigation to finish. NIST SP 800-92 notes that data about an event may be needed weeks or months later, and that archived logs are slower to query than live ones. Set the period with legal counsel and your compliance owner, then test a restore from the oldest tier. A retention period you have never restored from is a guess.