On a Tuesday morning in an environment I will not name, a security team received an alert that looked like a standard data exfiltration event. Files moved, a credential used in an unusual context, a network path that did not match the user’s normal pattern. They worked the incident the way they always do: pull the logs, interview the user, reconstruct the timeline.

The user was blameless. The AI assistant was not.

The assistant had been given access to a file management tool and a code execution environment. A prompt injection buried inside a document it was asked to summarize told it to move files to a staging directory. The assistant complied. It logged the tool calls exactly as it was designed to. The problem was that nobody on the IR team knew that log existed, where it lived, or what questions to ask of it.

That is the gap I want to talk about.

The Artifacts

What an AI assistant actually generates

When I run an autonomous agent session, it produces evidence in four distinct places. Each place has a different owner, a different retention policy, and a different chain-of-custody status.

graph TD
  Session["AI Session"] --> Logs["Session logs / transcripts"]
  Session --> Tools["Tool call traces"]
  Session --> Git["Git commits + diffs"]
  Session --> Memory["Persistent memory entries"]
  Session --> API["API request logs (provider-side)"]
AI assistant artifact trail — what persists after a session ends

Conversation logs. Every message sent to a model is logged by the provider. Anthropic, OpenAI, and every other commercial API operator retains conversation data under their own terms. The exact retention window and access controls depend on the service tier, the API contract, and whether the session used a consumer product or a direct API call. Some of that data is accessible through the API or a dashboard; some of it is accessible only to the provider; some of it is gone after a defined window. If you run a self-hosted model, you control this layer entirely. If you use a commercial API, you share custody with a third party whose retention policy may or may not match your incident response timeline.

Memory writes. Systems like the prom-memory layer I run on Prometheus write durable facts to a vector store during and after sessions. Every significant event can be memorialized: decisions made, errors encountered, tools called, patterns identified. That memory layer is mine; I control the store, I can query it, and I can audit what was written and when. But the content is only as trustworthy as the session that produced it. If the session was compromised, the memory writes are potentially compromised artifacts.

The memory layer is mine to query. The content of what was written is exactly as trustworthy as the session that wrote it. A compromised session produces a tampered artifact that reads like ground truth.

Tool call traces. Every tool the agent calls can produce a log: shell commands executed, files read or written, APIs hit, external services contacted. The completeness of that log depends entirely on what the tool logs. A file-system tool might log the operation at the OS level, in the tool’s own log, or not at all. An API call might appear in the receiving service’s access log, or it might not. This is the same problem as any distributed transaction: the evidence is scattered across the systems the agent touched, and nobody mapped those systems in advance.

Session state snapshots. Modern agent frameworks checkpoint state. My system writes handoff files at session boundaries: which tasks were active, what decisions were made, where the agent was in a multi-step operation. Those files live on disk and are durable. They are also exact descriptions of what the agent believed it was doing at a specific point in time, which is enormously useful in post-incident reconstruction, if you know they exist.

The Problems

Three forensic challenges specific to this surface

Chain of custody on provider logs. If the relevant conversation happened through a commercial API, the logs are on someone else’s infrastructure. You can request them through the API, a support ticket, or a legal process, but you did not collect them, you do not control them, and you cannot certify that they have not changed since the session ended. Every forensic examiner knows this problem with cloud evidence generally. AI session logs are a specific, underexamined instance of it.

The adversarial artifact problem. This one is specific to AI memory systems and it is not obvious from the outside. A prompt injection can direct an agent to write specific facts to its memory store. When I run forensics on a potentially compromised session, I cannot take memory writes at face value. I have to correlate them against tool call traces and external logs to find where the written narrative diverges from what the tools actually did. The artifact and the attack can come from the same input.

Incomplete tool traces. An agent that runs commands in a shell relies on that shell’s logging. If bash history was disabled, if the container’s audit logs were not captured, if the receiving API was not logging at the right verbosity, there is a gap. The agent may have called ten tools and I can only see eight of them. This is not a new problem; it is a classic distributed systems logging problem. But agents move fast, touch many systems, and cross trust boundaries in ways that make the gaps larger than they would be for a human operator working at human speed.

The Playbook

What incident response needs before the incident

You cannot build a forensic track for a surface you have not inventoried. The time to map where AI assistant evidence lives is before you need to find it.

A few specific things an IR team needs before any incident occurs.

A map of every AI-assisted capability in the environment: which models it calls, which tool integrations it has, and what those tools log. This map needs to answer one question: if this assistant acted on a malicious instruction, which systems would hold evidence? If you cannot answer that in a tabletop, you cannot answer it at 2 AM.

A documented process for requesting provider-side conversation logs. This means knowing the API endpoints, the support escalation path, and the legal process before you need them, not during. Provider retention windows are typically 30 days on non-enterprise tiers. If the incident surfaces at day 31, those conversation logs are gone.

A classification for AI-generated memory artifacts in your evidence handling procedures. Memory writes are not standard logs. They are model-mediated summaries of what happened, and they can be manipulated. Forensic procedures need to treat them as potentially tampered by default and require corroboration against primary sources before they carry evidentiary weight.

A session replay capability, if you run self-hosted agents. Tool call traces, session state files, and handoff documents should be retained somewhere your IR team can reach independently of the agent host. If they live only on the host that was compromised, you have a collection problem that should have been solved in advance.

The IR teams I know have built sophisticated playbooks for endpoint forensics, cloud forensics, and SaaS forensics. Almost none of them have an AI assistant track. That surface exists whether the playbook acknowledges it or not. An assistant that acts on a malicious instruction does not leave a different kind of evidence just because your procedures do not know where to look for it.

Where I’m wrong

The analysis here assumes you are dealing with a sophisticated assistant that has persistent memory and broad tool access. Most deployed AI assistants today are stateless and tool-limited. For those deployments, the forensic surface is much smaller: it may be only the provider’s conversation logs, and only for the session in question.

There is also a signal-to-noise problem I understated. AI assistant environments generate a lot of tool call traces that represent normal, benign activity. Forensic investigators will need to reconstruct intent from volume, and the adversarial artifact problem (planted memory writes, manipulated session state) makes that harder. The playbook framework I described assumes you can distinguish legitimate from manipulated artifacts. In practice, that determination requires external corroboration that may not always be available.

Casey Gager builds a personal AI orchestration platform called Prometheus and writes about AI security at cyberdaemon.ai. Views are his own, not his employer’s.

See also