Most organisations have spent the last two years arguing about whether developers are allowed to use AI coding assistants. Very few have asked the follow-up question, which is the one that matters when something goes wrong: if an agent ran a command on an engineer's workstation at 02:00, how would you reconstruct it?

That question is now firmly in forensic territory. SANS has refreshed FOR577 with material on investigating AI usage during incident response, covering eight of the common coding assistants and agents — Claude Code, Codex, Gemini CLI, Cursor, Copilot, Warp, Windsurf and Qwen Code — along with scripts for reconstructing their activity. The existence of that curriculum update is, I'd argue, more significant than any individual artefact it describes. It marks the point at which agent activity stops being a productivity story and becomes an evidence-handling problem.

The threat model nobody wrote down

A coding agent is, functionally, a process running with a developer's full local privileges that takes instructions from a remote model, reads arbitrary files in its working directory, writes code, and in many configurations executes shell commands. Describe that to a security review board without the word "AI" attached and you'd expect a long conversation. Describe it as a developer tool and it arrives through the IDE marketplace or a brew install with no conversation at all.

The risks are not exotic. Prompt injection via a poisoned repository, a README or a dependency's documentation is a well-documented class of attack against tools that read untrusted content and then act. Credentials sitting in environment variables or dotfiles are readable by anything running as the user. Agents that can execute commands can exfiltrate as easily as they can refactor. None of this requires the model to be malicious — it only requires the model to be persuadable, which is the entire premise of the technology.

Local-first tooling breaks your logging assumptions

Here's the part that catches teams out. A decade of security tooling investment has gone into server-side and cloud-side visibility: sign-in logs, audit logs, SaaS activity feeds, network telemetry. CLI-based coding agents sit almost entirely outside that. They run on the endpoint. Their session history, prompts, tool invocations and file modifications land in local configuration directories and state files under the user's home directory — the sort of location that gets wiped on reimage and is rarely collected during triage.

So the practical state of most estates is this: the agent's conversation with the model is logged by the vendor, the code it produced ends up in Git, and everything in between — which tool calls it made, which files it read, what it ran — lives in artefacts you are not collecting and would struggle to interpret if you did. That gap is precisely what forensic scripts for these tools are designed to close.

Four things worth doing before you need them

  • Inventory what's actually installed. Ask your endpoint management and EDR estate which agent binaries and IDE extensions are present. Not which ones are approved — which ones are running. The answer is usually broader than the policy suggests.
  • Add agent state directories to your triage collection. If your DFIR collection profile predates these tools, it does not include them. The config and session paths are documented per-tool and are a small change to an existing collection script.
  • Establish retention before an incident, not during one. Local session history is frequently capped or rotated. If you want ninety days of it, you need to be shipping it somewhere, and you need to have decided that in advance.
  • Decide whether agents get their own identity. Anything that authenticates to a repository, a cloud subscription or an internal API on behalf of an engineer should be distinguishable in the logs from the engineer themselves.

The attribution problem is the real one

That last point deserves expanding, because it is where this intersects with identity work most organisations are already doing. When an agent commits code using the developer's Git credentials, pushes using their PAT, and calls an internal API with their token, every downstream log says the human did it. Your audit trail is accurate about the credential and wrong about the actor.

In a routine week that distinction is academic. In an incident it is everything. "Did Sarah run that query against production, or did something running as Sarah run it?" is not a question you want to be answering by reading a chat transcript after the fact. The answer determines whether you are handling a compromised endpoint, an insider matter, or a tooling misconfiguration — three very different response paths with three very different sets of people involved.

The conventional controls still apply, and they apply more sharply here than they do to most tooling. Workload identities for non-human actors. Scoped, short-lived tokens rather than long-lived PATs. Separate service principals where an agent touches cloud resources. Branch protection and required review on anything an agent can push to. None of that is new advice — it's the same least-privilege discipline that applies to CI runners and automation accounts. The novelty is that the thing holding the credential now makes its own decisions about what to do with it.

Where this lands for delivery teams

I'd resist the instinct to respond to all of this with a ban. Blanket prohibition on coding assistants tends to produce shadow usage on personal machines, which is strictly worse from both a security and a forensic standpoint — at least a sanctioned tool on a managed endpoint leaves artefacts you can collect. The more useful posture is to pick a small set of supported tools, run them on managed devices, give them scoped identities, and make sure your incident response capability knows where their traces live.

[AUTHOR: add a real example here if you have one — how agent usage was handled in an estate you know well.]

The broader signal is worth noting. When a DFIR course adds a day's material on a technology, that technology has crossed from emerging to operational. Agent activity is now something investigators expect to find on compromised hosts, and something they expect to have to explain. If your runbooks, collection scripts and identity model haven't caught up with that, the update is overdue — and it is a modest amount of work compared to discovering the gap mid-incident.

Source: Reconstructing AI Agent Activity: Two New Scripts for Forensic Review (SANS Internet Storm Center)