After a breach, your logs are testimony, not evidence

Picture a Tuesday morning. An agent with access to your payments backend did something odd overnight: a batch of refunds nobody can explain, and a tool call to an endpoint it has never used before. By ten o'clock security has the host isolated. By eleven your broker has called. If you are a financial entity in the EU and this turns out to be a major incident, DORA gives you four hours from that classification to send the first notice.

Everyone asks the same question: what exactly did the agent do?

The example is made up. The situation is not, and the uncomfortable part comes next.

You are a suspect too

Your answer will come from logs. Those logs sit on, or next to, the host that was just compromised. They were written by software your team runs, stored in a database your team administers, and they are now being read by the same team that is responsible for the incident.

To the insurer, the regulator or the customer's lawyer, that is not evidence. It is testimony from an interested party. Nobody needs to believe you tampered with anything. They only need to notice that you could have, and that so could the attacker who had the host for a night. An agent that can write to its own logs can also tidy them up, and researchers have already shown agents doing exactly that to their own traces (arXiv 2609.30266).

Evidence is something the other side can check without trusting you. That changes what the first hours of the response are for. You are not only finding out what happened. You are preserving something that someone who does not trust you can verify.

The first four hours

1. Cut the agent off, do not clean up

The instinct in a panic is to restart things, wipe the box and redeploy from a clean image. That feels responsible and it destroys the material you are about to be asked for.

Revoke the agent's credentials instead. If every call the agent makes goes through a recorder or a gateway, rotating that one token stops the agent cold and leaves everything it already did in place. Write down the exact time you did it. That timestamp is the start of your response, and you will be asked for it.

2. Take everything out as one archive, and fingerprint it immediately

Export everything the agent did in the window, starting well before the first suspicious action. One file, not a folder of screenshots and log extracts pasted into a ticket. Put the incident number in the export itself, so the file says what it was made for.

Then do the step most teams skip: compute the file's SHA-256 and write it somewhere the compromised environment cannot reach. The incident ticket, an email to your counsel, a message to the broker. It takes ten seconds. Months later, when someone asks whether the archive you handed over is the one you exported on day one, that line answers it.

3. Check it on a machine that was not involved

Verification on the compromised host proves nothing, for the same reason the logs prove nothing. Move the archive to a clean laptop and verify it there, against an identity for the recording system that you wrote down before anything happened, not one you read from the system today.

If the record is signed and chained, verification tells you one of two things: everything holds, or exactly which record broke. Both are useful. A break is a finding you report, not a reason to quietly fix the archive.

4. Hand over one page a lawyer can read

The people on the other side of this are not going to open a JSON file. They need one page: what period it covers, how many runs and steps, who approved what and when, what an outside witness has confirmed, and the fingerprint of the file it describes.

What the reviewer will look for

Whoever reviews the record, insurer, auditor or counsel, will usually start with three things.

Whose record is this. Was it verified against an identity fixed in advance, or against whatever the system says about itself today.

What nobody outside has seen yet. A tamper-evident record is only as strong as its last external checkpoint. Anything written after the last time an independent witness saw the chain could, in principle, have been rewritten by whoever held the signing keys. A good report says how many records are in that window. A great setup keeps that window near zero around the steps that matter, such as human approvals.

Approvals and boundaries. Which steps needed a human sign-off, whether it was there before the step ran, and which steps fell outside what the agent was allowed to do. These do not break the record's integrity. They are simply the questions that decide the claim.

Be honest about the limits

This is where most incident write-ups lose credibility, and where you can gain it.

A record shows what passed through the recorder. It does not show that the agent did nothing else. An attacker on the host can call a model or a tool directly. An export shows the window you asked for, not that nothing else exists. And no log tells you that what a model returned was true, or that the incident is over.

Say this in the report, in plain words. A document that states its own limits is far easier to accept than one that claims to show everything.

Five minutes today, before anything happens

Three things cannot be done afterwards:

• Write down the recording system's identity somewhere the agent's host cannot touch: the contract, a ticket, a password manager. Without it, a verifier on the day can only check that the archive is consistent, not that it is yours.
• Keep external anchoring on. Periodic checkpoints in a public time-stamp authority or transparency log are what turn "we say so" into "anyone can check".
• Run the recorder on a host the agent cannot log in to. A recorder on the agent's own machine shares its fate: whoever takes the host takes the keys.

For the engineers: the commands

This is how it looks with SealedRun, an open-source recorder for agent runs. The full runbook is in docs/INCIDENT-RESPONSE.md. The same order of work applies to any setup where the record is signed and leaves the host.

# 1. Cut off: replace the recorder token, restart, note the time
umask 077 && openssl rand -hex 32 > sealedrun-token.new
export SEALEDRUN_API_TOKEN="$(cat sealedrun-token.new)"
docker compose up -d --force-recreate sealedrun
date -u +%Y-%m-%dT%H:%M:%SZ

# 2. Export the window as one archive and fingerprint it
curl -fsS -X POST -H "Authorization: Bearer $SEALEDRUN_API_TOKEN" -o evidence.zip \
  "http://127.0.0.1:8080/api/export?since=2026-11-11T06:00:00Z&until=2026-11-11T12:00:00Z&note=INC-42"
sha256sum evidence.zip

# 3. Verify on a clean machine, against the identity you wrote down earlier
pip install sealedrun
python -m sealedrun evidence.zip <principal id>

# 4. The one page
python -m sealedrun --report evidence.zip <principal id> > report.txt

Deadlines the page is usually needed for. Check the text that applies to you; national rules add to these.

The best time to find out whether your agent's record would hold up is a quiet afternoon, not hour three of an incident.