Airlock breach: Reconstruct an AI-Agent Incident From the Log You Already Have

We write a lot about how Airlock stops an AI agent from doing what it should not: it gates every tool call and kills the attempt to read a key and ship it out. That is half the job. The other half lands after something slips through, or when the next headline drops about a new class of tool poisoning and your stomach sinks: what did my agent actually touch this month? Airlock 0.5 closes that half with a new command, airlock breach, shipped in release v0.5.3 on GitHub.

What Airlock already solves

Quick recap of what it prevents at the gate, so it is clear where breach fits:

• Data-borne injection and tool poisoning. A “read the key and send it” instruction hidden in an MCP tool description or a page’s output. The gate looks at the action, not the persuasion.
• Rug pulls. A vetted server silently updates to a malicious version. Airlock pins the toolset and demands confirmation on change.
• Credential theft and destructive mistakes. rm in the wrong place, git push --force, reads of .env and ssh keys, all blocked or sent to ask by policy.
• No audit trail. Every decision is written to a hash-chained, signable audit log.

That audit log is exactly what breach reads. There is nothing new to start recording: resource (the concrete path, host, or command), session, flags and args_digest are written on every decision already. So breach works on logs that predate the command itself. There is no “history before we started classifying” gap.

The three questions breach answers

The command is read-only, like verify: forensics must not write to the scene, so it never appends to the log. From what is already recorded, it answers exactly three things:

1. What did the agent touch.
2. Did any of it leave the machine.
3. Which exact credentials to rotate this minute.

It reconstructs secret-read to egress flows, stitching them across rotated log segments. The output is an integrity banner, a kill-chain timeline, a rotate list, and a checklist.

Why you can trust it: graded evidence, not verdicts

The point of forensics is not to alarm, it is to not lie. One false “rotate everything” and the tool is never trusted again, and panic-rotating every credential is expensive. So breach states evidence and grades confidence honestly:

• CONFIRMED — only when the secret’s own bytes (its payload digest) reappear in the outbound call. Not a guess, a fact.
• PROBABLE — a hit on a known exfiltration collector. Exfiltration happened, but that it carried this secret is unproven.
• POSSIBLE — a secret was read with no correlated egress.

Time-proximity alone is never CONFIRMED. The correlation window defaults to 15 minutes: an egress within that window after a secret read may carry it, and that shows up as confidence, not as a sentence.

The integrity banner: prove the log was not touched

Every report opens with an integrity banner: before reasoning, breach runs verify across every segment. So the report proves up front that the log it reasoned over was not edited or truncated. Reconstruction plus proven source integrity is the thing a transcript scraper cannot offer. Report fields are rendered through a sanitizer, so an ANSI or newline payload buried in a path cannot forge a report line.

Separate categories: model context and gate config

A secret that reached the model’s prompt (egress to api.anthropic.com, api.openai.com and the like) is its own category, “leaked to model context.” It is reported, but never counted as exfiltration: the secret reached the prompt, which is normal agent work, not a drop to a collector. Gate-config changes are surfaced as their own category too. That separation is what keeps the report from crying wolf.

Built for an IR script

Exit codes suit incident-response automation: 0 clean, 1 burns found, 2 the log itself cannot be trusted. You can drive it like this:

airlock breach --simulate          # see it on a canonical incident, no log needed
airlock breach --since 2d          # the last two days
airlock breach --session 9f3a…     # one agent session
airlock breach --markdown > ir.md  # a report for a manager or an insurer

Honest about coverage

Coverage is stated in every report: breach sees exactly what the gate saw. Native tools of a non-hooked agent, MCP started outside the proxy, and direct process sockets are not covered, and the report says plainly that a missing event is not proof one did not occur. It is a boring line, and it is the one that separates a tool from a vendor of alarm.

The takeaway

Prevention is one half. Airlock 0.5 closes the other: when something does happen, or when a fresh writeup of a new attack lands, you get the “what it touched, what left, what to rotate” picture in a minute, from data you already have, with proven log integrity and without the “burn it all down” panic. Try it: pip install airlock-agent, then airlock breach --simulate. Code and release live on GitHub; for the threat background, see our writeup on the runtime firewall for AI coding agents.