Paper deep dive
Foundations for Agentic AI Investigations from the Forensic Analysis of OpenClaw
Jan Gruber, Jan-Niclas Hilgert
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 95%
Last extracted: 4/10/2026, 3:17:01 AM
Summary
This paper presents a foundational forensic analysis of OpenClaw, an open-source agentic AI assistant. The authors perform static code analysis and differential forensic analysis to identify and classify digital traces within the agent's interaction loop. They propose an agent artifact taxonomy and highlight challenges such as nondeterminism and agent-mediated execution, providing a framework for future digital forensic investigations of autonomous AI systems.
Entities (5)
Relation Signals (3)
Jan Gruber → authored → Foundations for Agentic AI Investigations from the Forensic Analysis of OpenClaw
confidence 100% · Paper title and author list
OpenClaw → uses → SQLite
confidence 95% · The memory architecture is built upon plain text files and an SQLite database
OpenClaw → implementedin → TypeScript
confidence 90% · The system is implemented primarily in TypeScript
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Agentic Al systems are increasingly deployed as personal assistants and are likely to become a common object of digital investigations. However, little is known about how their internal state and actions can be reconstructed during forensic analysis. Despite growing popularity, systematic forensic approaches for such systems remain largely unexplored. This paper presents an empirical study of OpenClaw a widely used single-agent assistant. We examine OpenClaw's technical design via static code analysis and apply differential forensic analysis to identify recoverable traces across stages of the agent interaction loop. We classify and correlate these traces to assess their investigative value in a systematic way. Based on these observations, we propose an agent artifact taxonomy that captures recurring investigative patterns. Finally, we highlight a foundational challenge for agentic Al forensics: agent-mediated execution introduces an additional layer of abstraction and substantial nondeterminism in trace generation. The large language model (LLM), the execution environment, and the evolving context can influence tool choice and state transitions in ways that are largely absent from rule-based software. Overall, our results provide an initial foundation for the systematic investigation of agentic Al and outline implications for digital forensic practice and future research.
Tags
Links
- Source: https://arxiv.org/abs/2604.05589v1
- Canonical: https://arxiv.org/abs/2604.05589v1
Trouble viewing inline? Open PDF directly →
Full Text
71,962 characters extracted from source content.
Expand or collapse full text
Foundations for Agentic AI Investigations from the Forensic Analysis of OpenClaw Jan Gruber a,∗ , Jan-Niclas Hilgert b a KASTEL Security Research Labs, Karlsruhe Institute of Technology, Am Fasanengarten 5, 76131 Karlsruhe, Germany b Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE, Zanderstr. 5, 53177, Bonn, Germany A R T I C L E I N F O Keywords: AI forensics digital investigations non-traditional forensic scenarios A B S T R A C T Agentic AI systems are increasingly deployed as personal assistants and are likely to become a common object of digital investigations. However, little is known about how their internal state and actions can be reconstructed during forensic analysis. Despite growing popularity, systematic forensic approaches for such systems remain largely unexplored. This paper presents an empirical study of OpenClaw—a widely used single-agent assistant. We examine OpenClaw’s technical design via static code analysis and apply differential forensic analysis to identify recoverable traces across stages of the agent interaction loop. We classify and correlate these traces to assess their investigative value in a systematic way. Based on these observations, we propose an agent artifact taxonomy that captures recurring investigative patterns. Finally, we highlight a foundational challenge for agentic AI forensics: agent-mediated execution introduces an additional layer of abstraction and substantial nondeterminism in trace generation. The large language model (LLM), the execution environment, and the evolving context can influence tool choice and state transitions in ways that are largely absent from rule-based software. Overall, our results provide an initial foundation for the systematic investigation of agentic AI and outline implications for digital forensic practice and future research. 1. Introduction AI agents represent a fundamental leap in artificial in- telligence, transforming chatbots into autonomous systems that can reason, plan, and execute real-world workflows. The highly popular open-source software project OpenClaw democratizes this technology, allowing non-technical users to deploy powerful agents as personal assistants without complex coding, which suggests these systems will soon become common in digital investigations. 1 Despite this trail- blazing trend, the forensic community currently lacks both experience with and an understanding for identifying and analyzing the traces produced by these systems. 1.1. Motivation In the past months, we have seen a rapid development from agentic AI used for coding and online workflows evolv- ing into “personal AI assistants” into semi-autonomous enti- ties embedded deeply in users’ daily lives. While they resem- ble earlier smarthome assistants in their ability to support the user in accomplishing task, for instance in form of Amazon’s ecosystem [5, 6], these new systems extend far beyond pas- sive interaction: they execute multi-step workflows, integrate deeply with the operating systems and online services, and are granted broad permissions over highly sensitive personal data. Furthermore, these systems are intended for always- on assistance running 24/7 and operate as more or less ∗ Corresponding author Email addresses: jan.gruber@kit.edu (J. Gruber); hilgert@cs.uni-bonn.de (J. Hilgert) ORCID(s): 0000-0003-1862-2900 (J. Gruber); 0009-0000-5308-5712 (J. Hilgert) 1 See https://w.wired.com/story/clawdbot-moltbot-viral-ai-assis tant/. autonomous entities while their actions can produce real- world effects that are not fully anticipated or even observed by the human operator. User reports of OpenClaw instances initiating purchases without explicit user awareness, or dis- closing sensitive personal information. In such cases, the central forensic question is not only what happened on the host, but what the assistant actually did versus what the user requested, knew, or intended—an attribution problem that current forensic understanding struggles to resolve. Consequently, a significant research gap exists in the forensic analysis of agentic assistants, rooted both in lim- ited system understanding and the absence of dedicated investigative methodologies. Existing digital forensic ap- proaches are ill-equipped to handle the combination of cloud-mediated reasoning, local execution, and continuous autonomy. This work addresses this gap by establishing the foundation for the forensic examination of AI assistants. 1.2. Contributions To our knowledge, this work presents the first foren- sic analysis of a personal AI assistant, using the trailblaz- ing open-source system OpenClaw as a representative case study. We begin by describing the technical architecture of OpenClaw. Based on static code analysis, differential analysis, and in-depth file system examination, we identify and correlate digital traces with observed agent behavior. We structure our examination around representative investiga- tive questions and demonstrate how they can be addressed through the locally available artifacts. We synthesize the theoretical agent interaction loop and core components with our empirical findings on OpenClaw to propose an agent artifact taxonomy. Organized into five PreprintPage 1 of 13 arXiv:2604.05589v1 [cs.CR] 7 Apr 2026 Gruber & Hilgert / Foundations for Agentic AI Investigations planes, this functional taxonomy captures the distinct as- pects of such systems and provides a foundation for system- atic analysis. To support practical analysis, we implement a proto- type tool that automatically extracts and correlates local artifacts from an OpenClaw installation. Experimental data and source code are made publicly available. 2 Collectively, our results establish an initial foundation for the forensic examination of personal AI assistants and highlight key im- plications for digital forensics, including challenges related to context reconstruction, nondeterminism, and abstraction. 2. Background & Related Work 2.1. Agentic AI and AI Agents Agentic systems extend generative AI by planning, ac- tion, memory, and adaptation [15]. They are designed to take initiative on behalf of users rather than merely responding to prompts [13]. Definition 2.1 (Agentic AI). Agentic AI is “an AI system or software that can understand human problems, collect re- lated data, use the data, and perform self-determined tasks to solve the problem with zero or minimum human intervention by interacting with its environment” [18]. It denotes the broader architectural approach of combining AI agents. Definition 2.2 (AI agent). An AI agent (or single-agent sys- tem) is a computational entity that perceives its environment, reasons about observations, and executes actions in pursuit of explicit goals with limited human intervention [19, 1]. To do so, such AI agents are not dependent on direct guid- ance and coordination with other autonomous agents to solve the task at hand. They have the ability to manage complex task and solve them using multi-step approaches [15, 19]. LLM Core. AI agents are structured around a LLM that serves as the core reasoning and generative component. Unlike standalone language models, the LLM is extended with mechanisms for planning, memory access, and tool selection, enabling it to interpret user and environmental inputs and coordinate actions as an autonomous decision- making agent [13]. Reasoning and planning capabilities allow the agent to decompose complex objectives into ordered, multi-step actions. Agentic systems typically operate in an iterative cycle, where intermediate results are incorporated back into the model’s context to refine subsequent decisions and adapt strategies over time [13]. Memory and Context. To maintain coherence across long-horizon tasks, AI agents incorporate memory compo- nents, including short-term contextual memory and persis- tent, retrieval-augmented storage. These mechanisms ground 2 See https://github.com/jgru/forensic-analysis-of-openclaw, Commit d9e8e4. the agent’s reasoning, support evolving goals, and reduce redundant computation by enabling reuse of relevant past information [13]. Tools, Actions, and Services. Agentic AI systems are further distinguished by their integration with external tools and interfaces, such as APIs and software environments. When it is needed, the agent takes action by invoking these tools, e.g., using a search or transcription API, or some CLI tool [15]. Control and Interaction Loop. A control loop orches- trates adaptive, goal-directed behavior that differentiates AI agents from traditional single-pass AI models [13, 12]. The agent first perceives inputs from the user or environment, it incorporates them into the LLM’s context and memory, uses the reasoning and planning components to determine a strategy, and executes the plan through tool-driven actions. Afterwards, it observes outputs and the actions’ results to update its context and memory (either episodic or long- term) [19]. 2.2. Related Work Prior work can be broadly grouped into two streams. First, researchers have applied machine learning and AI models to conduct or support digital forensic investiga- tions, traditionally through narrow, task-specific methods [8, for an overview] and increasingly through general-purpose LLMs [20], including explorations using agentic AI frame- works [24]. Second, researchers have examined AI systems them- selves as forensic objects—as subjects of investigation, in- struments enabling wrongdoing, or targets of attack. Our work contributes to this latter (and comparatively sparse) stream. Schneider and Breitinger [21] examined the attri- bution and accountability challenges that arise when AI systems act with limited or no real-time human oversight. They highlighted the difficulty of determining whether an AI system merely executed predefined logic or exhibited behavior that could be considered independent or emergent. This distinction is central to forensic analysis of autonomous AI agents, such as OpenClaw. In contrast to prior work that focuses on defining AI forensics, recent work has begun to operationalize AI forensics by proposing concrete sources of forensic evidence within AI systems. In this context, Dragonas et al. [7] present a forensic analysis of the Chat- GPT mobile application, demonstrating the feasibility of extracting evidence related to LLM interaction in this mobile application. Chernyshev et al. [4] focused the LLM itself. They were the first to analyze LLM invocation logs to recon- struct intent, usage patterns, and misuse. As the first forensic analysis of agentic tooling, Walker et al. [23] investigated forensic artifacts when using Microsoft’s AutoGen multi- agent LLM framework. In their experiments, they identi- fied logs, configuration files, agent communication traces, and execution metadata that enable reconstruction of agent behavior and task workflows. Their findings demonstrated that meaningful forensic analysis is possible in multi-agent PreprintPage 2 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations LLM environments and emphasize the need for specialized methodologies to support investigations involving collabo- rative AI systems. While OpenClaw is an orchestration layer utilizing LLMs for reasoning, this work is related insofar that they deal with identifying internal AI artifacts—such as logs and prompts—as forensic evidence. Our analysis of OpenClaw, however, goes beyond these settings, as OpenClaw operates as an AI assistant with substantially greater autonomy and much deeper integration into the host system, enabling persistent state, direct interaction with local resources, and self-directed task execution, which introduces a broader and more complex forensic surface. Using the taxonomy proposed by Behzadan and Baggili [2], the present paper is situated in the field of AI Substrate and AI Application Forensics contributing to the conceptual and methodological foundations of AI forensics providing empirical insights into the forensic analysis of agentic AI systems. 3. Architecture of OpenClaw 3.1. Overview of the Functionality OpenClaw is a self-hosted personal AI assistant designed to translate natural-language instructions into concrete ac- tions across connected devices and services. At a high level, the system comprises a centralized gateway and a primary agent capable of spawning subagents. OpenClaw enables continuous interaction with users through existing messaging applications as well as ded- icated companion apps for macOS, iOS, and Android. Functionally, OpenClaw combines LLM-based reasoning with device-level execution implemented through extensi- ble skills. These skills enable operations such as sending emails, controlling a web browser, managing calendar ap- pointments, and interacting with the local file system. The integration of persistent memory, natural-language reason- ing, direct system interaction, and subagent management distinguishes OpenClaw as an agentic system. From a more technical perspective, OpenClaw is designed as a modular, local-first platform to act as an orchestration layer around an LLM at its core, services through APIs, and data stores (such as file systems). The system is implemented primarily in TypeScript and can be run via a JavaScript runtime environments Node.js and bun. 3.2. Gateway Service At the heart of the architecture lies the gateway, a Node.js-based service acting as the always-on and remotely accessible central process. It employs an event-driven archi- tecture to handle real-time communication, utilizing Web- Sockets for client connectivity and internal event emitters for subsystem coordination. The Gateway is responsible for: • Lifecycle Management: Orchestrating the initializa- tion, execution, and termination of sessions. • Routing & Dispatch: Multiplexing incoming messages from external channels (e.g., Telegram, WhatsApp, Slack) to the appropriate agent contexts. • Tool Execution: Providing a runtime environment where agents can invoke local tools, ranging from executing Bash commands to browser automation. Hence, it is the central component of the event/control-plane. 3.3. Pluggable Communication Channels OpenClaw abstracts external communication platforms through a modular plugin system located. Each channel (e.g., Telegram, WhatsApp via Baileys, Discord, Slack) operates as an independent module that normalizes incoming events into a standard internal schema. The architecture decouples the transport layer from the agentic logic. A “Dock” abstrac- tion manages the connection state (e.g., WebSocket keep- alives or webhook listeners), ensuring that agent cognition remains agnostic to the specific medium of communication. 3.4. Memory and Persistence Layer An important feature of OpenClaw is its reliance on local persistence for context management. The memory architec- ture is built upon plain text files and an SQLite database, enhanced with the sqlite-vec extension to support vector embeddings. The system maintains several Markdown files where the agent stores important facts to load as context and a memory.sqlite containing chunked text and associ- ated vector embeddings in a chunks_vec_* table. This allows agents to perform semantic search and retrieval-augmented generation. 3.5. Security and Integrity For providing a secure environment, OpenClaw relies on the concepts of permissions, containment, and human oversight to mitigate risk of autonomous agent executing destructive commands. To do so, the architecture supports a strict Policy Enforcement Model. Sensitive operations, particularly those involving shell execution, can potentially be sandboxed using Docker containers with minimal priv- ileges (read-only root, network isolation). Additionally, an Execution Approval Manager gates critical actions, ensuring a "Human-in-the-Loop" workflow by holding high-risk tool calls in a pending state until explicit authorization is granted. 4. Methodology 4.1. Experimental Design The experiments were conducted in a virtualized envi- ronment managed by Oracle VirtualBox, the guest virtual machine operated on Debian GNU/Linux 13 (Codename: Trixie). Within this virtualized environment, OpenClaw in version 2026.2.2-3 3 was installed and operated to generate the requisite test data. Following the methodology of Kälber et al. [14], we systematically generated test data by executing a series of actions (휎 푖 ∈ Σ) that encompass installation, setup, and 3 https://w.npmjs.com/package/openclaw/v/2026.2.2-3 PreprintPage 3 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations 푞 0 푞 1 푞 2 푞 3 푞 4 푞 5 푞 6 푞 7 푞 8 푞 9 푞 10 푞 11 푞 12 푞 13 Baseline Install OpenClaw Run Onboarding Bootstrap TUI Send Text Msg Send Voice Msg Send Image Install Gog Send Gmail Message Add Google Cal Event Browse Wikipedia Remember Fact Spawn Subagent Delete Data 휎 1 휎 2 휎 3 휎 4 휎 5 휎 6 휎 7 휎 8 휎 9 휎 10 휎 11 휎 12 휎 13 훿 1 훿 2 훿 3 훿 4 훿 5 훿 6 훿 7 훿 8 훿 9 훿 10 훿 11 훿 12 훿 13 Figure 1: Data generation workflow. Actions 휎 푖 transition the system states 푞 푖 , enabling differential analysis 훿 푖 to isolate artifacts. various interactions with the agent. Each action transitions the system to a distinct state (푞 푖 ), which is captured as a disk image, starting from a baseline 푞 0 . Fig. 1 illustrates this process, enabling the isolation of artifacts tied to specific agent functionalities. 4.2. Analysis Procedure Our analysis combined static code analysis, differential analysis, and file inspection to locate and interpret relevant traces. First, we performed static code analysis of the source code. This step provided an overview of the application’s ar- chitecture, its components and their main functionality, and potential data storage locations (such as database schemas or configuration files) before generating any user data. Next, we applied the differential forensic analysis [11]. This allowed us to isolate the specific effects of an ac- tion by comparing the differences between two sequential images. We utilized the Sleuthkit in conjunction with the DFXML library [10] and the Python script idifference2.py [9], to programmatically identify changes 훿 푖 in the file system induced by the action 휎 푖 in question by comparing two consecutive state images⟨푞 푖 ,푞 푖+1 ⟩. The tool detects changes across five specific categories: file or directory creation, deletion, renaming, content modification, and timestamp updates. To focus the investigation, we applied a filter to exclude system background noise unrelated to the executed actions. Finally, the remaining candidates of file system changes were subsequently verified and inspected in-depth. We parsed the relevant files—including plain text files, SQLite databases, JSONL files, and others—using standard forensic tooling and custom scripts. The data recovered from these files were then compared against the known inputs from the test data generation phase to confirm the artifacts’ content. 5. Forensic Analysis of OpenClaw We now present the results of our analysis. We begin with an overview of the main artifact locations, then struc- ture our findings around the core components of the agent architecture described in Section 2.1: the agent’s cogni- tive engine and configured identity, its accumulated knowl- edge, its communication interfaces, and its executed actions. This organization reflects the modular design of agentic AI systems, where each architectural component produces forensically distinct artifacts that require different analytical approaches. For each component, we address representative investigative questions and introduce the relevant artifacts in detail. For reproducibility and documentation, we provide the description of the experiments in literate programming style, experimental data, and a tool supporting the analysis as sup- plementary material (Section B). 4 There, we documented our main findings in the artifacts YAML format to feed machine-readable knowledge bases, like the Digital Foren- sics Artifacts Repository [17]. 5.1. Artifact Overview While standard Linux OS artifacts are well understood and should of course be included in an investigation, we focus in the following on artifacts specific to OpenClaw. In a standard installation, the vast majority of data linked to the AI agent resides in a hidden directory named .openclaw in the user’s home directory. Table 1 summarizes the primary artifact locations. All paths are relative to this directory unless stated otherwise. Ephemeral runtime logs are written outside this directory to /tmp/openclaw/*.log. 5.1.1. Session Transcripts Session transcripts are the single richest forensic artifact in the system, as they record not only communication but also reasoning traces, tool invocations, and context state. Because they span all aspects of the agent’s operation, we in- troduce them here before turning to the component-specific analysis. OpenClaw organizes conversations using a two-level hierarchy. A session represents a long-lived conversation context and is identified by two complementary keys: (i) a human-readable sessionKey (e.g., agent:main:main) used for routing, and (i) a UUID-based sessionId that uniquely identifies a session instance. Sessions persist across inter- actions and record metadata such as the working directory, model/provider overrides, the configured thinking level, and the path to the transcript file. A session transitions through the states idle (awaiting input), processing (actively execut- ing), and waiting (queued messages pending). 4 See https://github.com/jgru/forensic-analysis-of-openclaw, commit d9e8e4. PreprintPage 4 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations Table 1 Overview of OpenClaw artifact locations and their forensic relevance. Phase columns indicate relevance to: Char. = Agent Characterization, Know. = Knowledge Reconstruction, Inter. = Interaction Tracing, Act. = Action Reconstruction. Relevance levels: = primary evidence,= secondary evidence, blank = not relevant. PathContainsChar. Know. Inter. Act. openclaw.jsonAgent, model, channel, and permission settings openclaw.json.bak*Historical configuration snapshots credentials/Channel authentication (Telegram, WhatsApp) agents/id/agent/auth-profiles.json Provider credentials (OAuth tokens, API keys) devices/, identity/Paired companion devices and keys workspace/*.mdAgent persona, user profile, tool definitions, curated memory workspace/skills/Custom agent skill definitions workspace/memory/Daily memory logs (created on demand) memory/agent_id.sqliteSemantic search embeddings agents/id/sessions/sessions.jsonSession metadata and mappings agents/id/sessions/*.jsonlFull conversation and tool execution history media/inbound/User-uploaded files (images, voice notes) cron/jobs.jsonScheduled autonomous task definitions cron/runs/jobId.jsonlExecution logs for scheduled tasks subagents/runs.jsonDelegated task tracking /tmp/openclaw/*.logRuntime events Within a session, individual user interactions are exe- cuted as runs. A run is a transient execution instance identi- fied by a runId. Run progression can be traced through debug log messages that mark stages such as prompt start, agent start, tool execution, agent end, and prompt end. In parallel, a structured event system emits events on categorized streams: the lifecycle stream tracks run state via phases start, end, and error; the tool stream records tool invocations (start, update, result); and the assistant stream carries model output. Together, these two trace layers enable fine-grained forensic reconstruction of individual runs. Session Index and Mapping. Local session data is stored under ~/.openclaw/agents/<agentId>/sessions/. Within this directory, sessions.json tracks current and past sessions and maps sessionKey values to their corresponding sessionId values. The sessionId can then be used to locate the session transcript file <sessionId>.jsonl. Session Transcript Files. Session history is persisted in JSONL files located at ~/.openclaw/agents/<agentId>/- sessions/<sessionId>.jsonl, where each line is a self- contained JSON object with id and parentId fields. The file begins with a session header entry (version 3) containing the session UUID, creation timestamp, and working directory. Subsequent entries record configuration changes, extension- injected state, and—most importantly—the conversation it- self as message entries carrying a role field and typed content blocks. The specific record types are described alongside the components they relate to in the following subsections. Lifecycle and Recovery. OpenClaw employs a soft-delete mechanism: when a session is deleted, the transcript is renamed in place with a .deleted.<timestamp> suffix and removed from the sessions.json index, rather than being expunged. 5.1.2. Log Data Log data is stored in /tmp/openclaw/. The directory may contain multiple log files, typically one per day, named openclaw-Y-M-D.log. The retention policy is hard-coded: log files older than 24 hours are deleted. The log cleanup routine runs automatically when the logger is first initialized (early in application startup) or when the logger configuration changes. Log data is stored in JSON format, with each line rep- resenting an independent JSON object that includes details about the subsystem that generated the entry, along with a time field that records when it was emitted. 5.2. Agent Characterization The first step in examining an agentic system is to establish what the agent is, how it reasons, and what it could do. This requires answering several investigative questions: How is the agent configured? What LLM drives its reason- ing? What capabilities and permissions are available? How has the configuration changed over time? 5.2.1. Configuration and Identity The primary configuration is stored in openclaw.json under the agents section. It defines defaults such as the selected model (e.g., Gemini 3), as well as global settings including the workspace root, which defaults to workspace/ within ~/.openclaw/. During onboarding, OpenClaw creates an initial agent named main; additional agents can be added later and are listed in the list entry. Each agent entry specifies, among other parameters, the model, workspace path, and an agent directory. The agent’s persona and operational boundaries are de- fined by a set of workspace files initiated by AGENTS.md and BOOTSTRAP.md (the latter is deleted after initialization by the agent itself). Crucial files include: IDENTITY.md (agent name/avatar/“creature type”), SOUL.md (core truths, person- ality traits, and safety boundaries), TOOLS.md (environment- specific technical details, e.g., SSH hosts and aliases), and HEARTBEAT.md (periodic awareness tasks executed in the main PreprintPage 5 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations session). These files, together with the system prompt assem- bled from them, constitute the agent’s configured identity and behavioral policy. Agent-specific provider credentials (e.g., API keys or OAuth tokens) are stored in auth-profiles.json within the respective agent directory. Session-level configura- tion and operational metadata can be reconstructed from agents/id/sessions/sessions.json, which may record per- session parameters such as the active provider/model as well as usage statistics (e.g., token utilization). 5.2.2. Capabilities and Permissions OpenClaw distinguishes between tools and skills. Tools represent executable actions (e.g., reading/writing files or invoking exec to run commands), whereas skills provide task-specific guidance and prompt material to teach the agent how to use tools effectively. Skills are defined by a SKILL.md file and can be stored either globally in skills/ or agent-locally under workspace/skills/. In addition, OpenClaw may provide bun- dled skills (e.g., guidance for querying weather information). Tool implementations reside in the OpenClaw codebase (e.g., src/agents/tools/*.ts). Evidence of tool and skill availability can be extracted from an agent’s sessions.json. For skills, the skillsSnapshot structure may include (i) a list of skills, (i) resolvedSkills with the resolved on-disk path to each SKILL.md and its source (e.g., openclaw-bundled), and (i) the generated prompt text that was provided to the model. In practice, we observed that the systemPromptReport prompt-reporting structure may not persist reliably over time. When present, it can ad- ditionally summarize exposed tools by name and provide schema/summary length metrics; however, it does not pre- serve the full tool descriptions as transmitted to the model, nor does it document the concrete implementation behind an exposed tool. The same structure also records injected workspace files, as discussed in Section 5.3.2. Scheduled automation capabilities are defined in cron/jobs.json; each job captures the schedule (one-shot at, fixed-interval every, or cron expression with optional timezone) and how it is executed, along with payload and runtime state. These definitions reveal what autonomous actions the agent was configured to perform. Run history for these jobs is analyzed in Section 5.5. 5.2.3. LLM Core and Reasoning A distinguishing feature of agentic AI systems is that the agent’s decision-making is mediated by an LLM whose reasoning process produces forensically recoverable traces. These artifacts have no direct analog in the forensic analysis of traditional, rule-based software. Assistant messages in the transcript additionally record usage metadata—token counts, cost breakdowns, stopReason (e.g., stop or toolUse), and provider-specific data—enabling investigators to quan- tify model utilization per interaction. The LLM model identity—including provider, model version, and thinking level—is recorded in openclaw.json and per session in sessions.json. Mid-session model changes are captured as model_change events in the ses- sion transcript. Reasoning traces appear as thinking content blocks within assistant messages. These chain-of-thought blocks may reveal how the agent interpreted a request, which alternatives it considered, and why it selected a particular tool. 5.2.4. Historical Configuration Historical configurations can be recovered from the configuration backup files (e.g., openclaw.json.bak, openclaw.json.bak.1, ...). These snapshots preserve prior configurations alongside metadata such as meta.lastTouchedAt and meta.lastTouchedVersion, enabling approximate point-in-time reconstruction: the configuration “in effect” for a given time window can be approximated by selecting the most recent backup whose lastTouchedAt precedes that time. Differencing consecutive snapshots further reveals what changed. Because the effective system prompt and capability en- velope may not be stored persistently, investigators should consider complementary sources such as log data. In our analysis, logs contained specific google tool schema snapshot entries that enumerate the tools exposed to the model for a run. While these entries are not explicitly linked to a particular session, they are typically emitted immediately after a run starts and can therefore often be associated with the corresponding session via temporal proximity. As logs are continuous, such snapshots can help identify capabil- ity changes over time and detect orphaned tools that were previously available but have since been removed. Analysts should note that snapshots may be recorded in provider- specific schema formats (e.g., Google tool schema), which can vary across model providers. 5.3. Knowledge Reconstruction Having established the agent’s identity, reasoning en- gine, and capabilities, the investigator next reconstructs what the agent knew. This addresses questions such as: What information had the agent accumulated? What was in its episodic and long-term memory? What context was avail- able to the LLM at the time of the events under investigation? Because an agent’s behavior is shaped not only by its configuration and user input but also by its evolving memory, loaded workspace files, and dynamically available tools, the same request can produce different outcomes at different points in time. The goal is therefore to approximate, as closely as the available evidence allows, the knowledge state that was active during the relevant period. 5.3.1. Episodic and Long-term Memory OpenClaw implements memory primarily as plain Markdown files in the agent workspace. workspace/memory/Y-M-D.md serves as an append-only daily log; updates to this file are triggered by user requests such as “remember this”. At session start, the agent is instructed (via AGENTS.md) to read the two most recent daily PreprintPage 6 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations memory files. The curated MEMORY.md is injected into the system prompt by the platform. OpenClaw can additionally build a vector index over memory files to support semantic retrieval, stored in memory/<agent_id>.sqlite. 5.3.2. Contextual Knowledge at Incident Time A central challenge is reconstructing what the agent knew at a specific point in time. The USER.md file, for instance, contains learned user details such as timezone, active projects, and preferences—information that accumu- lates and evolves as the agent interacts with the user. When present, the systemPromptReport in sessions.json (cf. Section 5.2) may include an injectedWorkspaceFiles list (with name, path, and injected character counts), which helps approximate which workspace and memory files were injected into the model context. However, this structure may not persist reliably, may be missing entirely, or may only reflect the latest recorded state rather than every individual interaction. One complementary approach is to reconstruct historical versions of knowledge files from the session transcript itself. When the agent uses file-manipulation tools such as read, write, or edit, the session JSONL records the invoked op- eration and its payload. This allows investigators to recover prior file contents as last observed or modified by the agent and to build an approximate timeline of context evolution driven by the LLM. However, this approach cannot account for external modifications to injected files that occur out- side the agent’s tool interface (e.g., direct user edits in the workspace). For long-running sessions, investigators should also pay attention to compaction entries in the transcript. These indi- cate where the context window was summarized and mark locations where the agent’s context may have changed. 5.4. Interaction Tracing The investigator next reconstructs the communication between users and the agent. This requires answering: Through which channels could a user interact with the agent? What and when did the user communicate? What information was visible to the user at any given point? Together, these findings establish the human side of the interaction and define the boundary between what was requested and what the user could observe. 5.4.1. Communication Channels Channel configuration is centralized in the channels sec- tion of openclaw.json. It defines, for each supported channel (e.g., Telegram, WhatsApp, Discord), whether the channel is enabled and which access policies apply. BecauseOpenClawuseschannel-specific implementations—for example, the Telegram Bot API for Telegram and the Baileys library for WhatsApp— the resulting artifacts and their storage locations are likewise channel-specific. For Telegram, the bot token is stored directly in openclaw.json, while credentials/telegram-allowFrom.json stores the allowFrom entry used for permission control. For WhatsApp, credentials and auxiliary material (e.g., pre-keys) are stored under credentials/whatsapp/default/. In addition, agents/<id>/sessions/sessions.json can contain per-session channel metadata, such as the current and last channel as well as the last recipient identifier (e.g., telegram:id). sessions.json may optionally record an ori- gin entry that stores the channel in provider and carries channel-specific information, e.g. sender identifier in the from field or a conversation label, which can be correlated to user messages in a transcript file. Log entries from subsystems such as gateway or channel-specific subsystems (e.g., gateway/channels/telegram) document the connection state and operational health of communication channels over time. Furthermore, comparing configuration backups enables approximate historical reconstruction of channel enablement and policy changes. 5.4.2. Message Recovery and Media Within the session JSONL files, user-to-agent messages are indicated by role: user and include the full text content as well as a timestamped event record. For some channels, additional attribution is embedded in message headers. For example, Telegram messages include a structured header inside the stored user message content (e.g., [Telegram <name> (@<handle>) id:<id> <Y-M-D> <H:M> UTC]). When present, it can be parsed to extract channel attribution, sender identity (e.g., display name, user- name, platform-specific user ID), and message timestamp. A platform message identifier appears on a separate line as [message_id: N]. When a user sends media attachments, OpenClaw stores inbound files under ~/.openclaw/media/inbound/ using one of two filename formats: if the channel provides an original file- name, it becomes sanitized_original—uuid.ext; other- wise, only the UUID is used. The extension is determined by MIME type detection. Corresponding session events include a note in the format [media attached: PATH (mime/type) | URL], allowing media files to be linked back to the conversa- tional timeline. 5.4.3. Visibility to the User The transcript also contains assistant-side events (role: assistant) that may contain multiple content types (e.g., tool-related messages, intermediate reasoning, and user- facing text). According to the implementation, for providers that use reasoning tags (e.g., Google Gemini), only content of type text wrapped in <final> tags is forwarded to the user, while internal thinking blocks (wrapped in <think> tags) and tool execution details are not displayed. For providers with native thinking support, this filtering is not enforced. Accordingly, forensic reconstruction should distinguish be- tween the full internal transcript stored on disk and the subset of content that was actually observable to the user. 5.5. Action Reconstruction This phase focuses on the actions the agent performed. The investigator constructs a timeline of tool invocations, file PreprintPage 7 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations operations, network requests, scheduled tasks, and other ex- ecuted actions. Key questions include: What is the timeline of executed actions? Did the agent execute unprompted or autonomous actions? The output of this phase is a factual record of what the agent did and when, without yet attempting to explain why. 5.5.1. Tool Invocations and Effects Tool executions are recorded as paired events in the session JSONL files: toolCall content blocks in assistant messages specify the tool name, a unique call identifier (id), and the arguments; subsequent role: toolResult messages reference this id as toolCallId and contain the output in content, an isError flag, and a timestamp. For shell com- mands (exec tool, an optional details object may include durationMs, exitCode, and status. Log files are an additional source as they contain specific entries for tool start and end that include runId and toolCallId, enabling cross-source correlation. Anti- forensics indicators include tool calls present in logs but ab- sent from the session transcript, which can suggest session- file tampering. 5.5.2. Autonomous and Scheduled Actions Run history for scheduled tasks is appended to cron/runs/<jobId>.jsonl with timestamps and outcomes, en- abling investigators to flag activity that lacks an immediately preceding user request. Each job may be executed either in the main session via an injected system event or in an iso- lated cron:<jobId> run; this distinction determines whether cron-triggered actions appear in the main session transcript or in separate session files. In addition, the agent may autonomously delegate work to subagents. Delegation can be reconstructed from sessions_spawn tool calls (task prompt, child session ID, cleanup policy, token use, and result summary) and from sessions.json, which may record the parent in spawnedBy and reference the child under keys such as agent:main:subagent:<uuid>. If the cleanup policy deletes the entry from sessions.json, the child session transcript often remains on disk, allowing investigators to link parent and child via the recorded session identifiers and to attribute seemingly user-initiated events (role: user) in the subagent transcript to agent-driven spawning. OpenClaw additionally maintains a lightweight registry of spawned subagent runs in subagents/runs.json. It records high-level metadata such as which subagent was spawned for which task and when it started and ended, which can be useful when session records are incomplete. Entries are created when a subagent is spawned and are updated as lifecycle events occur; depending on the configured cleanup policy, they may be removed immediately after completion or retained only temporarily before being swept once their archiveAtMs deadline passes (defaulting to 60 minutes after creation), so their presence (or absence) can itself be an indicator of how the system was configured and operated. 5.6. Attribution Analysis The preceding phases recover evidence about what the agent was, how it reasoned, what it knew, how it com- municated, and what it did. This final phase synthesizes evidence across all areas to address questions of causality and responsibility: Can specific actions be linked to specific user requests? What degree of autonomy was exhibited? What are the limits of the reconstruction? Unlike the evidence-recovery phases, attribution is an interpretive activity: it does not recover new artifacts but reasons about the relationships between artifacts already identified. 5.6.1. Linking Actions to Origins The investigator traces each significant action backward through the session transcript to determine its origin. Did the reasoning trace cite a user message? A memory entry? A cron trigger? Its own prior reasoning? The chain from user request through agent reasoning to tool invocation can often be reconstructed from the sequence of role: user, role: assistant (with thinking blocks), and toolCall/toolResult entries within a session. 5.6.2. Autonomy Assessment Indicators of autonomy are distributed across multiple artifact sources. Cron run history quantifies scheduled ac- tions that occurred without a preceding user message. Sub- agent delegation reveals autonomous task decomposition. Each observed action can be classified on a spectrum: di- rectly instructed by the user, interpretively derived from an ambiguous instruction, autonomously initiated by the agent, or indeterminate. This classification draws on evidence from all preceding phases—the agent’s configuration and reason- ing capabilities, its knowledge context, the communication record, and the action timeline. 5.6.3. Reconstruction Boundaries Several factors limit the completeness of any forensic reconstruction of an agentic AI system. First, the LLM’s rea- soning is only partially observable through thinking traces. Second, the actual context window assembled at inference time is not stored persistently and memory as well as configuration may have changed between the incident and the examination. Lastly, as we will discuss in Section 7, there is an inherent nondeterminism of LLM-based decision- making, so even a complete reconstruction of inputs cannot guarantee a unique explanation for the agent’s behavior. 6. A Forensic Taxonomy for Agentic AI AI agents are notably different from regular rule-based software systems, so there is a need for the research com- munity to provide guidance for analyzing agent-specific components such as context, configuration, execution, LLM interaction, and autonomous scheduling. To address this gap, we structure the findings of our OpenClaw analysis into an Agent Artifact Taxonomy—a functional classification of five artifact planes, each corresponding to a distinct aspect PreprintPage 8 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations Agent Artifact Taxonomy Reasoning & Cognition The Brain — How it thinks Model Identity & Parameters openclaw.json (model, provider) Reasoning Traces thinking blocks in SessionId.jsonl Identity & Configuration The DNA — What it is / could do Core Configuration openclaw.json, openclaw.json.bak* Persona & System Prompt SOUL.md, AGENTS.md Capability Manifests TOOLS.md, workspace/skills/ Credentials & Permissions auth-profiles.json Knowledge & Recall The Memory — What it knows Episodic Memory workspace/memory/- Y-M-D.md Long-term Memory MEMORY.md User Profile USER.md Semantic Index memory/agent_id.sqlite Communication & I/O The Ears & Mouth — How info flows Channel Configuration credentials/telegram- allowFrom.json Companion Devices devices/, identity/ Messages & Dialogue user/assistant messages in SessionId.jsonl Exchanged Media media/inbound/ Actions & Effects The Hands — What it did Tool Invocations toolCall/toolResult in SessionId.jsonl Scheduled Tasks cron/jobs.json, cron/runs/ Subagent Delegation subagents/runs.json Runtime Logs /tmp/openclaw/*.log Session transcripts (.jsonl) are cross-cutting and contribute direct or indirect evidence to multiple planes. Figure 2: Agent Artifact Taxonomy for forensic analysis of agentic AI systems. The taxonomy organizes agent-related evidence into five planes, each corresponding to a distinct aspect of the agent’s architecture. Session transcripts are cross-cutting and contribute direct or indirect evidence to multiple planes. Representative OpenClaw artifacts are listed as examples. of the agent’s architecture. The taxonomy was developed through a combination of literature review on agentic system architectures, code analysis as well as differential analysis, and validated against the abstract agent interaction loop described in Section 2.1. 6.1. Five Artifact Planes Just as one might examine attributes indicating a sus- pect’s intent with the cognitive processes, their inherent characteristics, their knowledge, their communications, and their actions, the five planes capture analogous aspects of an AI agent. Figure 2 provides an overview with representative artifacts; we briefly introduce each plane below. Reasoning & Cognition (“The Brain”): How the agent thinks. Captures the LLM’s reasoning traces—a category of forensic evidence with no analog in traditional software and the closest approximation to reconstructing agent intent. Identity & Configuration (“The DNA”): What the agent is and what it could do. Encompasses the predom- inantly static artifacts that define the agent’s configured identity, capabilities, and operational boundaries. Knowledge & Recall (“The Memory”): What the agent knows. Covers accumulated knowledge such as episodic memory, user profiles, and semantic indices—distinguished from DNA by being accumulated at runtime, often by the agent itself. Communication & I/O (“The Ears & Mouth”): How information flows to and from the agent. Establishes who interacted with the agent, through which channels, and what each party could observe. Actions & Effects (“The Hands”): What the agent did. Records concrete actions and their observable effects, providing the factual basis for determining what changes the agent caused. The planes represent analytical perspectives rather than isolated subsystems, and individual artifacts may participate in multiple planes depending on investigative context. In par- ticular, session transcripts are inherently multi-planar: a sin- gle JSONL file directly records reasoning traces (Brain), user and agent messages (Ears & Mouth), and tool invocations (Hands), while additionally containing indirect evidence for the DNA and Memory planes. 6.2. Preliminary Cross-System Assessment The analytical phases applied in Section 5 map closely to these planes, reflecting the modular architecture of agentic AI systems. While the specific artifacts differ across sys- tems, the taxonomy is designed to generalize: any agent that combines an LLM core with persistent configuration, memory, communication interfaces, and tool execution will produce artifacts classifiable into these five planes. For a preliminary validation, we mapped the taxonomy’s five planes against artifacts reported by Walker et al. [23] for the agentic framework AutoGen and by Dragonas et al. [7] for the non-agentic ChatGPT mobile application. All AI- specific artifacts documented in both studies fit within the existing planes without requiring additions, supporting the taxonomy’s structural completeness detailed in Table 2. The mapping reveals a discriminative pattern: the Reasoning & Cognition and Actions & Effects planes are both effectively empty for the non-agentic ChatGPT, while the Identity, Knowledge, and Communication planes are populated— mirroring the architectural distinction between systems that merely use an LLM and those that reason and act via one. AutoGen, despite being a genuine multi-agent framework, shows a similar gap. Grounded in traditional disk, memory, and network forensics, Walker et al. [23] did not consider reasoning traces or structured action records as evidence cat- egories; combined with the deprecation of runtime logging since AutoGen v0.2, this left both the Reasoning and Actions planes without recoverable artifacts. This demonstrates how agent-specific evidence classes can go unexamined without a prescriptive taxonomy that defines which artifact categories PreprintPage 9 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations investigators must consider—ensuring that fundamentally new classes such as reasoning traces are not overlooked. 7. Discussion 7.1. Practical Implications of Our Analysis AI assistants expand the attack and impact surface by mediating high-privilege actions (e.g., filesystem ac- cess, process execution, and network requests) through tool abstractions exposed via asynchronous chat interfaces. Furthermore, the intended autonomy—while beneficial for usability—can increase both the likelihood and severity of unintended or adversarial actions, including data exfiltration, credential misuse, and unsafe system modifications, through prompt injection, malicious inputs, or compromised agent instances. This interaction model weakens real-time human oversight: tool calls may execute without immediate user confirmation, and their side effects remain unnoticed. The autonomous nature introduces a covert communication risk that differs from supervised interactive sessions. This shifts the trust model from visible session oversight to post-hoc audit and enables “silent informant” behavior: an assistant completes a benign task while covertly transmitting under- lying data. 7.2. Limitations of this study During our analysis period, the OpenClaw codebase evolved rapidly. While this is a general phenomenon in dig- ital forensics [22], the fast-paced development style rooted in “vibe coding practices” [16] and the increasing autonomy of machines creating software aggravates the situation and makes OpenClaw a fast moving target for empirical study. Accordingly, we restricted our examination to persistent on-disk artifacts and excluded main memory and network traffic. We also did not assess the durability of this ev- idence over extended periods. Moreover, we focused on core functionality using a set of representative actions and did not consider companion devices. The LLM’s inherent nondeterminism complicated reproducible experiments: de- spite fixing all variables under our control, we could not make OpenClaw behave completely identically across runs. This highlights that agentic systems complicate reproducible analysis compared to traditional, non-agentic software. The proposed taxonomy is inductively derived from our analysis of OpenClaw. A preliminary literature-based cross-mapping against published artifact inventories from two additional studies supports the taxonomy’s structural completeness (Table 2), but hands-on forensic analysis of additional agen- tic systems is needed to fully validate its generalizability. 7.3. The Need for an Agentic AI Investigation Framework Nondeterminism. Our analysis revealed that repeated ex- ecution of identical actions with fixed conditions does not yield identical traces. For example, issuing a reminder re- quest may either create a cron job (in /.openclaw/cron/) or instead modify HEARTBEAT.md, depending on the context en- velope provided to the LLM. We distinguish three sources of nondeterminism: (1) sampling stochasticity: LLM produces different reasoning chains and tool selections for the same prompt; (2) context assembly variability: the dynamically constructed context window incorporating evolving memory files and workspace content differs subtly between runs; and (3) timing-dependent external state: responses from third- party services are inherently non-reproducible. Crucially, not all artifacts are equally affected. Structural artifacts, such as configuration files, credential stores, directory layouts, and file creation patterns, remained deterministic across our runs, while LLM-generated content, i.e., reasoning traces, tool-choice sequences, and agent-authored memory entries, exhibited variation. Abstraction. These observations suggest two qualitatively different classes of traces: (i) conventional, deterministic artifacts produced by rule-based software components, and (i) agent-generated artifacts whose creation depends on LLM-mediated planning and tool choice. The latter class has important implications for reconstruction and attribution, because the same high-level intent can be realized through different execution paths and, consequently, different local traces, which can be conceptualized as an additional abstrac- tion layer [3] in trace creation. Challenges in Context Reconstruction. Our experi- ments showed that it is highly relevant to determine which context was available to LLM at what point in time. Since the workspace environment, memory, and capabilities naturally evolve and change over time, this is difficult to determine. The correlation of modified timestamps of the context- providing files in the workspace or memory directory might give an indication but cannot provide the full picture either since many relevant parameters are difficult to determine retrospectively. Generally, we see the need for clear guidance on the approach; our taxonomy proposal in Section 6 may provide a viable foundation, but it still requires further development. 8. Conclusion Agentic AI systems are becoming a durable part of the software ecosystem. As they increasingly act on behalf of users, they will reshape digital processes and become a con- sequential object of digital investigations. At the same time, their delegated and context-dependent execution challenges long-standing forensic assumptions about reproducibility, provenance, and the completeness of local traces. In this work, we analyzed OpenClaw as the first widely used personal AI assistant. We combined an architectural perspective with static code analysis and differential forensic analysis to identify recoverable on-disk traces and to relate these traces to agent-relevant investigative questions, for which we provide an analysis tool as open-source software. We further generalized our observations by proposing an artifact taxonomy with five planes: reasoning and cogni- tion, configuration, memory and knowledge, action and PreprintPage 10 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations execution, and human interaction—to structure investiga- tions of agentic assistants. Our findings also highlight why agentic systems cannot be approached like traditional soft- ware. First, agentic execution introduces nondeterminism: the same user-level request may be realized through different tool choices and different state transitions, producing dif- ferent artifacts. Second, LLMs add an additional layer of abstraction between intent, actions, and observable traces, and third, the relevant context that shaped a decision is difficult to reconstruct retrospectively. Overall, agentic AI shifts the conditions of analysis, compelling a reassessment of long-standing assumptions in a landscape shaped by del- egated agency, autonomy, and model-mediated execution, underscoring the need for sustained, systematic forensic research of agentic systems. Acknowledgements This work was funded by the Walter Benjamin Pro- gram of the DFG (German Research Foundation) under grant number 570978749/GR 6850/1-1 and partially sup- ported by the DFG as part of the Research Training Group 2475 “Cybercrime and Forensic Computing” (grant num- ber 393541319/GRK2475/1-2019). CRediT authorship contribution statement Jan Gruber: Conceptualization, Funding Acquisition, Methodology, Implementation, Investigation, Writing - Original draft, Writing - Review & Editing, Validation, Visualization. Jan-Niclas Hilgert: Conceptualization, In- vestigation, Methodology, Writing - Review & Editing. Use of AI writing assistance The authors used Claude Opus 4.6 and Gemini 3 Pro as writing aids to identify typographical and grammatical issues and to improve the clarity and style of selected pas- sages. All suggestions were critically assessed and, where appropriate, adapted by the authors. References [1] Ali, M.A., Dornaika, F., Charafeddine, J., 2026. Agentic AI: a com- prehensive survey of architectures, applications, and future directions. Artif. Intell. Rev. 59, 11. URL: https://doi.org/10.1007/s10462-025 -11422-4, doi:10.1007/S10462-025-11422-4. [2] Behzadan, V., Baggili, I.M., 2020. Founding the domain of AI forensics, in: Espinoza, H., Hernández-Orallo, J., Chen, X.C., ÓhÉigeartaigh, S.S., Huang, X., Castillo-Effen, M., Mallah, R., Mc- Dermid, J.A. (Eds.), Proceedings of the Workshop on Artificial Intel- ligence Safety, co-located with 34th AAAI Conference on Artificial Intelligence, SafeAI@AAAI 2020, New York City, NY, USA, Febru- ary 7, 2020, CEUR-WS.org. p. 31–35. URL: https://ceur-ws.org/ Vol-2560/paper53.pdf. [3] Carrier, B.D., 2003. Defining digital forensic examination and analysis tool using abstraction layers. Int. J. Digit. EVid. 1. [4] Chernyshev, M., Baig, Z.A., Doss, R.R.M., 2024. Towards large language model (LLM) forensics using llm-based invocation log analysis, in: Li, B., Xu, W., Chen, J., Zhang, Y., Xue, J., Wang, S., Bai, G., Yuan, X. (Eds.), Proceedings of the 1st ACM Workshop on Large AI Systems and Models with Privacy and Safety Analysis, LAMPS 2024, Salt Lake City, UT, USA, October 14-18, 2024, ACM. p. 89–96. URL: https://doi.org/10.1145/3689217.3690616, doi:10.1145/3689217.3690616. [5] Chung, H., Park, J., Lee, S., 2017. Digital forensic approaches for amazon alexa ecosystem. Digit. Investig. 22 Supplement, S15–S25. URL: https://doi.org/10.1016/j.diin.2017.06.010, doi:10.1016/J.DI IN.2017.06.010. [6] Crasselt, J., Pugliese, G., 2024. Started Off Local, Now We’re in the Cloud: Forensic Examination of the Amazon Echo Show 15 Smart Display, in: Proceedings of the Digital Forensics Research Conference Europe (DFRWS USA), dfrws.org, Baton Rouge, Louisiana. p. 1–11. doi:10.48550/ARXIV.2408.15768. [7] Dragonas, E., Lambrinoudakis, C., Nakoutis, P., 2024. Forensic analysis of openai’s chatgpt mobile application. Forensic Sci. Int. Digit. Investig. 50, 301801. URL: https://doi.org/10.1016/j.fsidi. 2024.301801, doi:10.1016/J.FSIDI.2024.301801. [8] Fähndrich, J., Honekamp, W., Povalej, R., Rittelmeier, H., Berner, S., Labudde, D., 2023. Digital forensics and strong AI: A structured literature review. Forensic Sci. Int. Digit. Investig. 46, 301617. URL: https://doi.org/10.1016/j.fsidi.2023.301617, doi:10.1016/J.FSIDI. 2023.301617. [9] Garfinkel, S.L., 2009. Automating disk forensic processing with sleuthkit, XML and python, in: Fourth International IEEE Workshop on Systematic Approaches to Digital Forensic Engineering, SADFE 2009, Berkeley, California, USA, May 21, 2009, IEEE Computer Society. p. 73–84. URL: https://doi.org/10.1109/SADFE.2009.12, doi:10.1109/SADFE.2009.12. [10] Garfinkel, S.L., 2012. Digital forensics XML and the DFXML toolset. Digit. Investig. 8, 161–174. URL: https://doi.org/10.1016/j.diin.2 011.11.002, doi:10.1016/J.DIIN.2011.11.002. [11] Garfinkel, S.L., Nelson, A.J., Young, J., 2012. A general strategy for differential forensic analysis. Digit. Investig. 9, S50–S59. URL: https://doi.org/10.1016/j.diin.2012.05.003, doi:10.1016/J.DIIN.2 012.05.003. [12] Huang, K., Huang, J., 2025. AI Agent Tools and Frameworks. Springer Nature Switzerland. p. 23–50. URL: http://dx.doi.org /10.1007/978-3-031-90026-6_2, doi:10.1007/978-3-031-90026-6_2. [13] Huang, K., Hughes, C., 2025. Introduction to Agentic AI: Founda- tions, Drivers, and Risks. Springer Nature Switzerland. p. 3–16. URL: http://dx.doi.org/10.1007/978-3-032-02130-4_1, doi:10.1007/978-3 -032-02130-4_1. [14] Kälber, S., Dewald, A., Freiling, F.C., 2013. Forensic application- fingerprinting based on file system metadata, in: Morgenstern, H., Ehlert, R., Freiling, F.C., Frings, S., Göbel, O., Günther, D., Kiltz, S., Nedon, J., Schadt, D. (Eds.), Seventh International Conference on IT Security Incident Management and IT Forensics, IMF 2013, Nuremberg, Germany, March 12-14, 2013, IEEE Computer Society. p. 98–112. URL: https://doi.org/10.1109/IMF.2013.20, doi:10.1109/IMF.2013.20. [15] Lazer, S.J., Aryal, K., Gupta, M., Bertino, E., 2026. A survey of agentic ai and cybersecurity: Challenges, opportunities and use- case prototypes. URL: https://arxiv.org/abs/2601.05293, arXiv:2601.05293. [16] Meske, C., Hermanns, T., von der Weiden, E., Loser, K., Berger, T., 2025. Vibe coding as a reconfiguration of intent mediation in software development: Definition, implications, and research agenda. IEEE Access 13, 213242–213259. URL: https://doi.org/10.1109/ACCESS .2025.3645466, doi:10.1109/ACCESS.2025.3645466. [17] Metz, J., 2025. Digital forensics artifacts repository documentation. https://github.com/ForensicArtifacts/artifacts. URL: https: //artifacts.readthedocs.io/en/latest/. accessed: 2026-02-03. [18] Pati, A.K., 2025. Agentic AI: A comprehensive survey of tech- nologies, applications, and societal implications. IEEE Access 13, 151824–151837. URL: https://doi.org/10.1109/ACCESS.2025.358560 9, doi:10.1109/ACCESS.2025.3585609. [19] Sapkota, R., Roumeliotis, K.I., Karkee, M., 2026. AI agents vs. agentic AI: A conceptual taxonomy, applications and challenges. Inf. PreprintPage 11 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations Fusion 126, 103599. URL: https://doi.org/10.1016/j.inffus.2025. 103599, doi:10.1016/J.INFFUS.2025.103599. [20] Scanlon, M., Breitinger, F., Hargreaves, C., Hilgert, J.N., Sheppard, J., 2023. Chatgpt for digital forensic investigation: The good, the bad, and the unknown. Forensic Science International: Digital Investigation 46, 301609. URL: https://w.sciencedirect.com/ science/article/pii/S266628172300121X, doi:https://doi.org/10.101 6/j.fsidi.2023.301609. [21] Schneider, J., Breitinger, F., 2023. Towards AI forensics: Did the artificial intelligence system do it? J. Inf. Secur. Appl. 76, 103517. URL: https://doi.org/10.1016/j.jisa.2023.103517, doi:10.1016/J.JI SA.2023.103517. [22] Spichiger, H., Adelstein, F., 2025. Preserving meaning of evidence from evolving systems. Digit. Investig. 52, 301867. URL: https: //doi.org/10.1016/j.fsidi.2025.301867, doi:10.1016/J.FSIDI.2025.3 01867. [23] Walker, C., Gharaibeh, T., Alsmadi, R., Hall, C.L., Baggili, I.M., 2024. Forensic analysis of artifacts from microsoft’s multi-agent LLM platform autogen, in: Proceedings of the 19th International Conference on Availability, Reliability and Security, ARES 2024, Vienna, Austria, 30 July 2024 - 2 August 2024, ACM. p. 198:1– 198:9. URL: https://doi.org/10.1145/3664476.3670908, doi:10.1145/ 3664476.3670908. [24] Wickramasekara, A., Scanlon, M., 2024. A framework for integrated digital forensic investigation employing autogen ai agents, in: 2024 12th International Symposium on Digital Forensics and Security (ISDFS), p. 01–06. doi:10.1109/ISDFS60797.2024.10527235. A. Application of the Taxonomy to Other Works As a preliminary validation, we applied our taxonomy to two other works dealing with forensic analyses in a restricted LLM or more extensive agentic setting. In addition to the description in Section 6.2, we provide more details of our comparison in a tabular fashion in Table 2. B. Supplementary Material We provide a supplementary repository alongside this paper, containing the machine-readable description of rel- evant forensic artifacts, a Python-based tool to support the forensic analysis of OpenClaw, and documentation of the analysis process in form of the DFXML outputs for our experi- ments. B.1. Artifact Examiner Tool To facilitate the analysis of OpenClaw, we developed the artifact-examiner, a Python-based command-line interface (CLI) tool included in the artifact-examiner/ directory. This tool leverages our analysis results to automatically ingest, parse, and correlate forensic data from an OpenClaw instal- lation. The Artifact Examiner offers several capabilities for investigators: • Unified Timeline Analysis: It reconstructs a chronolog- ical view of all agent activities by merging events from logs, session transcripts, and configuration changes. This allows analysts to trace the sequence of actions leading up to a specific event. • Session Inspection: The tool provides interactive browsers for exploring agent sessions, including the abil- ity to reconstruct conversation flows, tool invocations, and subagent spawns. • Anti-Forensics Detection: By comparing execution logs with persistent session records, the tool can identify discrepancies that may indicate deleted sessions or tam- pered data, highlighting potential anti-forensic activities. Table 2 Literature-based cross-system mapping of the Agent Artifact Taxonomy. ChatGPT mobile is a cloud-native LLM chat interface without agent capabilities per Section 2.1; it is included as an architectural contrast to illustrate the taxonomy’s discriminative scope. Taxonomy PlaneOpenClaw (this work)AutoGen (Walker et al. [23])ChatGPT Mobile (Dragonas et al. [7]) Reasoning & Cognition thinking blocks and model_change events in ses- sion JSONL; reasoning traces with no analog in traditional software No reasoning traces recovered or investigated; transient LLM response fragments in volatile memory but recovery inconsistent across tasks; no chain-of-thought, planning step, or infer- ence parameter artifacts No local reasoning traces (all inference possi- bly server-side); GPT model version recorded in conversation metadata but contains no chain-of-thought or inference parameters Identity & Configuration openclaw.json, persona files (SOUL.md, IDENTITY.md), provider credentials in auth-profiles.json Agent definitions, system prompt, model configuration (llm_config), and code execution settings (work_dir) in Python source scripts; pyautogen installation footprint in site-packages; API credentials not recovered App preferences (BPLIST on iOS, Protobuf on Android), account/user/device/workspace identifiers, subscription plan, custom instruc- tions, authentication tokens Knowledge & Recall memory.sqlite with vector embeddings, curated MEMORY.md, daily memory logs, USER.md Conversational context session-scoped and volatile only (not persisted to disk); logging deprecated since v0.2; no persistent memory, no user profiles, no semantic indices Conversation SQLite database (Android) and JSON files (iOS); cloud-synced chat history; no persistent agent memory; no local semantic index Communication & I/OMulti-channel transcripts (Telegram, What- sApp), media/inbound/ attachments, channel config in openclaw.json TLS-encrypted PCAP traces of API connec- tions to OpenAI endpoints; inter-agent dia- logue (UserProxyAgent↔ AssistantAgent) not persistently logged; message content encrypted under TLS 1.3 (decryption not attempted) Chat messages in local database and JSON; voice recordings (.m4a); text-to-speech narra- tions; uploaded images and files; cloud export archive Actions & Effects toolCall/toolResult pairs in session JSONL, cron/jobs.json and cron/runs/ logs, subagents/runs.json No structured tool invocation logs or agent delegation records recovered; runtime logging deprecated since v0.2 Minimal: DALL-E image generation among tested actions but no dedicated artifact beyond conversation record; no local tool execution, no scheduled tasks, no autonomous actions PreprintPage 12 of 13 Gruber & Hilgert / Foundations for Agentic AI Investigations • Capability Analysis: It tracks the evolution of the agent’s capabilities over time, such as changes in avail- able tools, models, and permissions, providing insight into the agent’s potential impact on the system. Refer to the repository for a comprehensive listing of its capabilities. During our own analyses, we noted that the artifact-examiner significantly reduces the manual effort required to analyze human interaction and agent behavior, while ensuring a consistent and reproducible investigation process. B.2. Forensic Artifact Definition We provide a technical and concise description of foren- sic artifacts via the artifacts/data/openclaw.yml file fol- lowing the specification of the Digital Forensics Artifacts Repository [17]. This YAML file serves as a machine- readable schema that defines the location, structure, and semantic meaning of important artifacts generated by the OpenClaw agent. Each artifact entry includes: • Name: A unique identifier for the artifact (e.g., LinuxOpenClawSessionTranscriptJsonl, LinuxOpenClawDailyJsonLogFiles). • Documentation: A brief description of the artifact’s purpose, content, and forensic significance. This doc- umentation is embedded directly within the schema to ensure it remains synchronized with the implementation. • Sources: The file paths or glob patterns where the artifact can be found on the target system (e.g., ~/.openclaw/sessions/*.jsonl). We aim to enable both human analysts and automated tools to reliably locate and interpret forensic data of Open- Claw. B.3. Experimental Methodology The artifact documentation within the artifacts/ direc- tory was informed through a controlled series of experiments designed to isolate file system changes associated with spe- cific user and agent actions. The methodology involved the following steps: 1. Baseline Establishment: A clean virtual machine (VM) snapshot was created with the base operating system and necessary dependencies but without the OpenClaw agent installed. 2. Action Execution: Specific actions were performed in a sequential manner, such as installing the agent, onboard- ing, sending text and voice messages, adding calendar events, and spawning subagents. 3. Differential Analysis: After each action, the VM state was captured, and a differential analysis was performed against the previous state to identify created, modified, or deleted files. B.4. Availability The supplementary material, including the analysis tool artifact-examiner, the openclaw.yml schema, and the differ- ential analysis, is published at: https://github.com/jgru/forensic-analysis-of-openclaw Artifacts have been redacted where necessary to remove sensitive personal information. PreprintPage 13 of 13