Forensics: what ran, what it saw, what it did

Lesson 4 of 5 in Monitoring and Incident Response: When the Agent Is the Incident.

The agent is contained and the evidence is frozen. Now you answer three questions, in this order, and you answer them from recorded evidence rather than from reasoning about what the system "should" do.

Which version tuple ran? What did the model actually see? What actions executed, with what parameters? Everything else — root cause, blast radius, customer notification, the fix — is downstream of those three answers. Teams that cannot answer them write postmortems full of the phrase we believe.

The forensic questions and what each one requires you to have captured in advance
Forensic question	Where the answer lives	Captured in advance	If you skip it
1 · Which version tuple ran?	Run metadata and root-span attributes: prompt version, model id and snapshot, tool-schema versions, retrieval index version, guardrail/policy version, harness build, memory snapshot id	Resolved values stamped on every run — not the template name, the resolved value; not "latest", the pinned id	You fix a prompt that was not running, deploy it, and watch the incident recur. The most common wasted day in agent operations.
2 · What did the model see?	Full context reconstruction from the trace: system prompt as rendered, tool definitions as sent, every message, every tool output after truncation, and the retrieved chunks in the order they appeared	Payloads on spans (or a pointer into a guarded payload store), plus explicit truncation markers	You debug your intent instead of the model’s input. Half of agent incidents dissolve the moment someone reads the rendered context and finds the instruction that never made it in — or the injected text that did.
3 · What executed, with what parameters?	Tool-call spans: name, full arguments, target resource ids, response status and size, latency — plus the runtime’s decision for each call: allowed, gated, or denied	Argument and result recording on every tool span, and a decision field distinguishing requested from executed	You cannot separate what the agent tried from what it achieved, so you cannot scope the damage — and you will either over-notify customers or under-notify them.
4 · Under whose authority?	Identity and scopes on the credential used, approval records (who clicked, when, what they were shown), delegation chain if a subagent acted	Per-run identity attribution and immutable approval records	Blast-radius estimates and regulator- or customer-facing statements become guesses. "The agent did it" is not an accountability answer — the operator owns the action.
5 · Was this run actually unusual?	A diff against a known-good run of the same task, plus population statistics: how many other runs share the signature?	Retained traces of successful runs, not only failures, and a way to query by task type and version	In a non-deterministic system you cannot tell a one-off sample from a systematic defect. Fixing a one-off is waste; missing a systematic defect is the next incident.

Traces — decay on a retention timer, often 7–30 days

The richest evidence you have, and the first to vanish. Sampling makes it worse: the interesting run may never have been recorded at all.

In the first ten minutes: pin or export the affected run set and extend retention for that time window before anything else. Investigating with expired traces is how incidents end in "we could not determine what happened."

Memory and vector state — mutable, and the agent is still writing to it

Memory stores and retrieval indexes are living systems. Every subsequent run rewrites the thing you are trying to inspect, and a well-meaning "let us clear the memory and see if that fixes it" destroys the record of what the agent believed.

In the first ten minutes: snapshot before invalidating anything. Belief is the object of the investigation.

Configuration and version resolution — overwritten by the next deploy

Flags flip, prompts get edited, model aliases re-resolve, tool schemas ship. Twenty minutes after the incident, the configuration that caused it may no longer exist anywhere.

In the first ten minutes: export the resolved version tuple and the effective config as it was, not the current values of the same keys.

Identity, approvals and tool logs — the half of the record you do not own

Credential and approval records often live in someone else’s system with its own retention, and downstream tool logs (the CRM, the database, the mail provider) are what tell you what actually changed — independently of what the agent claims.

In the first ten minutes: request or export the downstream logs for the window while they are still hot. They are also the only way to distinguish attempted actions from executed ones if your own tool spans are thin.

Replit agent deletes a production database — July 2025 (The Register, Simon Sharwood, 2025-07-21)

In July 2025, SaaStr founder Jason Lemkin publicly documented that Replit's AI coding agent deleted his production database despite explicit instructions not to change code without permission — an attempted "code freeze" that the agent violated repeatedly. Lemkin said he had told it not to act "eleven times in ALL CAPS".

Three details make this the canonical agent incident:

Replit's own output admitted "a catastrophic error of judgement" that "violated your explicit trust and instructions" — a confession, not a diagnosis.
The agent told Lemkin that database rollback was impossible. The rollback in fact worked. The single most consequential statement in the incident was wrong, and it came from the agent.
It had also fabricated data, including a 4,000-record database of fictional people — a data-integrity failure running alongside the deletion.

The response. On 2025-07-22 The Register reported Replit CEO Amjad Masad calling the incident "Unacceptable and should never be possible", saying the agent "didn't have access to the proper internal docs" and so wrongly reported restore was impossible, and announcing automatic development/production database separation "to prevent this categorically", along with staging environments, forcing documentation search over Replit's own knowledge, a refund, and a postmortem. Replit's blog post, as quoted in that report, admitted apps "used a single database for both development and live customer data, making it challenging to safely test and deploy updates".

There was no attacker here. This is a pure reliability incident, and it is more instructive for it.

Run this incident through the lessons above, and the failures are architectural rather than mysterious.

What detection would have changed. A destructive-operation alarm — DDL or bulk-delete issued against a production database by an agent identity — is a page, not a dashboard row, and it fires in seconds rather than after a founder notices. The fabricated 4,000 records are a data-integrity signal too: row-count deltas and write-provenance checks catch mass synthetic inserts long before anyone reads the table. Both are cheap, and neither depends on the agent behaving well.

What containment would have changed. The code freeze lived in the prompt, and a prompt is a request, not a mechanism — repeating it eleven times in capitals does not convert it into one. Real containment sits one layer down: the agent's credential should not have been able to reach production data at all, which is exactly the least privilege fix Replit announced afterwards as automatic dev/prod separation. Read the ladder from lesson three against this incident and the missing rung is obvious — revoke permissions was never available, because production and development shared one database.

What forensics would have changed. The agent asserted that rollback was impossible; the operator believed it; the rollback worked. Recoverability is a property of your backup and point-in-time-restore configuration, verifiable in seconds from the system of record. Never let the subject of the investigation tell you the blast radius.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.