Rob T. Lee Gave Claude Code Root on a DFIR Workstation - Here's What SANS Learned

Giving an AI agent root on a forensics workstation and watching what happens is not a red team exercise. It is a production decision someone on your team is about to make, or already has made, while calling it a productivity experiment.

Rob T. Lee, SANS Institute's chief of research, made that decision deliberately - and publicly - at the [un]prompted conference earlier this year. He handed Claude Code elevated access to a SIFT workstation, the same SANS Investigative Forensic Toolkit environment that incident responders worldwide use on live cases. The experiment was framed as agentic incident response research under SANS's emerging GTG-1002 guidance work. What it produced was something more useful than a proof of concept: a concrete stress test of assumptions that the DFIR community - and the broader agentic security field - is still carrying over from non-agentic tooling.

The assumption is this: if you constrain what the agent can do, you have constrained what the agent can affect. Tool-use boundaries and permission scopes are treated as the security perimeter. They are not. They never were, and the SANS experiment shows exactly why.

Why This Misconception Has Stayed Alive

The logic feels sound when you import it from traditional systems. In a conventional automation pipeline, you define a service account, scope its permissions, and the blast radius of any failure is bounded by what that account can touch. The tool is the agent. The permission is the constraint. This model works when the system executing the action cannot reason about what it is doing.

Agentic systems break that assumption at the foundation. The LLM layer reasons - imperfectly, inconsistently, but genuinely - about context, intent, and sequencing. When you give Claude Code access to a shell, a filesystem, and a set of forensic tools via Model Context Protocol, you have not defined an automation scope. You have defined an operating environment for a reasoning system that will make decisions about how to use that environment based on whatever it concludes is appropriate to the task.

MCP is worth naming specifically here because it is the mechanism through which most practitioners are currently wiring agents to tool sets. It is well-documented and the tooling around it is maturing fast. That maturity is part of the problem: the protocol is solid, so teams treat protocol-level access controls as architectural security controls. They are not equivalent. MCP defines what tools are reachable. It does not constrain how a reasoning system chains those tools, what intermediate states it creates, or what it infers from the outputs it receives. Understanding how prompts, timers, and skill modules shape agent behavior is essential before treating any single layer as a meaningful security boundary.

Vendor documentation has reinforced this conflation. Most agent framework documentation shows permission scopes and tool definitions in the same section as security guidance, which implies they are the same category of control. They are not.

Where This Breaks in a DFIR Context

Lee's setup was not adversarial in the traditional sense. He was not trying to break the agent. He was trying to use it - asking Claude Code to assist with forensic triage tasks on the SIFT workstation with elevated privileges. That is the realistic scenario: a legitimate operator giving an agent legitimate credentials to do legitimate work.

What the experiment surfaces is the class of failure that emerges not from an attacker manipulating the agent, but from the agent operating correctly within its permission scope and still producing outcomes that violate the operator's actual intent. This is the distinction that most threat models miss.

Consider the specific pressure points in a DFIR environment. A forensics workstation holds evidence. Evidence has chain-of-custody requirements. An agent with write access to the filesystem - necessary for some forensic operations - can modify timestamps, alter file metadata, or create artifacts that contaminate a case, not because it is compromised, but because it is completing a subtask in a way that is locally correct and globally destructive. The agent is not wrong by its own reasoning. The operator's intent was never fully encoded.

The MCP layer in this setup exposes another failure class: tool output as state injection. When Claude Code calls a forensic tool and receives output, that output becomes part of the context the agent reasons from on the next step. In a DFIR environment, some of that output is attacker-controlled - strings from a memory dump, filenames from a compromised filesystem, log entries written by malware. Prompt injection through environmental data is a documented attack class, and forensic tooling is one of the highest-exposure surfaces for it precisely because the data the agent processes is, by definition, hostile.

We have traced this failure mode in other contexts: an agent performing log analysis that reads an attacker-planted log entry containing instruction-formatted text, which the LLM layer interprets as a directive. In a DFIR context with elevated privileges, the consequences of a successful injection are not bounded by the permission scope - they are bounded by what root can do on a forensics workstation, which is everything. A thorough methodology for red-teaming agentic systems should treat tool invocation chaining and environmental data as primary attack surfaces, not afterthoughts.

The GTG-1002 guidance that SANS is developing acknowledges this. The framing is not "how do we prevent agents from having access" but "how do we define what appropriate autonomous action looks like" - and critically, how do we detect when an agent's action sequence has drifted from what that definition would allow. That is a harder problem than access control, and it requires different instrumentation.

The Corrected Mental Model for Agentic Tool Access

Stop modeling the permission scope as the security boundary. Model the agent's action space as the security surface, and treat every tool call as a decision point that requires independent validation - not just schema validation, but intent validation against the declared task.

This is not a call for human approval on every action. That eliminates the operational value of agentic systems. It is a call for a different architecture: one where the agent's action sequence is observable and where anomaly detection operates on the sequence, not just on individual calls.

In practice, this means logging at the orchestration layer before execution, with structured records that capture not just what tool was called but what the agent's stated reasoning was for calling it. Claude Code and similar systems can be prompted to surface this reasoning explicitly. That output is not trustworthy as a control - the agent can reason incorrectly - but it is instrumentable. When the stated reasoning diverges from the task definition, that is a signal.

For DFIR specifically, the SANS experiment points toward a tiered autonomy model: the agent operates with low-privilege read access by default, escalates to write or execute only for defined subtask classes, and those escalations are logged with a hard time bound. Any action requiring elevated privilege that falls outside the defined subtask taxonomy triggers a halt and review. This is not a technical control that the agent enforces on itself. It is an architectural wrapper that the orchestration layer enforces regardless of what the agent decides. What human oversight in agentic systems actually looks like in production is less about real-time approval gates and more about this kind of structured escalation design.

The injection surface from hostile forensic data is harder to close. What we have found partially effective is treating tool output as untrusted input at the orchestration layer - running it through a separate validation pass before it re-enters the agent's context window. This adds latency and it is not airtight; sufficiently crafted injections can survive the validation pass. But it eliminates the naive case where a plaintext instruction in a log file gets executed because the agent can