AI assistants and coding tools introduce a new layer of endpoint activity that many security teams are not yet fully equipped to monitor or understand. These tools operate with a high degree of access: they read local files, execute commands, persist prompts and context, and communicate with external APIs.
As adoption has rapidly accelerated over the past few years, visibility has not kept pace. In many environments, this creates a blind spot where AI-assisted activity can occur with little to no detection coverage.
Understanding how these tools behave and, more importantly, what artifacts they leave behind is critical for defenders. These artifacts can provide insight into what actions were taken on a system, what data may have been accessed, and whether new risks were introduced during AI-assisted workflows.
We’ll explore how AI assistants behave from a Digital Forensics and Incident Response (DFIR) perspective and examine the artifacts they generate on endpoint systems. Specifically:
- Conversation and prompt history
- File system and workspace artifacts
- Plugin, extension, and MCP server usage
How AI Assistants Behave
AI assistants follow a set of core behaviors that define how they operate. These behaviors also directly influence the types of forensic artifacts they leave behind.
At a high level, AI agents:
- Execute commands and scripts locally
- Persist prompts and responses
- Interact with the file system (read, write, modify)
- Communicate with external APIs
- Utilize credentials such as API keys and environment variables
These behaviors form the foundation for understanding how to detect and investigate AI-assisted activity.
Assistant Configurations
Artifacts remain at the configuration and installation stages even in the most common AI assistant and coding tools.
Below is a breakdown of some of the important directories for each AI assistance tool. These are typically used for storing global configuration files that define application settings and session states for each tool.
| Tool |
Artifact Root |
Scope |
Why It Matters |
| Claude Code |
~/.claude/ |
User-wide + project |
Full conversation history, configs, MCP, plugins |
| Cursor |
~/.cursor/ + project dirs |
User + workspace |
AI interaction state, project context |
| Windsurf |
~/.windsurf/ |
User + workspace |
Config + extension state |
| VS Code (AI extensions) |
.vscode/ + ~/.vscode/ |
Project + user |
Extension configs, workspace metadata |
While the structure and content varies by tool, these directories typically contain high-value artifacts related to how the assistant operates and interacts with the system. Some common examples include global configuration files (e.g., claude.json) that define application settings and session state, along with prompt and conversation logs such as history.jsonl or even project specific transcripts stored in projects/<project>/<sessino>.jsonl. These will often include full prompt and response data, timestamps and in some cases references to tool usage or files.
These directories also frequently contain integration and extension configurations. For example, .mcp.json files define connections to external MCP servers, while plugin or extension directories (e.g., plugins/) store metadata and configuration for additional capabilities. Some tools maintain debug, execution logs and file history, or snapshot data as well.
It’s worth noting that similar directories may be distributed across workspace directories, capturing project-specific context, cached interactions, and extension state.
What Can These Artifacts Prove?
At a high level, these directories provide evidence of tool presence, configuration, and usage.
What’s contained within can help establish:
- Which specific AI assistant tools are installed and actively used
- How the tool is configured (e.g., models, integration plugins)
- Which projects or directories were associated with the tools
- Whether external integrations were used (e.g., MCP servers or plugins)
Conversation & Prompt History
Next, we'll take a closer look at some of these files and locations.
| Tool |
Artifact Location |
File / Storage Type |
What It Contains |
DFIR Value |
| Claude Code |
~/.claude/history.jsonl |
JSONL |
Prompt history with timestamps, working directory, session references |
Identify what prompts were run and when; correlate to specific projects |
|
~/.claude/projects/<project>/<session>.jsonl |
JSONL (per session) |
Full conversation transcripts (prompts + responses), tool usage, execution context |
Reconstruct full interaction with a project; recover exact prompts and outputs |
| Cursor |
~/.cursor/ (varies internally) |
IndexedDB / local storage (Electron) |
Cached prompts, chat sessions, interaction state |
Prove AI interaction occurred; partial prompt recovery depending on retention |
|
Project workspace .cursor/ |
JSON / workspace metadata |
Project-specific AI state, references to files used in context |
Tie AI usage to specific repositories or codebases |
| Windsurf |
~/.windsurf |
Local cache / JSON / IndexedDB |
Cached completions, interaction metadata |
Evidence of AI-assisted coding activity; limited prompt visibility |
|
VS Code integration paths(.vscode/, extension storage) |
SQLite / JSON |
Extension state, usage metadata |
Correlate AI usage with specific projects |
| VS Code (AI extensions) |
~/.vscode/User/workspaceStorage/ |
SQLite / IndexedDB-like storage |
Extension data (Copilot, Codeium), session metadata |
Identify AI usage patterns tied to workspace IDs |
|
Project workspace .vscode/ |
JSON |
Workspace settings, extension configs |
Link AI usage to specific projects |
| ChatGPT Desktop |
~/Library/Application Support/ChatGPT/IndexedDB/ |
IndexedDB |
Cached conversation data, session state |
Partial reconstruction of conversations; timeline correlation |
|
Local Storage/ |
JSON-like key-value |
Session tokens, metadata |
Confirm usage and session timing |
What's Inside
Within these files we can often find full prompts, often verbatim, of what users are asking the AI agents and even their responses. This can help provide transparency and even provide timestamps and session IDs to help look at exactly what was prompted and the response of the AI agent. We will examine some Claude Code examples, but the other AI assistants operate in a similar manner. A snippet from a history.json that clearly shows the prompt, timestamp and sessionId.
{"display":"Has anyone really been far even as decided to use even go want to do look more like?","pastedContents":{},"timestamp":1777474993713,"project":"/Users/jarrett/Documents/Nebulock","sessionId":"4f5cfa30-b8f5-4b32-b66f-1ee4f2a418a3"}
{"display":"Can we test this code?","pastedContents":{},"timestamp":1777475421868,"project":"/Users/jarrett/Documents/Nebulock","sessionId":"4f5cfa30-b8f5-4b32-b66f-1ee4f2a418a3"}
Continuing to use Claude as an example, if we want to take an even closer look at can examine the .jsonl files within the projects directory (~/.claude/projects/<project>/<session>.jsonl). This contains much more verbose information including responses from the agent.
{
"type": "assistant",
"uuid": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"parentUuid": "1a2b3c4d-5678-90ab-cdef-1234567890ab",
"timestamp": "2025-02-20T09:14:32.441Z",
"sessionId": "abc123-session-id",
"cwd": "/home/user/myapp",
"version": "2.1.81",
"gitBranch": "feature/add-authentication",
"userType": "external",
"entrypoint": "cli",
"message": {
"model": "claude-sonnet-4-5-20250929",
"id": "msg_bdrk_01ExampleMessageId",
"type": "message",
"role": "assistant",
"content": [
{
"type": "text",
"text": "I'll help you add authentication to the application."
},
{
"type": "tool_use",
"id": "toolu_bdrk_01ExampleToolUseId",
"name": "Read",
"input": {
"file_path": "/home/user/myapp/src/auth.js"
}
}
],
"stop_reason": "tool_use",
"stop_sequence": null,
"usage": {
"input_tokens": 1250,
"cache_creation_input_tokens": 8500,
"cache_read_input_tokens": 0,
"output_tokens": 125,
"server_tool_use": {
"web_search_requests": 0,
"web_fetch_requests": 0
}
}
}
}
What's both interesting and useful is that the parentUuid allows you to reference the message it responded to making it easy to follow the chain of events when the conversation branches, much like how we would trace back a process tree.
You’ll notice tool_use which represents a tool being called by the agent. This can be used to identify command line tool usage, file reads, web fetches, or MCP server calls.
A few of the tools, such as Cursor, Windsurf, and VS Code, store state and configuration data in local database files like state.vscdb, which are SQLite databases. These can be examined using standard tools such as the sqlite3 command-line utility or GUI applications like DB Browser for SQLite. Within these databases, information is typically stored as key-value pairs (often in tables such as ItemTable), with values frequently stored as JSON. While less straightforward than flat files, these databases can provide insight into extension configurations, workspace state, and integration settings, making them a valuable, though often overlooked, source of context during an investigation.
Execution & Code Generation
AI agents execute code in two primary ways: by issuing commands directly and by writing code to disk before executing it locally. Both behaviors are observable through standard endpoint telemetry.
The most direct method is through process tree analysis. By leveraging EDR process events, we can trace command execution back to the originating AI tool and understand the full execution chain.
Process Tree Examples
cursor.exe → powershell.exe
cursor.exe → cmd.exe → python.exe
claude → bash → python
claude → bash → sh → node
windsurf → bash → python
These relationships allow us to clearly attribute execution to the originating AI tool and analyze how it interacts with the underlying system through spawned shells and interpreters.
In addition to process activity, AI-generated code is often written to disk prior to execution, typically in temporary directories or within the active workspace. This behavior can be observed through file write events in locations such as:
| Tool |
macOS / Linux |
Windows |
Notes |
| Claude Code |
/tmp/
/private/var/folders/ |
%TEMP%
C:\Users\<user>\AppData\Local\Temp\ |
Uses system temp directories for script staging; also executes within working directory |
| Cursor |
/tmp/
/private/var/folders/ |
%TEMP% |
Relies on system temp + workspace directories for generated code |
| Windsurf |
/tmp/ |
%TEMP% |
Similar behavior via editor/runtime execution |
| VS Code (AI extensions) |
/tmp/ |
%TEMP% |
Extensions may stage files before execution |
These file writes can often be correlated with conversation artifacts and workspace context, helping establish what was generated and why.
By combining process trees, file write activity, and conversation history, we can determine whether code was likely generated by an AI tool and whether it was executed locally. This enables several useful detection opportunities, including:
- Identifying unusual parent-child process relationships
- Correlating execution activity with prompt timestamps
- Detecting iterative AI-assisted execution loops
File System & Workspace
In addition to process execution, file system telemetry provides another way to understand how AI agents interact with a system. By leveraging file write events from EDR platforms, we can build a clear picture of where these tools are operating and what they are modifying.
AI assistants frequently write files within active workspace directories, such as .cursor, .claude, or project-specific folders. Monitoring these locations allows investigators to identify when projects were interacted with, when scripts were written and general interactions with the assistant.
As an example, we can query for files being written to these locations to find users starting new sessions:
/Users/jarrett/.claude/projects/-Users-jarrett-Documents-test-detections/17f6b4eb-2840-4d99-8ecf-3e0a4628877b.jsonl
This activity can be used to:
- Identify which projects or directories were involved in AI-assisted work
- Track files created or modified by the agent
- Correlate file activity with prompt history and execution events
When combined with process and conversation artifacts, file system telemetry helps establish a more complete view of how AI tools interact with local codebases and what changes they introduce over time.
Plugin, Extension, and MCP Server
AI assistants often expand their functionality through plugins, extensions, and MCP usage servers. While these integrations enable more powerful workflows, they also introduce additional risk. As we’ve seen with broader supply chain compromises and abuse of third-party tooling, understanding what integrations are present on a system is critical for assessing exposure.
These integrations effectively extend the capabilities of the AI assistant beyond the local environment. In practice, this means the tool may be able to interact with external APIs, internal services, or local scripts depending on how it has been configured.
Common extension mechanisms include plugins, editor extensions, and MCP server configurations. These can typically be identified by examining tool-specific directories and workspace configuration files.
| Tool |
Example Locations |
What to Look For |
| Claude Code |
~/.claude/plugins/.mcp.json (project root) |
Installed plugins, MCP server definitions, external endpoints |
| Cursor |
~/.cursor/ Project workspace |
Extension state, tool configs, integration metadata |
| Windsurf |
~/.windsurf/ |
Extension configs, Codeium integration data |
| VS Code (AI extensions) |
~/.vscode/extensions/.vscode/ |
Installed extensions (Copilot, Codeium), workspace settings |
Our Head of Threat Hunting Sydney Marrone recently wrote a highly informative Hunt Mode on MCP servers that's worth a read. It includes some additional information on command line patterns to look for in MCP exploitation.
Reconstructing AI Activity
Now that we’ve covered the different artifacts left behind by AI assistant tools, we can walk through a simple example of how these signals can be combined to reconstruct activity during an investigation.
Configuration artifacts → Tool presence
Identify directories such as .claude, .cursor, or .windsurf to confirm that an AI assistant was installed and used on the system. These locations also provide insight into how the tool was configured and what capabilities were enabled.
Conversation logs → User intent
Review artifacts like history.jsonl or session transcripts to understand what the user asked the tool to do. This provides direct visibility into intent, including requested scripts, commands, or data access.
File writes → Generated code
Analyze file write events in workspace directories or temporary locations to identify where the AI assistant generated code or supporting artifacts. This helps establish what was created on disk and where.
Process execution → Script ran
Use process telemetry to trace execution chains (e.g., claude → bash → python) and confirm that generated code was executed locally. This step validates that activity moved from generation to execution.
Network activity → External interaction
Correlate network logs to identify outbound connections to APIs, MCP servers, or other external services. This helps determine whether data was transmitted or external systems were accessed.
Move Beyond Simple Detections
AI-assisted workflows introduce a new layer of endpoint activity that blends user intent, automated execution, and external integrations. While this can make investigations more complex, it also creates new opportunities for defenders.
The artifacts left behind by these tools provide a unique combination of context and execution data. When properly correlated, they allow investigators to move beyond simple detection and reconstruct how AI tools were used, what actions were taken, and where risk may have been introduced.
As adoption continues to grow, building visibility into these behaviors will become an increasingly important part of modern threat hunting and incident response.
Assistant File Location Reference
| Tool |
General Configuration |
Conversation / Prompt History |
Plugins / Extensions |
MCP / Integrations |
| Claude Code |
~/.claude/
.claude/settings.json (project) |
~/.claude/history.jsonl
~/.claude/projects/<project>/*.jsonl |
~/.claude/plugins/ |
~/.claude.json
.mcp.json (project specific) |
| Cursor |
~/.cursor/
.../Cursor/User/globalStorage/state.vscdb |
IndexedDB / local storage (internal)Workspace context in .cursor/ |
VS Code extension system + workspace |
Stored within workspace config or internal state (no single standard file) |
| Windsurf |
~/.windsurf/
.../Windsurf/User/globalStorage/state.vscdb |
Limited local history (cache/state) |
VS Code extension system |
mcp_config.json (observed, may vary by setup) |
| VS Code (AI extensions) |
~/.vscode/
.vscode/settings.json
.../User/globalStorage/state.vscdb |
Extension-dependent (workspace storage) |
~/.vscode/extensions/ |
Extension-specific (varies; typically JSON in workspace or globalStorage) |
