The moment an AI incident gets confirmed, there's a narrow window where the exact state of what happened is still recoverable, and it closes fast. Log rotation runs on its own schedule, retention policies purge on theirs, and someone on the response team will want to "just fix it" before anyone has captured what needs capturing. This guide is for the specific task of preserving evidence once an incident is confirmed or strongly suspected: not investigating it, not communicating about it, not remediating it, just making sure the record survives long enough for those other steps to use it. It applies whether the incident is a prompt injection, a data leak, an unauthorized tool call, or something still ambiguous enough that you're not yet sure it's an incident at all.
Snapshot the audit trail before rotation or retention catches up
The first concrete action is pulling a full, timestamped export of everything relevant in the audit trail: the session records, the decision log, the tool-call history, covering a window wider than you think you need. Retention policies and log rotation don't pause for an active investigation unless someone tells them to, and a policy that quietly ages out 30-day-old records doesn't care that day 29 is when the incident happened. Export first, ask questions about scope second. If your logging infrastructure supports a retention hold or a legal hold flag, apply it immediately to the relevant identities and time range rather than relying on the export alone.
Preserve the specific session, not a summary of it
A dashboard summary or an aggregated metric tells you an anomaly happened, but it won't tell an investigator or a lawyer what actually happened. Preserve the specific session transcript, the specific prompt and response pairs, the exact model version and configuration in use at the time, and the exact tool-call parameters and results. If the model provider or a tool changes version between the incident and your investigation, a "similar" request run today won't reproduce the original conditions, so the original state has to be captured as it was, not reconstructed after the fact from partial records.
Maintain a clear chain of custody
Anything that might later support a legal claim, a regulatory response, or even an internal disciplinary action needs a documented chain of custody: who pulled the evidence, when, from what system, and where it's been stored since. This doesn't need to be elaborate, but it does need to be consistent. A single spreadsheet or ticket recording each handoff is enough, as long as it's actually maintained rather than assumed. Evidence that can't show an unbroken custody record is weaker evidence, even if its content is accurate, because its integrity becomes a matter of trust rather than record.
Resist destructive fixes before state is captured
Under pressure, the instinct is to stop the bleeding: roll back a system, wipe an agent's memory, restart a service, revoke a credential. Some of that is genuinely urgent and shouldn't wait. But anything that overwrites or destroys state, clearing an agent's memory store, force-restarting a process that held relevant in-memory context, rotating a key before its usage history is pulled, should wait until someone has confirmed the relevant evidence is captured elsewhere. If a fix and a capture genuinely can't both happen first, capture what you can in the seconds available, even partially, rather than skipping straight to the fix.
Separate evidence preservation from remediation timing
Containing an active threat and preserving evidence are not the same action, and treating them as if they were creates false urgency in one direction and false patience in the other. You can pause a compromised agent, block a malicious identity, or disable a vulnerable tool without touching the evidence that documents what it did. Do the containment that safety genuinely requires, on its own timeline, and do the evidence capture on its own timeline, and don't let either one wait on the other unless there's a real conflict between them.
Store preserved evidence separately, with restricted access
Once captured, preserved evidence shouldn't just sit in the same log store as everything else, subject to the same retention rules and the same broad read access. Move it, or flag it, into a separate, access-restricted location, with a record of who can view it and why. This protects the evidence from accidental deletion by an unrelated cleanup job, and it limits exposure of what may be sensitive incident detail to only the people who genuinely need it for investigation, legal review, or later reporting.
Where TELEON fits
TELEON's audit trail, running through the gateway or supported middleware, gives you a structured, timestamped record of identity, decisions, and tool-call outcomes that's already capturing much of what this guide asks you to preserve, which means the export step is pulling from an existing record rather than trying to reconstruct one after the fact. Its policy enforcement layer can also apply a hold or restrict access to a specific time range or identity once an incident is flagged.
The actual chain-of-custody documentation, the decision about what counts as in scope, and any legal or regulatory judgment about what evidence matters still have to be handled directly by the team responding to the incident. TELEON's record supports that work; it doesn't replace the judgment involved in doing it.
A short checklist
- Export the audit trail immediately, wider than you think you need.
- Apply a retention or legal hold to the relevant time range and identities.
- Preserve the specific session, prompt, model version, and tool-call state, not a summary.
- Document chain of custody from the moment evidence is pulled.
- Hold off on destructive fixes until state is captured, or capture what you can first.
- Contain the threat on its own timeline, separate from evidence capture.
- Store preserved evidence in a restricted, access-controlled location.
The easiest mistake here isn't skipping evidence preservation entirely, it's assuming there's more time than there actually is. Retention jobs, credential rotations, and eager remediation all run on their own clocks, and none of them wait for an investigation to catch up. Building the habit of capturing first, even imperfectly, before anything else touches the system, is what makes the rest of the incident response process actually possible later.