Paper deep dive
ASTELD: A Six-Axis Classification Framework for Autonomous AI Agents - Design, Evaluation, and an OpenClaw Case Study
Siyuan Li, Peng Shu, Churan Yu, Peilong Wang, Ruidong Zhang, Bowen Guo, Xinliang Li, Ruiyu Yan, Arif Hassan Zidan, Yi Pan, Wei Ruan, Lifeng Chen, Junhao Chen, Zhaojun Ding, Yiwei Li, Zhengliang Liu, Haixing Dai, Lin Zhao, Yu Bao, Xiang Li, Wei Zhang, Tianming Liu
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/8/2026, 2:19:04 AM
Summary
The paper introduces ASTELD, a six-axis classification framework for autonomous AI agents covering Architecture, Security, Tool integration, Execution, Level of autonomy, and Deployment. It evaluates the framework by mapping eight representative platforms and conducting an in-depth case study of OpenClaw, analyzing its architecture, security vulnerabilities (including the ClawHavoc supply chain attack), and derivative ecosystem. The study identifies cross-platform patterns, such as the security-accessibility diagonal and execution-architecture coupling, and highlights an empty design region where local-first deployment meets enterprise-grade security.
Entities (33)
Relation Signals (34)
ASTELD â classifies â Autonomous AI Agents
confidence 98% ¡ We propose ASTELD, an operational six-axis classification framework for autonomous AI agents
ASTELD â hascomponent â Architecture pattern
confidence 95% ¡ ASTELD... Architecture pattern, Security posture, Tool integration model, Execution paradigm, Level of autonomy and human control, and Deployment topology.
ASTELD â hascomponent â Security posture
confidence 95% ¡ ASTELD... Security posture
ASTELD â hascomponent â Tool integration model
confidence 95% ¡ ASTELD... Tool integration model
ASTELD â hascomponent â Level of autonomy and human control
confidence 95% ¡ ASTELD... Level of autonomy and human control
ASTELD â hascomponent â Deployment topology
confidence 95% ¡ ASTELD... Deployment topology
ASTELD â hascomponent â Execution paradigm
confidence 95% ¡ ASTELD... Execution paradigm
OpenClaw â hostedon â GitHub
confidence 95% ¡ most-starred repository on GitHub
OpenClaw â iscasestudyfor â
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Autonomous AI agent platforms differ substantially in architecture, security, tool integration, execution, autonomy, and deployment, yet the field lacks a common classification scheme for comparing these design choices. We propose ASTELD, an operational six-axis classification framework for autonomous AI agents: Architecture pattern, Security posture, Tool integration model, Execution paradigm, Level of autonomy and human control, and Deployment topology. ASTELD is constructed by synthesizing prior agent taxonomies with observable platform properties and explicit category-assignment rules. We evaluate its discriminative and explanatory utility by mapping eight representative frameworks and by using OpenClaw as an in-depth case study. The resulting profiles separate all eight platforms under their dominant configurations and reveal three cross-platform patterns: a security-accessibility diagonal, strong execution-architecture coupling, and capability convergence with persistent architectural differentiation. We further classify 50+ OpenClaw derivatives and find that innovation concentrates on the Security, Execution, and Deployment axes, indicating that ASTELD can explain where ecosystem fragmentation occurs. The OpenClaw case study also supplies a six-category vulnerability taxonomy, evidence from five institutional assessments, and adoption and governance analyses that connect platform coordinates to observed risks. These results position ASTELD as a reproducible method for comparing agent platforms, identifying unoccupied design regions, guiding framework selection, and organizing future empirical research. The analysis also exposes a consequential empty region: none of the evaluated systems combines local-first deployment with enterprise-grade security.
Tags
Links
- Source: https://arxiv.org/abs/2608.05201v1
- Canonical: https://arxiv.org/abs/2608.05201v1
Trouble viewing inline? Open PDF directly â
Full Text
118,089 characters extracted from source content.
Expand or collapse full text
ASTELD: A Six-Axis Classification Framework for Autonomous AI Agents â Design, Evaluation, and an OpenClaw Case Study Siyuan Li 1,9 , Peng Shu 1 , Churan Yu 2 , Peilong Wang 3 , Ruidong Zhang 1 , Bowen Guo 4 , Xinliang Li 1 , Ruiyu Yan 5 , Arif Hassan Zidan 6 , Yi Pan 1 , Wei Ruan 1 , Lifeng Chen 1 , Junhao Chen 1 , Zhaojun Ding 1 , Yiwei Li 1 , Zhengliang Liu 1 , Haixing Dai 7 , Lin Zhao 8 , Yu Bao 4 , Xiang Li 9 , Wei Zhang 6 , and Tianming Liu â1 1 School of Computing, University of Georgia, Athens, GA, USA 2 College of Engineering, University of Georgia, Athens, GA, USA 3 Department of Radiation Oncology, City of Hope National Medical Center, Duarte, CA, USA 4 Department of Graduate Psychology, James Madison University, VA, USA 5 Tandon School of Engineering, New York University, New York, NY, USA 6 School of Computer and Cyber Sciences, Augusta University, Augusta, GA, USA 7 Meta, Menlo Park, CA, USA 8 Department of Biomedical Engineering, New Jersey Institute of Technology, Newark, NJ, USA 9 Department of Radiology, Massachusetts General Hospital and Harvard Medical School, Boston, MA, USA Abstract Autonomous AI agent platforms differ substantially in architecture, security, tool integration, execution, autonomy, and deployment, yet the field lacks a common classification scheme for comparing these design choices. We propose ASTELD, an operational six-axis classification frame- work for autonomous AI agents: Architecture pattern, Security posture, Tool integration model, Execution paradigm, Level of autonomy and human control, and Deployment topology. ASTELD is constructed by synthesizing prior agent taxonomies with observable platform properties and explicit category-assignment rules. We evaluate its discriminative and explanatory utility by mapping eight representative frameworks and by using OpenClaw as an in-depth case study. The resulting profiles separate all eight platforms under their dominant configurations and reveal three cross-platform patterns: a securityâaccessibility diagonal, strong executionâarchitecture coupling, and capability convergence with persistent architectural differentiation. We further classify 50+ OpenClaw derivatives and find that innovation concentrates on the Security, Execution, and Deployment axes, indicating that ASTELD can explain where ecosystem fragmentation occurs. The OpenClaw case study also supplies a six-category vulnerability taxonomy, evidence from five institutional assessments, and adoption and governance analyses that connect platform coordinates to observed risks. These results position ASTELD as a reproducible method for comparing agent platforms, identifying unoccupied design regions, guiding framework selection, and organizing future empirical research. The analysis also exposes a consequential empty region: none of the evaluated systems combines local-first deployment with enterprise-grade security. Keywords: autonomous AI agents; agent classification; ASTELD framework; OpenClaw; agent security; AI agent platforms â Correspondence: tliu@uga.edu 1 arXiv:2608.05201v1 [cs.CR] 5 Aug 2026 Contents 1 Introduction4 2 Background: From Chatbots to Autonomous AI Agents5 2.1 LLM-Based Applications . . . . . . . . . . . . . . . . . . . . . . . . . . .5 2.2 Definition of Autonomous AI Agents . . . . . . . . . . . . . . . . . . . .6 2.3 The Security Implications of the Agent Paradigm . . . . . . . . . . . . .6 3 OpenClaw: Origins and Evolution7 3.1 From Clawdbot to OpenClaw . . . . . . . . . . . . . . . . . . . . . . . .7 3.2 Growth Trajectory and Milestones . . . . . . . . . . . . . . . . . . . . . .7 3.3 Governance Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 3.4 Naming and Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 4 System Architecture10 4.1 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Execution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 The Lethal Trifecta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4 State and Memory Management . . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Deployment Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 Architectural Comparison via ASTELD . . . . . . . . . . . . . . . . . . . 13 4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 Security and Privacy Analysis14 5.1 Vulnerability Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1 Category A: Authentication and Session Trust Abuse . . . . . . . 14 5.1.2 Category B: Approval System Bypass . . . . . . . . . . . . . . . . 15 5.1.3 Category C: Operating System-Specific Escapes . . . . . . . . . . 16 5.1.4 Category D: Prompt Injection . . . . . . . . . . . . . . . . . . . . 16 5.1.5 Category E: Supply Chain Attacks (ClawHavoc) . . . . . . . . . . 17 5.1.6 Category F: Infrastructure Misconfigurations . . . . . . . . . . . . 17 5.2 Attack Chain Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3 Institutional Security Assessments . . . . . . . . . . . . . . . . . . . . . . 18 5.4 Defense Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6 ASTELD: Classification Framework and Empirical Evaluation20 6.1 Problem Setting and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Framework Construction and Evaluation Protocol . . . . . . . . . . . . . 20 6.3 ASTELD Axes and Category Definitions . . . . . . . . . . . . . . . . . . 21 6.4 Framework Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.5 Cross-Cutting Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.6 Comparative Analysis by Dimension . . . . . . . . . . . . . . . . . . . . 24 6.7 Framework Selection Matrix . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2 7 Adoption, Social Impact, and the Derivative Ecosystem26 7.1 Adoption Metrics and Growth Dynamics . . . . . . . . . . . . . . . . . . 27 7.1.1 GitHub Star Growth . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1.2 Comparative Platform Metrics . . . . . . . . . . . . . . . . . . . . 27 7.1.3 Usage and Ecosystem Metrics . . . . . . . . . . . . . . . . . . . . 27 7.1.4 The Adoption Paradox: Stars ̸= Enterprise Adoption . . . . . . . 27 7.2 The Derivative Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.1 Derivative Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.2 Derivative Prediction Power . . . . . . . . . . . . . . . . . . . . . 29 7.3 Social and Regulatory Impact . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.1 The Token Economy . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.2 ClawHub Marketplace Dynamics . . . . . . . . . . . . . . . . . . 30 7.3.3 Regulatory Responses . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.4 Enterprise Adoption Dynamics . . . . . . . . . . . . . . . . . . . 31 7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8 Open Research Questions and Future Directions31 8.1 Architectural Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.2 Security Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.3 Ecosystem Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.4 Sociotechnical Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.5 Meta-Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9 Conclusion35 3 1 Introduction The emergence of autonomous artificial intelligence (AI) agents represents a paradig- matic shift in how humans interact with AI. Unlike chatbots that generate text in response to prompts, autonomous agents decompose goals into subtasks, invoke tools, access file systems, and communicate with external servicesâall with minimal human oversight. This transition from generation to action has profound implications for software engineering, security, and governance. These implications are no longer theoretical. In the span of a few months, a single open-source project, OpenClaw, has made them concrete. Released as a weekend side project in November 2025 under the name Clawdbot, OpenClaw accumulated 60,000 GitHub stars within four days of going viral in late January 2026, surpassed React as the most-starred software project on GitHub by March 3, 2026 with 250,829 stars, and reached 360,000+ stars on GitHub by late April 2026 [1][2][3][4]. In parallel, public trackers documented 100+ tracked advisories and 10+ published CVEs by April 2026, while broader vendor summaries reported larger tallies of tracked vulnerability records under different aggregation rules [5][6]; OpenClaw also suffered a coordinated supply chain attack, ClawHavoc, that ultimately led to the identification of 1,184 malicious skills in its marketplace [7][8]. This is the paradox: the most-starred repository on GitHub is also a case study in security debt. The tensions it reveals are not unique to one project; they are built into the agent paradigm itself. Three such tensions recur throughout this analysis. First, the accessibilityâsecurity trade-off : the design choices that made OpenClaw accessible to non-technical users (a messaging-platform interface, a monolithic daemon with system-level access, a permission- less skill marketplace) are precisely the choices that created its most serious vulnerabilities. Second, the open-source speed paradox: rapid community-driven development outpaced the projectâs capacity to establish security governance, resulting in a 4-day burst in which 9 new security-tracker entries were logged between March 18 and March 21, 2026 [5]. Third, the impossibility of architectural universality: no single agent architecture can simulta- neously optimize for accessibility, security, expressiveness, and enterprise readinessâa finding we demonstrate through systematic cross-framework comparison. Existing studies describe individual agent platforms, compare selected frameworks, or survey security and ecosystem issues [9][10][11][12][13]. What remains missing is an operational classification method that converts heterogeneous platform evidence into comparable coordinates. Without explicit axes and assignment rules, comparisons remain narrative, framework selection is difficult to reproduce, and ecosystem changes cannot be related systematically to the design constraints of a base platform. We formulate the problem as follows: given publicly observable evidence about an autonomous-agent platform, assign a compact profile that captures its dominant design while preserving meaningful configuration ranges. The classification should (i) distinguish platforms with different design commitments, (i) reveal cross-axis regularities and unoc- cupied design regions, and (i) help explain how derivative systems modify the constraints of a base platform. OpenClaw provides a high-information case for this task because its architecture, security incidents, rapid adoption, and unusually large derivative ecosystem expose the consequences of platform design choices at scale. To address this problem, we propose and evaluate ASTELD, a six-axis classification framework covering Architecture, Security, Tool integration, Execution, Level of autonomy and human control, and Deployment. The paper answers three classification questions: 4 whether observable platform properties can be encoded consistently along these axes; whether the resulting profiles discriminate among representative frameworks and expose structural patterns; and whether axis-level constraints help explain the direction of derivative innovation. Specifically, we make five contributions: 1. ASTELD classification method. We introduce a six-axis taxonomy with explicit, observable category definitions for classifying autonomous AI agent platforms. The method supports dominant-value assignments, range-valued profiles, and transition notation when common configurations span categories. 2. Empirical framework evaluation. We operationalize ASTELD on eight repre- sentative platforms and evaluate its discriminative and analytical utility through profile separation, cross-axis pattern analysis, and identification of unoccupied design regions. 3.OpenClaw case evidence. We construct a multi-dimensional evidence base cover- ing OpenClawâs architecture, security, adoption, governance, and ecosystem position. This includes a six-category vulnerability taxonomy synthesized from CVE databases, five institutional assessments (Microsoft [14], CertiK [15], CrowdStrike [16], Trend Micro [17], and Koi Security [8]), and academic research. 4.Derivative-based explanatory analysis. We classify 50+ OpenClaw derivatives across three tiers and test whether observed modifications concentrate on the ASTELD axes that are most constrained in the base platform. The results show concentration on Security, Execution, and Deployment. 5.Research and selection implications. We derive a practitioner selection matrix, identify the local-first plus enterprise-security design gap, and formulate eight research questions spanning architectural, security, ecosystem, and sociotechnical domains. The remainder of this paper is organized as follows. Section 2 establishes the intel- lectual context by tracing the evolution from chatbots to autonomous agents. Section 3 introduces OpenClawâs origins, evolution, and governance transitions. Section 4 provides a technical deep dive into its architecture. Section 5 presents our security and privacy analysis, including the six-category vulnerability taxonomy and attack chain composi- tion. Section 6 positions OpenClaw within the broader AI agent ecosystem through the ASTELD classification framework. Section 7 examines adoption dynamics, social impact, and the derivative ecosystem. Section 8 formulates open research questions and future directions. Finally, Section 9 concludes the work. 2Background: From Chatbots to Autonomous AI Agents 2.1 LLM-Based Applications The development of LLM-based applications can be understood as a progression from standalone text generation, to retrieval- and workflow-enhanced systems, and more recently to autonomous agentic architectures. 5 Text Generation Chatbots. The release of GPT-3 [18] established the paradigm of prompt-in, text-out interaction. Users provided natural language instructions; models returned generated text. Applications included summarization, translation, and question answering. The model had no memory, no tool access, and no ability to take actions in the world. Retrieval-Augmented Systems. Retrieval-Augmented Generation (RAG) extended LLMs by grounding their outputs in external knowledge bases. Frameworks such as LangChain (released October 2022) [19] provided composable abstractions for chaining LLM calls with document retrieval, enabling applications like domain-specific chatbots and enterprise knowledge assistants. The model could now reference external data, but still could not act on the world. Autonomous AI Agents. The agent paradigm represents a qualitative shift: LLMs are no longer endpoints but controllers. An autonomous agent observes its environment, formulates plans, invokes tools (APIs, shell commands, file operations), and iterates until a goal is achieved. AutoGPT, released in March 2023 [20], was the first viral demonstration of this paradigm. The subsequent emergence of multi-agent frameworksâAutoGen [21] for multi-agent conversation, CrewAI [22] for role-based collaboration, LangGraph [19] for stateful graph executionâestablished autonomous agents as a recognized architectural pattern. OpenClaw is significant as it represents a further step in the operationalization of autonomous agents. By combining an LLM controller with system-level OS access, a messaging-platform UI (WhatsApp, Telegram, Discord), and an open plugin marketplace, OpenClaw made autonomous AI agents accessible to non-technical users for the first time [23][24]. This democratization is simultaneously its greatest achievement and its most serious liability. 2.2 Definition of Autonomous AI Agents We adopt the following operational definition, drawing on recent surveys of agentic AI and autonomous agents [25][26][27][28]: An autonomous AI agent is a software system in which a large language model serves as a cognitive controller that (1) maintains persistent state across interactions, (2) formulates multi-step plans to achieve user-specified goals, (3) invokes external tools and services to execute those plans, and (4) operates with a degree of autonomy that permits action without per-step human approval. This definition distinguishes agents from chatbots (which lack tool invocation and persistent state), from RAG systems (which lack planning and action), and from traditional automations (which are not LLM or AI-based). The Interface EU classification [29] further stratifies autonomy into five levels, from L1 (tool mode, every action requires instruction) through L5 (full autonomous operation, no human oversight). As we show in Section 4, OpenClawâs design enables autonomous operations up to L4 (agent decomposes and executes complex goals end-to-end) [14]. 2.3 The Security Implications of the Agent Paradigm The transition from chatbots to agents introduces a fundamentally broader security surface. A useful framing, sometimes described as the âlethal trifecta,â is the combination 6 of (1) access to private data on the userâs device, (2) exposure to untrusted external content from external sources, and (3) the ability to communicate with or act upon external services. When all three conditions hold, prompt injection becomes not merely a content moderation problem but an authorization bypassâa malicious instruction embedded in retrieved content can cause the agent to exfiltrate data, install software, or modify system configurations [14][30][31]. This threat model is not hypothetical. Public reporting on OpenClaw in early 2026 documented a rapidly growing stream of vulnerabilities and abuse cases, including CVE- 2026-25253 (ClawJacked: cross-site WebSocket hijacking, CVSS 8.8) [32] and CVE-2026- 32922 (privilege escalation) [33]. The ClawHavoc campaign demonstrated that supply chain attacks against agent plugin marketplaces can achieve unprecedented scale: Koi Securityâs initial audit identified 341 malicious skills among 2,857 on ClawHub (approximately 12%), and subsequent reporting later placed the total at 1,184 as the investigation widened [7][8]. These incidents are detailed in Section 5. OpenClaw emerged at the inflection point of this transitionâand its trajectory reveals both the promise and the peril of the agent paradigm. 3 OpenClaw: Origins and Evolution 3.1 From Clawdbot to OpenClaw OpenClaw began its life as Clawdbot, a weekend side project created by Austrian developer Peter Steinberger in November 2025 [34]. Steinberger, previously known as the founder of PSPDFKit (a cross-platform PDF SDK company), built Clawdbot as a personal experiment: a daemon process that connected a large language model to the local operating system via messaging platformsâWhatsApp, Telegram, and later Discord and Slack. The original vision was deceptively simple: enable users to interact with their computers through natural language messages sent from their phones [35][36]. In its earliest form, Clawdbot ran as a local process on macOS, accepting instructions via WhatsApp and executing them through shell commands, file operations, and API calls. There was no plugin system, no marketplace, and no multi-user support. The project attracted modest attention in its first two monthsârespectable but unremarkable by open-source standards [1]. The transformation from niche tool to global phenomenon began on January 29, 2026, when the project was rebranded to OpenClaw after a brief interim rename to Moltbot on January 27 following trademark concerns raised by Anthropic. The OpenClaw rebrand coincided with a restructured architecture that included a skill system, a nascent extension marketplace (ClawHub), and support for multiple LLM backends [1]. The timing coincided with a wave of social media attention: within 48 hours, OpenClaw was accumulating stars at a rate of 710 per hourâ17,084 per dayâa velocity without precedent in GitHubâs history [1][2]. By February 2, 2026, within four days of the rebrand, the project had accumulated over 60,000 new stars [1]. 3.2 Growth Trajectory and Milestones The growth of OpenClaw can be divided into four phases, each with distinct dynamics (see Figure 3): 7 Phase 1: Viral Ignition (January 29 â February 2, 2026). The initial burst was driven by technology media coverage and social media amplification. The projectâs appeal was immediate: unlike existing AI agent frameworks that required programming knowledge, OpenClaw could be installed by non-technical users and accessed through familiar messaging interfaces. This four-day window produced 60,000 stars at an average of 15,000 per day [1][2]. Phase 2: Sustained Acceleration (February 2 â March 3, 2026). The viral wave did not follow the typical pattern of rapid decay. Instead, growth sustained at approximately 6,600 stars per day, driven by tutorial content, derivative projects, and enterprise experimentation. By February 24, OpenClaw had crossed 224,000 stars and surpassed the Linux kernel (218,000 stars accumulated over 30 years), becoming one of the most-starred repositories in GitHub history [2][37]. The velocity comparison is instructive: Linux accumulated 100,000 stars in approximately 30 years (20 per day average); React reached 100,000 in approximately 10 years (68 per day); OpenClaw reached 100,000 in 12 daysâa velocity 123 times that of React and 419 times that of Linux [38][37]. Phase 3: China Wave (March 3 â March 24, 2026). After a brief deceleration, OpenClaw experienced a pronounced March reacceleration driven by adoption in China. Traffic from Chinese IP addresses surged by 1,436% month-over-month, propelled by what Chinese media termed the âlobster crazeâ (lĂłngxi Ěa rèchĂĄo, a wordplay on âClawâ) [39][37]. During this phase, OpenClaw surpassed React (243,438 stars accumulated over 10 years) on March 3, 2026, at 250,829 stars, and was officially recognized as the most-starred software project on GitHub on the same day [2]. Growth averaged approximately 4,000 stars per day during this phase, reaching 335,000 by March 24 [1][39]. Phase 4: Stabilization (March 24 â present). Growth decelerated to under 1,000 stars per day, reaching 360,000+ stars on GitHub by late April 2026 [39][37][4]. This phase coincided with increasing media coverage of security vulnerabilities and the disclosure of the ClawHavoc supply chain campaign. The growth trajectory is unusual: rather than following a simple post-viral decay curve, OpenClaw exhibited an abrupt late-January inflection, sustained acceleration through mid-February, and a later March reacceleration associated with Chinese adoption. This pattern suggests that the projectâs growth was not a single viral event but a compounding phenomenon in which each adoption wave created conditions for the next [38]. 3.3 Governance Transitions OpenClawâs governance has undergone three transitions in rapid succession: Solo maintainer (November 2025 â January 2026). In its Clawdbot phase, Steinberger was the sole maintainer, making all architectural and release decisions. Community-governed open source (January â February 2026). The rebrand to OpenClaw coincided with the opening of contributions. The contributor base grew from 1 to 1,800+ contributors by late April 2026 [38][4]. However, the project lacked formal governance structuresâno steering committee, no security response team, and no code review requirements for skill submissions to ClawHub. Foundation transition (February 2026 â present). Steinbergerâs hire by OpenAI in February 2026 [36] created uncertainty about the projectâs independence. In response, a foundation structure was announced to steward the project. Notably, this governance transition coincided with OpenClawâs peak security-disclosure burst: 9 entries were added in a 4-day window (March 18â21, 2026) [5]. Whether the transition affected security 8 Table 1: Timeline of OpenClaw milestones. DateEventDescriptionRef. 2025-11-24Clawdbot launched Peter Steinberger releases personal AI agent as weekend project; macOS-only, WhatsApp interface, Claude backend [34] 2026-01-29Rebranded to Open- Claw Final rebrand after the brief Moltbot interim name; model-agnostic architecture, ClawHub skill marketplace, and multi-platform messaging support debut together [1] 2026-01-30 Peak viral day 710 stars/hour (17,084/day) reported within the first 48 hours after the OpenClaw rebrand [1][2] 2026-02-02 60,000 stars 60K reached within four days post-rebrand; Phase 1 (Viral Ignition) concludes [1] 2026-02-07 ClawHavoc disclosed Koi Security identifies 341 malicious skills among 2,857 on ClawHub (âź12%); subsequent reporting later places the total at 1,184 [7][8] 2026-02-12 190,000 stars 190K in 14 days; NanoClaw, ZeroClaw, PicoClaw, Nanobot forks emerge within a 14-day window [1][38] 2026-02-15Steinberger joins Ope- nAI Creator hired by OpenAI; foundation governance announced for OpenClaw [36] 2026-02-24Surpassed Linux kernel Crosses 224K+ stars and exceeds Linuxâs 218K stars (accumulated over 30 years) [2][37] 2026-03-03 Surpassed React Exceeds Reactâs 243,438 stars (accumulated over 10 years) [2] 2026-03-03 Most-starred repository 250,829 stars; officially the most-starred software project on GitHub [2] 2026-03-18â 21 Peak disclo- sure burst 9 new security-tracker entries logged in 4 days, including critical authentication bypasses [5] 2026-03-24 China wave peak 335K stars; Chinese traffic +1,436% MoM; âlobster crazeâ phenomenon [39][37] Late Apr. 2026 Current360K+ stars on GitHub; 3M+ MAU; 40K+ ClawHub skills; 1,800+ repo contributors [4][39][1] accountability remains unclear; the disclosure spike may reflect increased researcher scrutiny of a high-profile project as much as any governance gap. 3.4 Naming and Identity The projectâs naming history reflects its evolving identity. The original name âClawd- botâ was a portmanteau of âClaudeâ (the Anthropic LLM that served as its initial backend) and âbot.â Following trademark concerns raised by Anthropic, the project was briefly renamed âMoltbotâ on January 27, 2026, before settling on âOpenClawâ on January 29, 2026 [1]. The final rebrand signaled two shifts: the move to model-agnosticism (dropping the Claude-specific reference) and the adoption of âOpenâ to emphasize its open-source nature. The community has subsequently adopted the claw/lobster motif as a cultural identity marker, with derivative projects adopting names like NanoClaw, ZeroClaw, PicoClaw, and Dr. Claw [38]. 3.5 Summary OpenClawâs evolution from a weekend experiment to the most-starred software project in GitHub history occurred in under five months. This trajectory was enabled by three 9 factors: (1) the accessibility of its messaging-platform interface, which lowered the barrier to autonomous AI from developers to general users; (2) the permissiveness of its architecture, which granted the LLM controller system-level OS access; and (3) the openness of its extension ecosystem, which allowed anyone to publish skills with minimal vetting. As we show in the following sections, these same three factors created the conditions for OpenClawâs most serious security vulnerabilities. 4 System Architecture This section provides a technical analysis of OpenClawâs architecture as of version 2026.3 (March 2026), drawing on official documentation [13], source code analysis, and third-party security assessments [14][15][16]. 4.1 Architectural Overview OpenClaw follows a monolithic daemon architecture (ASTELD category A1): a single long-running process that integrates the LLM controller, tool execution engine, skill loader, messaging interface, and local gateway into one TypeScript application. This design stands in contrast to the modular, microservice, or graph-based architectures adopted by competing frameworks (see Section 6). The system comprises five principal componentsâGateway, LLM Controller, Tool Execution Engine, Skill System, and Messaging Interface. Additional subcomponents (Provider Abstraction, Approval System, Persistent State, and Credential Store) are shown in Figure 1 and discussed in Section 5. 1.Gateway: An HTTP/WebSocket server that exposes the agentâs capabilities to local and remote clients. By default, the gateway binds tolocalhoston a dynamically assigned port, but misconfigurations frequently result in binding to0.0.0.0, exposing the agent to the public internet [14][15][16]. 2. LLM Controller: The cognitive core that receives user instructions (via messaging platforms or the gateway), maintains conversational context, formulates plans, and selects tools for execution. OpenClaw supports multiple LLM backendsâincluding Anthropic Claude, OpenAI GPT-4, Google Gemini, and local models via Ollamaâ through a provider abstraction layer shown as a distinct subcomponent in Figure 1 [13]. 3.Tool Execution Engine: Responsible for executing the actions selected by the LLM controller. Tools include shell command execution, file system operations, HTTP requests, and skill invocations. The engine operates with the full privileges of the user account under which the daemon runsâtypically the userâs primary login account [14]. 4.Skill System: An extension mechanism that allows third-party developers to package tool definitions, prompt templates, and execution logic as installable âskills.â Skills are distributed through ClawHub, an open marketplace that had grown to 40,000+ entries by April 2026 [39][1]. The skill system is the primary vector for the supply chain attacks described in Section 5. 5.Messaging Interface: Adapters that connect the daemon to messaging platforms (WhatsApp, Telegram, Discord, Slack). This component is architecturally significant 10 External messaging channels WhatsAppTelegram DiscordSlack Messaging Interface Gateway (HTTP / WebSocket) LLM Controller (Cognitive Core) Provider Abstraction Model backends LLM Providers (Claude / GPT / Gemini) Approval System Tool Execution Engine Skill System (ClawHub) Persistent State (SOUL.md, MEMORY.md) Credential Store ( Ě /.openclaw/) Host Operating System (File System, Shell, Network) OpenClaw daemon monolithic single-process design ASTELD A1 V1 V2 V3V4 V5 Ingress Orchestration Execution State Figure 1: OpenClaw architecture. Red-tinted nodes mark components with documented security issues. V1 denotes gateway exposure via0.0.0.0; V2 approval-bypass CVEs; V3 privileged tool execution; V4 the ClawHub skill attack surface; and V5 plaintext or unencrypted credential storage [14][15][16]. because it means user instructions arrive through channels designed for human-to- human communication, not for machine controlâa design choice with profound security implications [14]. 4.2 Execution Model OpenClaw employs a single-agent sequential execution loop (ASTELD category E1): observeâthinkâactâobserve. The LLM controller receives an instruction, reasons about the appropriate action, invokes a tool, observes the result, and iterates until the goal is achieved or the user intervenes. This execution model has three notable properties: Unbounded iteration. Unlike frameworks that impose step limits or token budgets, 11 OpenClawâs default configuration allows the agent to iterate indefinitely. Combined with system-level tool access, this means a single malicious instruction can trigger an arbitrarily long chain of privileged actions [9]. Approval system. OpenClaw implements a command approval mechanism in which certain actions (e.g., shell commands, file deletions) are presented to the user for confirmation before execution. However, as documented in Section 5, this system suffers from TOCTOU (time-of-check-time-of-use) vulnerabilities: the command displayed to the user may differ from the command actually executed [10][5]. âAllow alwaysâ mode. Users can configure the approval system to automatically approve all actions of a given type. Microsoftâs security assessment found that the majority of users default to this configuration for convenience, effectively operating at autonomy level L4 (delegated autonomy with no per-action oversight) despite the systemâs design for L2 (guided autonomy with approval) [14]. This behavioral patternâusers choosing convenience over securityâis a recurring theme in the security literature on autonomous agents. 4.3 The Lethal Trifecta As introduced in Section 2.3, Microsoftâs security analysis [14][31] identifies a structural property of OpenClawâs architecture that it terms the âlethal trifectaâ: the simultaneous presence of (1) access to private data on the userâs device, (2) exposure to untrusted content from external sources (web pages, emails, documents), and (3) the ability to communicate with and act upon external services. When all three conditions hold, prompt injection transitions from a content moderation problem to an authorization bypass. An attacker who can embed a malicious instruction in a web page, email, or document that the agent processes can cause the agent to: â˘Read and exfiltrate private files (condition 1 enables access, condition 3 enables exfiltration) ⢠Install software or modify system configurations (condition 3 enables action) â˘Persist the attack by modifying the agentâs memory files (SOUL.md, MEMORY.md), ensuring the malicious behavior survives restarts [10][30] This is not a bug in the traditional sense; it is an architectural property. The monolithic daemon design places the LLM controller, which processes both trusted instructions and untrusted content, in the same security domain as the tool execution engine, which has full system privileges. There is no privilege separation, no sandbox boundary, and no formal distinction between instruction and data at the architectural level [14][15]. 4.4 State and Memory Management OpenClaw maintains several forms of persistent state: Conversational memory. The LLM controller maintains a context window of recent interactions. This is ephemeral and bounded by the LLMâs context length. Long-term memory. OpenClaw supports persistent memory through two mecha- nisms: (1) SOUL.md files that define the agentâs personality and behavioral guidelines, and (2) MEMORY.md files that store accumulated knowledge. Both are stored as plaintext 12 Table 2: ASTELD profile of OpenClaw. AxisCategory Description ArchitectureA1Monolithic daemon SecurityS2Reactive, post-hoc patching Tool IntegrationT2Plugin marketplace (ClawHub) ExecutionE1Single-agent sequential loop Level of autonomyL2/L4Designed for L2; users default to L4 DeploymentD1Local-first personal agent Markdown files in the userâs home directory (~/.openclaw/) and are loaded into the LLMâs context at startup [10]. Credential storage. API keys, tokens, and authentication credentials are stored in plaintext in~/.openclaw/openclaw.jsonand environment files. No encryption, no OS keychain integration, and no access controls beyond filesystem permissions [16][33]. The security implications of this state management approach are significant. Because SOUL.md and MEMORY.md are loaded into the LLM context, an attacker who can modify these filesâthrough a prompt injection, a malicious skill, or direct file accessâ can persistently alter the agentâs behavior. This âmemory poisoningâ attack vector is documented in Section 5 and represents one of the most insidious threats to autonomous agent systems [10][30]. 4.5 Deployment Topology OpenClaw is designed as a local-first personal agent (ASTELD category D1): the daemon runs on the userâs device, and the primary interaction occurs through messaging platforms. However, the reality of deployment diverges significantly from the design intent: â˘Approximately 500,000+ instances were reported as internet-facing in late- March 2026 live checks, with 15,000+ directly exploitable via known remote-code- execution paths [40][41]. â˘More than 30,000 exposed instances were observed with material security risks during the same reporting window [41]. â˘The gateway, intended for localhost communication, is frequently exposed to the public internet due to Docker misconfiguration, cloud deployment, or explicit user choice [14]. This gap between designed topology (local-first, personal) and actual topology (internet- exposed, multi-user) is a recurring source of vulnerabilities. The security model assumes a trusted local environment; the deployment reality is an untrusted networked environment. 4.6 Architectural Comparison via ASTELD To contextualize OpenClawâs architectural decisions, we apply the ASTELD classifica- tion framework introduced in this paper (see Section 6 for full framework description and cross-platform comparison). OpenClawâs ASTELD coordinates are: This profile is unique among the eight frameworks analyzed in Section 6. No other framework combines A1 (monolithic) with T2 (marketplace) and D1 (local-first). The combination explains both OpenClawâs distinctive strengthsâsimplicity, accessibility, low 13 setup frictionâand its distinctive vulnerabilitiesâno privilege separation, marketplace as attack surface, local daemon with internet exposure. 4.7 Summary OpenClawâs architecture is a study in trade-offs. The monolithic daemon design enables the simplicity and accessibility that drove viral adoption, but it also creates a security surface that is fundamentally different fromâand more dangerous thanâthat of modular or graph-based frameworks. The lethal trifecta is not a flaw to be patched; it is a consequence of architectural decisions that prioritized user experience over security isolation. As we demonstrate in the next section, the vulnerabilities that follow are largely predictable from this architectural profileârooted in design decisions rather than implementation accidents. 5 Security and Privacy Analysis OpenClawâs security trajectory is unlike that of any prior open-source project. Within five months of its viral breakout, public trackers documented 100+ tracked advisories and 10+ published CVEs, while broader vendor summaries reported larger tallies of tracked vulnerability records under different aggregation rules; these sources also converged on the presence of several critical-severity vulnerabilities (CVSSâĽ9.0), dozens of additional high-severity findings, and a 4-day burst in which 9 new security-tracker entries were logged between March 18 and March 21, 2026 [9][5][6]. At the time of writing, approximately 500,000+ OpenClaw instances had been reported as internet-facing, more than 30,000 were observed with material security risks, and 15,000+ were directly exploitable via known RCE paths [40][41]. This section presents a six-category vulnerability taxonomy synthesized from CVE databases, five institutional security assessments [14][15][16][17][8], and academic re- search [9][10][42]. We then identify four canonical attack chains that compose vulnerabili- ties across categories, and conclude with an assessment of the defense landscape. 5.1 Vulnerability Taxonomy We classify OpenClaw vulnerabilities into six categories based on attack vector, impact, and architectural root cause. The categories are not mutually exclusive: real-world attacks frequently chain vulnerabilities across categories (see Section 5.2). 5.1.1 Category A: Authentication and Session Trust Abuse The architectural root cause is OpenClawâs trust assumption that all localhost con- nections are legitimateâan assumption that does not hold when the gateway is internet- exposed or when browser-based attacks target localhost. Three critical CVEs define this category. CVE-2026-25253 (ClawJacked/ClawBleed, CVSS 8.8) enables a malicious webpage to initiate cross-site WebSocket hijacking against the localhost gateway; because the browserâs Same-Origin Policy does not block WebSocket connections to localhost, and OpenClawâs rate limiter exempts 127.0.0.1, an attacker can brute-force the gateway port and exfiltrate authentication tokens, achieving full agent takeover [32][43]. CVE-2026-22172 (CVSS 9.9) allows a WebSocket client to self-declare 14 Table 3: OpenClaw security vulnerability taxonomy. Cat.Category Name Root CauseRepresentative EvidenceCVSS / Severity Count AAuthentication & Session Trust Abuse Trust-boundary failures; improper scope/token binding in WebSocket-based control paths CVE-2026-25253 (ClawJacked) CVE-2026-22172 (Scope Self-Decl.) CVE-2026-32922 (Pairing Escala- tion) 8.8â9.9 Highâ Crit. 3+ B Approval Sys- tem Bypass Display-time vs. execution-time in- consistency (TOC- TOU analog) CVE-2026-29607 (Allow-Always) CVE-2026-28460 (Line Continua- tion) CVE-2026-34426 (Env Var Injec- tion) CVE-2026-32065 (Token Mismatch) 6.5â8.8 Med.â High 4 C OS-Specific Escapes Shell escaping fail- ures across plat- forms CVE-2026-22179 (macOS cmd subst.) CVE-2026-22176 (Windows .cmd) High 7.8 2 D Prompt Injec- tion No architectural separation of in- structions from data in LLM context Direct, indirect (IDPI/XPIA), mem- ory poisoning, guidance injection, cross-agent propagation â5 sub- types E Supply Chain (ClawHavoc) Unvetted market- place; weak pub- lisher vetting; un- vetted publishing pipeline 1,184 malicious skills identified Trojan/OpenClaw.PolySkill â1,184 skills F Infrastructure Misconfig. Local-dev defaults deployed at internet scale CVE-2026-32018 (No file locking) 500K+ internet-facing instances 15K+ known-RCE exploitable Plaintext credential storage 6.6 â â 3+ Representative evidence items include CVEs where assigned and non-CVE records where the category is documented through tracker entries, marketplace audits, or infrastructure exposure reports. administrative scopes, bypassing authentication entirelyâthe gateway trusts the clientâs scope assertion without verification [5]. CVE-2026-32922 (Critical) enables a single API call to escalate a pairing token into full administrative control with remote code execution capabilities [33]. The common thread is a trust boundary violation: mechanisms designed for trusted local environments are deployed in untrusted networked environments. 5.1.2 Category B: Approval System Bypass OpenClawâs command approval system is its primary human-in-the-loop security mechanismâand it has been bypassed through four distinct CVEs, each exploiting a different inconsistency between the approval display path and the execution path. CVE-2026-29607 exploits the fact that âallow alwaysâ persists at the wrapper command level, not the inner command; an attacker can swap the inner payload after the wrapper has been approved, achieving persistent RCE without re-prompting [5]. CVE-2026- 28460 demonstrates that shell line-continuation characters bypass the command allowlist entirely [5]. CVE-2026-34426 shows that inconsistent environment variable normalization between the approval and execution paths enables environment variable injection without 15 triggering the approval prompt [5]. CVE-2026-32065 (CVSS 5.7) reveals a mismatch between how command tokens are displayed during approval and how they are resolved at execution time [10]. The architectural insight is that the approval system suffers from a class of vulnerability analogous to the TOCTOU (time-of-check-time-of-use) problem in operating system security [10]. The âcheckâ (displaying the command for approval) and the âuseâ (executing the command) operate on different representations of the same action, creating a semantic gap that attackers can exploit. No formal specification of approval correctness exists for any agent system, making this an open research problem (see RQ3, Section 8). 5.1.3 Category C: Operating System-Specific Escapes Platform-specific shell escaping failures create additional attack vectors. CVE-2026- 22179 (High) allows command substitution syntax inside double-quoted strings to bypass the command allowlist on macOS [5]. CVE-2026-22176 (CVSS 7.8) exploits unescaped environment variables in scheduled task.cmdscripts on Windows, where characters such as &, |, and Ë are interpreted as command separators [5]. These vulnerabilities, while platform-specific, illustrate a broader point: OpenClawâs tool execution engine must correctly handle shell semantics across every supported operating systemâa combinatorially complex problem that is intrinsically difficult to solve in a monolithic architecture where the LLM controller generates shell commands directly. 5.1.4 Category D: Prompt Injection Prompt injection in autonomous agents is qualitatively different from prompt injection in chatbots. In a chatbot, a successful injection may cause the model to generate inappropriate text. In an agent with system-level tool access, a successful injection can cause the execution of arbitrary shell commands, the exfiltration of private data, and the persistent modification of the agentâs behavior. We identify five sub-types of prompt injection relevant to OpenClaw: Direct injection: The user types malicious instructions that override the system prompt, causing the agent to execute unintended operations [9]. Indirect injection (IDPI/XPIA): Malicious instructions are embedded in contentâ web pages, emails, documents, MCP tool outputsâthat the agent processes during legitimate task execution. Because the LLM processes instructions and data in the same context window with no architectural separation, the embedded instructions can hijack the agentâs reasoning [10][30][44]. Memory poisoning: An attacker modifies the agentâs persistent memory files (SOUL.md, MEMORY.md) to inject instructions that alter the agentâs behavior. Because these files are loaded into the LLM context at every startup, the injected behavior persists across restarts and may include time-delayed activation triggers [10][30]. This attack vector is unique to agent systems with persistent state and represents one of the most insidious threats identified in the literature. Guidance injection: Attacker-controlled instructions in ClawHub skill descriptions or MCP server tool outputs alter the agentâs reasoning during skill execution. Unlike indirect injection through user data, guidance injection operates through the tool layer itselfâthe agent trusts tool outputs as authoritative, creating a privilege escalation path [45][8]. 16 Cross-agent propagation: In multi-instance deployments or social-agent networks (such as Moltbook), a malicious prompt in shared content can reach multiple agents simultaneously, causing coordinated compromise [13][12]. This vector remains under- studied; only one empirical analysis exists [13], and no formal threat model for agent-to- agent infection has been proposed (see RQ6, Section 8). The key insight, shared by Microsoft [14], CrowdStrike [16], and academic re- searchers [9][10], is that prompt injection in agentic systems is an authorization problem, not a content moderation issue. Tool access is the amplifier: systems without external tool access show minimal successful injection outcomes. The architectural separation of instruction processing from data processing remains unsolved (see RQ1, Section 8). 5.1.5 Category E: Supply Chain Attacks (ClawHavoc) The ClawHavoc campaign, disclosed in February 2026, represents the first large-scale supply chain attack targeting an AI agent skill marketplace [7][45][8]. The campaignâs root cause was ClawHubâs minimal vetting requirement: publishing a skill required only a GitHub account that was one week old. The attack was executed through multiple sub-campaigns. The primary ClawHavoc campaign used fake error messages to trick users into pasting base64-encoded commands that installed Atomic Stealer (AMOS)âmalware that harvests browser credentials, cryp- tocurrency wallets, and system data [7]. The AuthTool sub-campaign deployed dormant payloads activated by specific user prompts, establishing persistent reverse shells [45]. The Hidden Backdoor campaign disguised itself as an Apple Software Update during skill installation, creating an encrypted tunnel to attacker infrastructure [8]. A benign-looking weather assistant skill was found to steal API keys from the .clawdbot/.env file [8]. The scale of the campaign is striking. Koi Securityâs initial audit identified 341 malicious skills among 2,857 total (approximately 12%) [7]. Bitdefenderâs expanded scan found 824+ among 10,700+ skills [45]. Subsequent reporting later placed the total at 1,184 malicious skills, and Koi Security assigned the classification Trojan/OpenClaw.PolySkill [7][8]. A single threat actor (âhightower6euâ) was responsible for 354 of these skills [7]. ClawHavoc established a new threat class: AI agent supply chain attacks through natural language payloads. Unlike traditional software supply chain attacks (e.g., npm, PyPI package poisoning) where malicious code can be detected through static analysis, agent skill poisoning can operate entirely through natural language instructions that the LLM interprets as commands. This makes conventional code scanning tools, including VirusTotal (which OpenClaw adopted post-ClawHavoc), fundamentally insufficient for detection [8][31]. 5.1.6 Category F: Infrastructure Misconfigurations Default configurations designed for local development are routinely deployed at internet scale. The gateway binds to0.0.0.0(exposing all network interfaces) in many deployment configurations; by late March 2026, public reporting described approximately 500,000+ internet-facing instances, more than 30,000 with material security risks, and 15,000+ directly exploitable through known RCE paths [40][41]. API keys and credentials are stored in plaintext in~/.openclaw/openclaw.jsonand.envfiles with no encryption or OS keychain integration [16][33]. Authentication tokens transmitted in URL query parameters are leaked to browser history and server logs [5]. The absence of file locking 17 (CVE-2026-32018, CVSS 6.6) causes concurrent registry operations to produce orphaned containers and inconsistent state [5]. 5.2 Attack Chain Taxonomy Individual vulnerabilities rarely exist in isolation. We identify four canonical attack chains that combine vulnerabilities across the categories defined above. Chain 1: Browser-Initiated Full Takeover. A malicious webpage (Category A: ClawJacked) initiates a WebSocket brute-force against the victimâs localhost gatewayâ exfiltrates the authentication tokenâachieves full agent controlâexecutes arbitrary shell commands. This chain requires only that the victim visits a webpage while OpenClaw is runningâno social engineering, no malware installation, no user interaction beyond the initial page visit [32]. Chain 2: Supply Chain Persistent Compromise. A malicious ClawHub skill (Category E) installs and tampers with persistent instruction files such as SOUL.md or MEMORY.md (Category D: memory poisoning), creating a delayed behavioral backdoor. When the trigger condition is later met, the poisoned memory can steer the agent toward credential exfiltration or attacker-directed command execution; the compromise persists across restarts because the poisoned memory is reloaded at startup [45][8]. Chain 3: Indirect Injection Escalation. A poisoned web page, email, or document (Category D: indirect injection) is ingested by the agent during legitimate task execution âthe embedded instructions override the agentâs reasoningâthe agent exploits an approval bypass (Category B) or executes a shell command directlyâdata is exfiltrated to an attacker-controlled server [10][30]. Chain 4: Cross-Agent Propagation. A poisoned message introduced into a shared feed or Moltbook interaction (Category D: cross-agent exposure) can be processed by multiple agent instances. If those agents are configured to write untrusted content into persistent memory, the same malicious instruction may propagate into separate memory states, creating the potential for repeated unauthorized actions across multiple agents [13]. 5.3 Institutional Security Assessments The convergence of institutional assessments regarding OpenClaw is noteworthy. Five major security organizations independently evaluated the platform and reached remarkably consistent conclusions, suggesting that its vulnerabilities are systemic rather than superficial. Microsoft Security emphasized the risks to host environments, recommending that users avoid deploying OpenClaw with primary work or personal accounts and proposing the use of dedicated virtual machines with non-privileged credentials as a minimum precaution [14]. CertiK identified a fundamental architectural contradiction, characterizing the vulnerability profile as a flaw designed for trusted local use, but deployed at internet scale, and advocated for mobile-OS-style permission declarations for all integrated skills [15]. From a threat-vector perspective, CrowdStrike classified OpenClaw as an AI super agent requiring intensive security scrutiny, warning that its extensive tool access serves as a primary amplifier for prompt injection attacks [16]. Trend Micro focused on enterprise governance, advising Chief Information Security Officers (CISOs) to apply the same level of security rigor to OpenClaw deployments as is standard for production-grade servers [17]. Complementing these views, Koi Security provided critical insights into supply chain 18 integrity, documenting the ClawHavoc activity and the proliferation of malicious skills designed to exploit the platformâs execution model [8]. The institutional consensus is definitive: OpenClawâs security challenges are structural, not incidental. These vulnerabilities are direct consequences of foundational architectural decisionsâspecifically the monolithic daemon design, the unvetted marketplace, plaintext credential storage, and the localhost trust assumptionârather than implementation bugs that can be resolved through isolated patches. 5.4 Defense Landscape The defense landscape spans three tiers of intervention: Tier 1: OpenClawâs own mitigations. Post-disclosure releases addressed several concrete flaws, including the one-click RCE path fixed in version 2026.1.29, later hardening of gateway authentication and localhost handling, and subsequent closures for multiple March-reported attack paths [46][5]. After ClawHavoc, the ecosystem also moved toward malware screening and user reporting for skill submissions [5]. These mitigations are primarily reactive: they reduce exposure to known exploit paths, but do not by themselves eliminate the underlying architectural weaknesses. Tier 2: Community and derivative approaches. NanoClaw adopts per-agent con- tainerized isolation, limiting each agentâs access to explicitly mounted resources [38]. Other derivative or adjacent systems propose stronger guardrails such as owner-governed policy controls, sandboxed execution, and architectural separation between model interpretation and tool invocation [44][38]. Tier 3: Third-party security tools. Third-party defenses aim to monitor and constrain agent behavior at runtime. For example, Prompt Securityâs AI Gateway inspects traffic between AI applications and MCP servers and enforces allow/block policies on risky interactions [44]. Enterprise hardening guidance further recommends container or VM isolation, secrets minimization, memory-file integrity monitoring, and outbound connection monitoring for exfiltration detection [14][16]. However, these defenses mostly reduce exploitability or blast radius rather than removing the deeper failure modes identified in our taxonomy, including localhost trust- boundary violations, approval-time vs. execution-time semantic mismatch, and the lack of reliable separation between instructions and untrusted data in agent context. 5.5 Summary OpenClawâs security landscape reveals a fundamental mismatch between deployment scale and security maturity. The six vulnerability categoriesâauthentication hijack- ing, approval bypass, OS-specific escapes, prompt injection, supply chain attacks, and infrastructure misconfigurationsâare not independent; they compose into multi-stage attack chains that amplify individual vulnerabilities into full system compromise. The institutional consensus, the volume of CVEs, and the architectural analysis all point to the same conclusion: the challenges are systemic, rooted in architectural decisions that cannot be fully remediated through patching alone. As we show in the next section, these challenges are not unique to OpenClaw but are shared, to varying degrees, across the autonomous agent ecosystem. 19 6ASTELD: Classification Framework and Empirical Evaluation This section presents ASTELD as the paperâs primary methodological contribution, specifies its construction and assignment protocol, and evaluates it on eight autonomous AI agent platforms. OpenClaw is then used as the anchor case for connecting classification coordinates to security, adoption, and derivative-ecosystem outcomes. 6.1 Problem Setting and Scope The autonomous AI agent ecosystem has expanded rapidly since AutoGPTâs viral release in March 2023 [20]. By April 2026, eight major open-source frameworks compete across different architectural philosophies, security models, and target use cases: Open- Claw [13], Hermes [47], AutoGPT [20], CrewAI [22], LangGraph [19], n8n [48], Dify [49], and AutoGen/Microsoft Agent Framework [21][50]. These frameworks differ significantly in architecture, tool integration, level-of-autonomy mechanisms, and deployment strategies, making direct comparison challenging. Hermes is especially relevant because it targets the same broad personal-agent space as OpenClaw but shifts the deployment model toward a server-resident D2 profile and emphasizes a built-in learning loop with persistent cross-session memory [47]. While prior work has explored aspects of these systems, there remains a need for a more standardized, multi-dimensional comparison. Prior analyses have provided valuable insights through framework-specific studies [9][10][11], pairwise comparisons [51][52], and practical rankings or benchmarks [53], but they typically focus on specific perspectives or evaluation criteria. To address this need, ASTELD treats platform comparison as a categorical coding problem: observable evidence is mapped to a six-coordinate profile under explicit assignment rules, allowing systems to be compared without reducing them to a single ranking. 6.2 Framework Construction and Evaluation Protocol ASTELD was developed through a four-stage procedure. First, we synthesized di- mensions from prior agent, autonomy, security, and leakage taxonomies and retained dimensions that describe platform-level design rather than task-level performance. Second, candidate axes were screened for observability (values can be assigned from documentation or implementation evidence), discrimination (the axis separates at least two systems), non- redundancy (the axis captures information not subsumed by another axis), and extensibility (new platforms can be added without changing the coordinate system). Third, we defined categorical anchors for each axis and applied a dominant-configuration rule: a platform receives the category that best represents its default or most typical use, while ranges or transition notation are retained when common deployments materially span categories. Fourth, we evaluated the framework at three levels: profile discrimination across eight platforms, structural utility through cross-axis pattern analysis, and explanatory utility through the direction of change observed in 50+ OpenClaw derivatives. The unit of analysis is the platform rather than an individual agent run, application, or optional component. Evidence is drawn from platform documentation, repositories, reported feature sets, and the security and ecosystem sources analyzed in the surrounding case study. ASTELD is therefore an empirical classification framework, not a performance benchmark: it organizes design properties and supports comparative reasoning, but 20 does not claim that a higher category number is universally better or that the observed relationships are causal. 6.3 ASTELD Axes and Category Definitions We propose ASTELD, a six-axis taxonomy for classifying autonomous AI agent platforms, where each axis is defined by observable system properties and assigned using explicit criteria. The name is an acronym for its axes: Architecture pattern, Security posture, Tool integration model, Execution paradigm, Level of autonomy and human control, and Deployment topology. The framework was designed to satisfy four properties: (1) discriminativeâevery axis separates at least two frameworks, and frameworks can be consistently mapped to distinct dominant profiles even when some axes require range-valued entries under common configurations; (2) comprehensiveâthe axes jointly capture key technical, security, and operational properties; (3) empirically groundedâ every axis value is derived from observed framework properties, not theoretical design space; and (4) extensibleâderivatives and future frameworks can be positioned without restructuring the taxonomy. ASTELD builds upon and extends six prior taxonomies identified in the literature, each of which addresses a subset of the classification problem: Sapkota et al.âs conceptual distinction between AI agents and agentic AI [28], the six-component agent anatomy of V et al. [25], Abou Ali et al.âs dual-paradigm framework [54], Interface EUâs five-level autonomy classification [29], Piccialli et al.âs industry-focused autonomy progression [55], and the Frontiers data leakage taxonomy [56]. The six axes are defined as categorical dimensions. Each framework is assigned a dominant value per axis where possible; when common real-world configurations materially span multiple categories, we retain an explicit range or transition notation rather than forcing an artificial single-value assignment. Axis 1: Architecture Pattern (A). Classifies the structural organization of the agent system into five categories: A1 (Monolithic Daemon)âa single long-running process handling all agent functions; A2 (Visual Workflow)ânode-graph editor as primary interface with execution following a visual DAG; A3 (Composable Library)âagent primitives provided as a library for developer composition; A4 (Graph-Based Runtime)âstateful directed graph with cycles, checkpointing, and replay; A5 (Event-Driven Multi-Agent)â event bus architecture with asynchronous message passing across multiple agents. Axis 2: Security Posture (S). Classifies the maturity of built-in security mecha- nisms, adapted from software security maturity models (BSIMM, OWASP SAMM), into four levels: S1 (Minimal)âno built-in security boundary, relying on OS-level permis- sions; S2 (Reactive)âpost-hoc patches, approval prompts, allowlists; S3 (Framework- Level)âmiddleware permissions, tool-level access control, code execution sandboxing; S4 (Enterprise-Grade)âRBAC, SSO/SAML, audit logging, SIEM integration, air-gapped deployment support. Axis 3: Tool Integration Model (T). Classifies how agents discover and in- voke external tools: T1 (Static Configuration)âtools predefined at setup; T2 (Plugin Marketplace)âinstall-time selection from a curated or open marketplace; T3 (Protocol- Based MCP)âstandardized Model Context Protocol for runtime tool discovery and invocation; T4 (Connector Ecosystem)âlarge library of pre-built connectors in an iPaaS- style model. Axis 4: Execution Paradigm (E). Classifies computation structure: E1 21 Table 4: ASTELD classification of eight autonomous AI agent platforms. Framework ASTELD Stars Primary Use Case OpenClawA1S2T2E1L2/ L4 â D1360K+Personal AI assistant HermesA1S3T3E1L3/ L4 D2117K+Server-resident personal agent AutoGPTA2S2T2 E1â E4 L4D2180K+Autonomous research CrewAIA3S3T3E2L3D4 50K+ Multi-agent collaboration LangGraphA4S3T3E3L2â L3 D3/ D4 30K+ Stateful workflows n8nA2S4T4E4L3D2/ D3 180K+Workflow automation DifyA2S4T3E4L3D2/ D3 130K+Production AI apps AutoGen / MS AF A5S3T4E2L3â L4 D4 50K+ Research collaboration â OpenClaw is designed for L2 (per-action approval), but many users configure âallow always,â effectively operating at L4 (delegated autonomy) [14]. Axis definitions: A = Architecture Pattern, S = Security Posture, T = Tool Integration Model, E = Execution Paradigm, L = Level of autonomy, D = Deployment Topology. Star counts were refreshed from GitHub repository pages in late April 2026 [4][47][20][57][58][59][60][61]. (Single-Agent Loop)âobserve-think-act cycle with sequential execution; E2 (Multi-Agent Conversation)âstructured message exchange among multiple agents; E3 (Stateful Graph Execution)âstate machine with branching, loops, and checkpoints; E4 (Event-Driven Pipeline)âtrigger-node chain with workflow-level parallelism. Axis 5: Level of autonomy and human control (L). Classifies the level of autonomous decision authority and human involvement, adapted from Interface EUâs five-level model [29]: L1 (Tool Mode)âevery action requires explicit user instruction; L2 (Guided Autonomy)âthe agent proposes actions, and a human approves each one; L3 (Bounded Autonomy)âthe agent executes within a predefined scope; L4 (Delegated Autonomy)âthe agent decomposes and executes complex goals end-to-end; L5 (Full Autonomy)âcontinuous operation without human oversight. To avoid conflict with the first Architecture Pattern (A), the sublevels of level of autonomy and human control use the prefix L (Level). Axis 6: Deployment Topology (D). Classifies where the agent runtime executes: D1 (Local-First Personal)âruns on userâs device with local file/system access; D2 (Self- Hosted Server)âruns on user-managed server; D3 (Cloud-Managed)âvendor-hosted agent-as-a-service; D4 (Library-Embedded)âagent logic embedded in userâs application code. 6.4 Framework Mapping Table 4 presents the complete ASTELD mapping for all eight frameworks. Under the dominant-configuration rule, the eight systems receive distinct six-axis profiles, satisfying the frameworkâs basic discrimination criterion for this evaluation set. We acknowledge that some frameworks span multiple categories depending on configu- ration and usage context; assignments reflect their primary design and typical deployment. OpenClawâs level of autonomy carries a notable caveat: the system is designed for L2 22 (a) ASTELD Framework A: Architecture S: SecurityT: Tool Integration E: Execution L: Level of autonomyD: Deployment A1: Mono- lithic Daemon A2: Visual Workflow A3: Compos- able Library A4: Graph Runtime A5: Event- Driven S1: Minimal S2: Reactive S3: Framework- Level S4: Enterprise T1: Static T2: Marketplace T3: MCP T4: Connectors E1: Single-Agent E2: Multi-Agent E3: State- ful Graph E4: Event- Driven L1: Tool L2: Guided L3: Bounded L4: Delegated L5: Full D1: Local D2: Self-Hosted D3: Cloud D4: Embedded (b) Architecture (A) Security (S) Tool Integ. (T) Execution (E) Level of autonomy (L) Deployment (D) 1 2 3 4 OpenClaw n8n CrewAI Security gap Figure 2: ASTELD taxonomy and representative profiles. Panel (a) lists the axes and categories. Panel (b) plots OpenClaw, n8n, and CrewAI. (guided autonomy with per-action approval), but the majority of users configure âallow alwaysâ mode for convenience, effectively operating at L4 (delegated autonomy) with an S2 (reactive) security posture [14]. Hermes shows a related but distinct pattern: it remains architecturally monolithic (A1/E1) yet pushes toward a more server-resident and security-hardened S3/D2 profile through containerized terminal backends, persistent memory, and protocol-based extensibility [47]. These classifications reflect typical usage patterns rather than strictly enforced system constraints. 23 6.5 Cross-Cutting Patterns The ASTELD mapping suggests three structural patterns that extend beyond individ- ual frameworks, based on the configurations summarized in Table 4. Pattern 1: The Security-Accessibility Diagonal. Plotting Security (S) against Deployment (D) across the surveyed frameworks, a general inverse trend can be observed. D1 (local-first) platforms tend to align with S1âS2 (minimal to reactive security), with OpenClaw as a representative example. D2/D3 (server/cloud) platforms are more often associated with S3âS4 (framework to enterprise-level security), as seen in n8n and Dify. D4 (library-embedded) platforms typically correspond to S3 (framework-level security), where responsibility is partially delegated to developers. Notably, none of the surveyed frameworks occupy the combination of D1 + S4 (local- first deployment with enterprise-grade security). While this observation is limited to the current sample, it highlights a potentially underexplored design space. In practice, users seeking locally running personal assistants may encounter more limited security features, whereas systems offering stronger security guarantees are more commonly deployed in server- or cloud-based settings. This trade-off appears in the current ecosystem, though further evidence would be needed to determine whether it reflects a fundamental constraint or a transient design choice. Pattern 2: Execution-Architecture Coupling. Architecture pattern appears closely associated with execution paradigm. For example, A1 (monolithic) systems are typically paired with E1 (single-agent loops), A2 (visual workflow) with E4 (event- driven pipelines), A3 (composable libraries) with E2 (multi-agent interaction), A4 (graph runtimes) with E3 (stateful graph execution), and A5 (event-driven multi-agent systems) also with E2. This alignment suggests that architectural design choices often influence, or co-evolve with, execution models. However, this relationship is empirical rather than strictly deterministic, and alternative pairings may be possible. Pattern 3: Convergence with Persistent Differentiation. Several frameworks exhibit convergence toward a common set of capabilities, including model-agnostic design, support for tool integration protocols (e.g., MCP), visual workflow construction, and human-in-the-loop control mechanisms. At the same time, meaningful architectural differences remain. The ecosystem can be broadly interpreted as forming three functional groupings: personal assistant-oriented systems (e.g., OpenClaw, Hermes), multi-agent orchestration frameworks (e.g., CrewAI, LangGraph, AutoGen), and workflow automation platforms (e.g., n8n, Dify). While these groupings are not mutually exclusive, they reflect typical usage patterns observed in the current landscape. Cross-group competition appears more limited than within-group variation, although this characterization is based on a small set of representative systems [51][47]. 6.6 Comparative Analysis by Dimension Architecture. OpenClawâs monolithic daemon (A1) is distinctive in using messaging platforms as its primary user interface, which may lower the barrier to entry for non- technical users but can introduce additional challenges for enforcing security boundaries. Hermes occupies a nearby architectural niche but relocates the agent to a server-resident D2 deployment with persistent memory, MCP extensibility, and a built-in learning loop, making it a more direct competitor in the personal-agent lane than the workflow- centric or library-centric alternatives [47]. AutoGPT, n8n, and Dify share the visual workflow pattern (A2), although their underlying system designs differ; notably, n8nâs 24 node-based canvas predates AI agent frameworks and originates from general workflow automation [48]. LangGraphâs graph-based runtime (A4) enables expressive control flow, including cycles and stateful execution, but may require greater familiarity with graph-based abstractions [19]. Security. The surveyed frameworks exhibit a range of security capabilities. n8n and Dify provide features such as RBAC, SSO/SAML, audit logging, and support for controlled deployment environments, reflecting their positioning toward enterprise use cases [48][49]. In contrast, OpenClaw is characterized here as S2 (reactive), relying more heavily on post-hoc controls and user configuration. While OpenClaw has a large deployment footprint, this comparison highlights a potential gap between deployment scale and the maturity of built-in security mechanisms. This observation is based on available feature sets and reported configurations rather than a formal security evaluation. Tool Integration. The Model Context Protocol (MCP) is increasingly adopted across frameworks, with several platforms supporting protocol-based tool integration [19][48][49]. OpenClaw follows a T2 (marketplace-based) approach, enabling rapid expansion of available tools. Prior work has noted that marketplace-based ecosystems may introduce risks if contributions are not systematically vetted [7][8]. The observed shift toward protocol-based integration (T3) in some systems may reflect an effort to standardize and better control tool invocation, although both models continue to coexist in practice. Human-in-the-Loop. Human-in-the-loop (HITL) mechanisms vary in granularity and integration. LangGraph provides support for checkpointing, state inspection, and intervention at arbitrary points in execution graphs [19]. n8n supports human inter- vention through workflow nodes, enabling approval steps and user input routing within pipelines [48]. OpenClaw includes an approval-based mechanism intended to gate actions, although its effectiveness depends on user configuration and system context (see Section 5). Overall, HITL support is present across frameworks but differs in depth and flexibility. License and Governance. The surveyed frameworks adopt a range of licensing models. OpenClaw, CrewAI, LangGraph, and AutoGen use permissive MIT licenses, while Dify adopts Apache 2.0. AutoGPT applies a Polyform Shield License to parts of its platform, and n8n uses a fair-code model (Sustainable Use License) alongside commercial offerings. These choices reflect differing approaches to ecosystem growth, monetization, and long-term maintenance. While permissive licenses may facilitate adoption, they do not inherently provide mechanisms for coordinated governance or resource allocation, which may influence sustainability considerations. 6.7 Framework Selection Matrix Based on the comparative analysis, we propose a selection matrix for practitioners: 6.8 Summary The evaluation supports three uses of ASTELD. First, it discriminates among the eight platforms through distinct dominant profiles. Second, it exposes structural relationships that are difficult to state consistently in narrative comparisons, including the securityâ accessibility diagonal and executionâarchitecture coupling. Third, it identifies design gaps, most notably the absence of a D1 + S4 platform in the evaluation set. The framework does not impose a universal ranking: OpenClaw, n8n, and LangGraph optimize different coordinates for different use cases. The sample remains limited and assignments reflect 25 Table 5: Agent-platform selection matrix for practitioners. Use CaseRecommended Rationale Personal AI via messaging OpenClawOnly native WhatsApp/Telegram/Discord integration Multi-agent collabo- ration CrewAIPurpose-built for role-based orchestration; 5.76x faster than LangGraph [51] Complex stateful workflows LangGraphMost expressive graph control flow; best HITL; checkpoint/resume [19] Visual no-code agents n8n or Dify400â600+ integrations; enterprise RBAC/SSO [48][49] Autonomous re- search AutoGPT Pioneer in autonomous task loops; visual workflow builder [20] Enterprise multi- agent MS Agent Framework Azure integration; 1,000+ connectors via Semantic Kernel [50] Maximum securityn8n (self-hosted) or TrustClaw RBAC/SSO/audit/SIEM; or OpenClaw fork with OAuth + sandbox [48][38] December 2026 FebruaryMarchApril 0 100K 200K 300K 60K (Feb. 2) > Linux (Feb. 24) 250.8K (Mar. 3) 335K (Mar. 24) 360K+ (late Apr.) React reference Linux reference Date GitHub Stars OpenClaw Figure 3: OpenClaw GitHub star trajectory with cross-checked milestone anchors. Dashed horizontal lines mark the Linux and React comparison levels used in the text. dominant configurations rather than every optional deployment. The derivative ecosystem examined next provides a separate explanatory test: if ASTELD captures consequential constraints, derivative projects should modify the axes on which the base system is most restricted. 7Adoption, Social Impact, and the Derivative Ecosys- tem OpenClawâs adoption trajectory is unprecedented in open-source history, both in its growth and in the breadth of its social impact. This section examines three interrelated phenomena: quantitative growth dynamics, the sociotechnical implications of mass adop- tion, and the derivative ecosystem that emerged as a response to OpenClawâs architectural constraints. The derivative data serve as an explanatory evaluation of ASTELD: they allow us to test whether ecosystem innovation is concentrated on the axes where the base platform exhibits the clearest limitations. 26 7.1 Adoption Metrics and Growth Dynamics 7.1.1 GitHub Star Growth Figure 3 shows a near-flat pre-viral baseline through December and most of January, a sharp inflection beginning on January 29, sustained high-velocity growth through mid- February, and a later March reacceleration. In terms of the phase definitions introduced in Section 3, the initial growth wave spans Phase 1 (January 29 â February 2) and the early portion of Phase 2, while the March reacceleration corresponds to Phase 3. The velocity comparison underscores the anomaly. OpenClaw reached 100,000 stars in 12 days; React required approximately 10 years (68 stars/day average); the Linux kernel required approximately 30 years (18 stars/day); AutoGPT, the previous fastest-growing AI project, required approximately 6 months [38][62][37]. OpenClawâs 100K-star velocity is 123 times that of React and 419 times that of Linux. The March reacceleration is closely tied to geographic adoption dynamics. Traffic from China surged 1,436% month-over-month during March 2026, propelled by what Chinese media termed the âlobster crazeâ [39][37]. This China-driven growth phase was accompanied by a surge in Chinese-language tutorials and enterprise experimentation (including Tencentâs ClawPro). 7.1.2 Comparative Platform Metrics The geographic distribution of traffic reveals concentrated adoption in three regions: the United States (16.29%), India (12.16%), and China (12.08%, with month-over-month growth of 1,436%), followed by Germany (4.10%, +992% MoM) and Canada (3.53%, +1,259% MoM) [37][63]. 7.1.3 Usage and Ecosystem Metrics Beyond GitHub metrics, OpenClawâs adoption is characterized by the following indi- cators as of April 2026: 3M+ monthly active users; 30M+ website visitors per month; 500,000+ running instances across 80+ countries; approximately 500,000+ internet-facing instances in late-March 2026 live checks, of which 15,000+ were reported as exploitable via known RCE flaws; 40,000+ skills on ClawHub; 1,800+ repository contributors; 2M+ total skill installations; tokens processed via 350+ LLM models; 180+ ecosystem startups with combined monthly revenue exceeding $320,000; and 80+ npm packages dependent on the OpenClaw runtime [39][1][40][41][4]. 7.1.4 The Adoption Paradox: Stars ̸= Enterprise Adoption A critical finding is the disconnect between community popularity and enterprise adoption. LangGraph, with 30,000+ stars, is deployed by 400 companies in productionâ including Cisco, Uber, LinkedIn, BlackRock, and JPMorgan Chaseâand registers 34.5 mil- lion monthly package downloads [19][51][58]. Dify, with 130,000+ stars, serves 280 enter- prises with 1.4 million deployments and a $30 million fundraise [49][60]. OpenClaw, with 360,000+ starsâmore than LangGraph and Dify combinedâhas 180+ ecosystem startups, $320,000 per month in ecosystem revenue, and zero Fortune 500 customers [39][37][1][4]. This paradox illustrates a systematic relationship: GitHub stars correlate with accessi- bility and viral potential, not with production maturity or enterprise trust. Enterprise adopters require security guarantees (RBAC, SSO, audit trails), operational reliability 27 Table 6: OpenClaw derivative ecosystem classification. ProjectTierLang.Created Stars Forks ASTELD / Key Differentiation Tier 1: Community Derivatives Nanobot (HKUDS) Community Python2026-02- 01 37.4K+ 6.5K+ Reduce complexity; compact Python rewrite ZeroClaw Community Rust2026-02- 13 30.6K+ 4.5K+ S2âS3 (memory safety); 8.8 MB binary PicoClaw (Sipeed) Community Go2026-02- 04 28.5K+ 4.1K+ D1 with edge/IoT emphasis NanoClaw Community TypeScript 2026-01- 31 28K+ 12.6K+ Simplify A1 (700 LoC); fork ratio 0.4+ TrustClaw Community TypeScript 2026-02 Private Private S2âS3 (OAuth + sandbox) Tier 2: Enterprise Adaptations Tencent ClawPro Enterprise â2026-03 Private Private A1âA2, S2âS4, D1âD2 QClawEnterprise â2026-03 Private Private WeChat integration; China LLM providers MaxClaw (Minimax) Enterprise â2026-03 Private Private China market optimization Kimi Claw Enterprise â2026-03 Private Private Moonshot AI integration Tier 3: Research Platforms Moltworker ResearchTypeScript 2026-01 9.8K+ 1.8K+ A1âA5, E1âE2 (Cloudflare sandbox deployment) Dr. ClawResearchTypeScript 2026-01 900+90+ A1âA2, E1âE4 (research pipeline) Combined Tier 1 metrics (top 4): roughly 124.5K+ stars and 27.7K+ forks within a 14-day emergence window (Jan 31 â Feb 13, 2026). Community-fork metrics were refreshed from current GitHub repository pages in late April 2026 [64][65][66][67]. Closed-source derivatives are marked as Private; the final-column notes are derived from documentation and feature analysis. (SLAs, support contracts), and regulatory complianceânone of which OpenClaw provides. The ASTELD framework captures this relationship: OpenClawâs S2 security posture is incompatible with enterprise requirements, regardless of its D1 deployment accessibility or its community scale. 7.2 The Derivative Ecosystem The most striking structural phenomenon in OpenClawâs ecosystem is the rapid emergence of derivative projects: over 50 forks, rewrites, and inspired-by projects appeared within three months of OpenClawâs breakout [38]. This fragmentation is not random; it is a systematic response to specific architectural constraints that the ASTELD framework makes legible. 7.2.1 Derivative Taxonomy We classify derivatives into three tiers based on their relationship to the OpenClaw codebase and their target audience. Tier 1: Community Derivatives. Rather than direct modifications of the OpenClaw codebase, the most prominent early derivatives were fresh implementations that re- 28 Security (S) ââ S1S2S3S4 Execution (E) ââ E1 E2 E3 E4 OC OpenClaw 360K+â PC PicoClaw (edge) NB Nanobot (30K LoC) NC NanoClaw (700 LoC) ZC ZeroClaw (Rust) TC TrustClaw (OAuth) QC QClaw CP Tencent ClawPro MW Moltworker DC Dr. Claw Empty quadrant: D1 + S4 + E3/E4 (unsolved design challenge) ⢠OpenClaw (base) ⢠Tier 1: Community forks â˘Tier 2: Enterprise adapta- tions ⢠Tier 3: Research platforms ââ ASTELD shift vector Figure 4: OpenClaw derivative ecosystem on the ASTELD SecurityâExecution plane. Arrows indicate the shift from OpenClawâs base position (S2, E1). expressed OpenClawâs core assistant model in Python, Rust, Go, and TypeScript for different priorities of simplicity, hardware efficiency, portability, and customizability [38]. NanoClawâs current fork ratio is notably anomalous at approximately 0.4+. Combined, the top four community derivatives accumulated roughly 124,500+ stars and 27,700+ forks by late April 2026 [64][65][66][67]. TrustClaw, while community-developed, specifically targets security hardening by adding OAuth and sandboxed execution (S2âS3). Tier 2: Enterprise Adaptations. Commercial or institutional projects that extend OpenClaw for enterprise requirements. Tencentâs ClawPro shifts from A1 to A2 (visual workflow) and S2 to S4 (enterprise RBAC/SSO), targeting Chinese enterprise customers. These projects uniformly shift the Security (S) and Deployment (D) axes toward enterprise- grade values, confirming that OpenClawâs S2/D1 profile is structurally incompatible with enterprise requirements. Tier 3: Research Platforms. Projects that use OpenClaw as a foundation for academic research rather than production deployment. Moltworker shifts from A1 to A5 (multi-agent) and E1 to E2 (multi-agent conversation), enabling research on agent collaboration and delegation. Dr. Claw shifts E1 to E4 (research pipeline workflow), enabling structured experimental workflows. 7.2.2 Derivative Prediction Power The ASTELD framework reveals that derivative shifts are non-random. Three axesâ Security (S), Execution (E), and Deployment (D)âaccount for the vast majority of derivative innovation. No derivative has shifted the Tool Integration axis from T2 to T3/T4 (marketplace to protocol-based), suggesting that the marketplace model is not 29 perceived as the primary constraint by derivative developers, despite its role in ClawHavoc. Similarly, no derivative has shifted the Architecture axis from A1 to A4 (monolithic to graph-based), suggesting that the monolithic daemon pattern is perceived as a feature, not a bug, by the community. This pattern has predictive implications. Future derivatives are most likely to target the Security-Deployment gap identified in Section 6: a local-first agent with enterprise- grade security. The current empty quadrant (D1 + S4) represents the most commercially valuable unsolved design challenge in the autonomous agent space. 7.3 Social and Regulatory Impact 7.3.1 The Token Economy OpenClaw has catalyzed a nascent token economy. As of April 2026, OpenClaw instances are estimated to have collectively processed trillions of tokens across 350+ language models [39]. The 180+ ecosystem startupsâskill developers, hosting providers, integration servicesâgenerate combined monthly revenue exceeding $320,000 [39][37][1]. While modest relative to the broader AI industry ($7.84 billion global AI agent market in 2025, projected to reach $52.62 billion by 2030 at 46.3% CAGR [37][41]), this ecosystem represents the first organic token-mediated economy around an open-source AI agent. 7.3.2 ClawHub Marketplace Dynamics The ClawHub marketplace has grown to 40,000+ skills. However, the security profile is concerning: independent assessment finds 47% of skills assessed as safe, 36% containing prompt injection vectors, 8% attempting data exfiltration, and 6% requesting excessive permissions [39]. The trend is worsening: at the time of the ClawHavoc disclosure in February 2026, approximately 12% of the then-10,700 skills were classified as malicious [7]; by April, 36% of the now-40,000+ skills contain prompt injection [39][1]. Because these two assessments use different classification schemesâbroader unsafe or adversarial characteristics in the former case, versus explicitly malicious skills in the latterâthey are not directly comparable as a single time-series. Even so, taken together, they indicate that marketplace risk is worsening faster than marketplace governance is maturing. Therefore, the governance challengeâenabling permissionless contribution while preventing compromiseâremains the central unsolved problem for agent skill ecosystems (see RQ5, Section 8). 7.3.3 Regulatory Responses OpenClaw has begun to draw governmental attention to autonomous AI agents, though no formal multi-jurisdictional review process has yet been publicly confirmed. The broader regulatory landscape remains uncertain. The EU AI Act classifies AI systems by risk level but does not specifically address autonomous agents with system- level access. The NIST AI Risk Management Framework provides general principles but no agent-specific guidance. No academic analysis has mapped how existing regulatory frameworks apply to the specific capabilities and risks of autonomous AI agents (see RQ7, Section 8). 30 7.3.4 Enterprise Adoption Dynamics The enterprise adoption paradox identified in Section 7.1.4 reflects a broader market dynamic. Gartner projects that 40% of enterprise applications will incorporate AI agents by end of 2026 (up from less than 5% in 2025), and 80% of Fortune 500 companies are exploring agent deployments [37]. Yet this adoption is overwhelmingly concentrated in enterprise-grade frameworks: LangGraph (400 production deployments among named enterprises), Dify (280 enterprises, $30M fundraise), and Microsoft Agent Framework (Azure integration, Semantic Kernel ecosystem) [19][49][50]. OpenClawâs path to enterprise adoption is blocked by structural factors captured in its ASTELD profile: S2 security posture (no RBAC, no SSO, no audit trails), D1 deployment topology (no server-grade deployment option by default), and the ongoing security advisory accumulation (averaging more than one per day) [5]. The derivative ecosystemâs enterprise tier (Tencent ClawPro, QClaw) represents market attempts to bridge this gap, but none has yet achieved the scale of LangGraph or Dify in enterprise settings. 7.4 Summary OpenClawâs adoption metrics are record-setting by every community measure: stars, growth velocity, monthly active users, and ecosystem breadth. Yet the adoption paradoxâ 360,000+ stars but zero Fortune 500 customersâreveals that community scale and enterprise readiness are orthogonal dimensions. The derivative ecosystem, with 50+ projects appearing in three months, is not fragmentation for its own sake but a systematic market response to specific ASTELD-axis constraints. The three most constrained axesâ Security, Execution, and Deploymentâpredict the direction of derivative innovation with remarkable accuracy. The social and regulatory impactsâthe token economy, ClawHubâs worsening security profile, emerging regulatory attention, and the enterprise adoption gapâpoint to fundamental open questions that we formulate in the next section. 8 Open Research Questions and Future Directions The preceding analysis reveals a field in rapid but uneven maturation. The techni- cal capability of autonomous AI agents has advanced ahead of security infrastructure, governance frameworks, and academic analysis. This section formulates eight research questions grounded in the evidence gaps identified throughout this survey, organized by research domain. 8.1 Architectural Research RQ1: Can we design a formally verifiable architecture that enforces a strict separation between instruction channels and data channels in autonomous AI agents, thereby eliminating prompt injection as an authorization vulnerability? As shown in Section 4, OpenClaw adopts a monolithic architecture in which the LLM controller processes both user instructions and untrusted external data within a shared context window, without any privilege separation between reasoning and execution components. Section 5 further demonstrates that this design directly enables multiple classes of prompt injection attacks, including indirect injection, guidance injection, and 31 memory poisoning, all of which exploit the absence of a structural boundary between instruction and data processing. These findings collectively suggest that prompt injection is not an isolated vulnerability, but a direct consequence of architectural design. Existing approaches, such as Energent.aiâs multi-step parsing, attempt partial separation but lack formal verification or formal security guarantees [44]. This motivates the need for a provably secure architectural paradigm that enforces instructionâdata separation at the system level. The relevant formalism may draw on information flow control, capability-based security, or language-theoretic security. RQ2: What is the principled design of a capability-based permission model for AI agent tool ecosystems that balances security, usability, and composabil- ity? As shown in Section 4, OpenClawâs tool execution engine operates with the full privileges of the user account, without any built-in mechanism for permission scoping or isolation. Section 5 further reveals that this unrestricted access is a key enabler of multiple attack vectors, particularly supply chain attacks (Category E) and prompt injection escalations (Category D), where malicious skills or injected instructions can trigger arbitrary system-level actions. The ClawHavoc campaign provides empirical evidence that the absence of a permission model allows large-scale compromise through seemingly benign skill installations. More broadly, these findings indicate that the current implicit full-trust model is fundamentally incompatible with secure agent deployment. CertiK accordingly recommended that skills should declare resource needs upfront, analogous to Androidâs permission model [15]. However, no existing framework implements such a mechanism at the architectural level. The design space includes static declarations at install time, dynamic capability negotiation at runtime, and sandboxed execution with permission escalation. A central challenge is to determine the appropriate permission granularity and enforcement model that can preserve open-source contribution velocity while reducing the risk of systemic compromise. 8.2 Security Research RQ3: How can the correctness of human-in-the-loop approval mechanisms in autonomous agents be formally defined and evaluated, given the observed gap between approval-time representations and execution-time behavior? As shown in Section 5, OpenClawâs approval system has been bypassed through multiple CVEs, each exploiting inconsistencies between the approval-time display of a command and its execution-time resolution. These cases reveal a systematic misalignment between what users approve and what the system ultimately executes. This problem is analogous to time-of-check-to-time-of-use (TOCTOU) vulnerabilities, but arises at a higher abstraction level where the approved entity is a natural language or semi-structured representation of an action, rather than a fully specified program. A key open challenge is to define what constitutes âapproval correctnessâ in such systems and to determine whether it can be formally specified, verified, or empirically evaluated under realistic agent behavior. RQ4: How can AI agent supply chain attacks be detected and mitigated when malicious behavior is encoded in natural language rather than executable code? Section 5 demonstrates that agent supply chain attacks, such as the ClawHavoc 32 campaign, operate through natural language payloads embedded in skill descriptions and execution flows, rather than traditional executable artifacts. As a result, conventional static analysis tools, including VirusTotal, are ineffective in identifying such threats [8][31]. These observations suggest a shift in the nature of supply chain risk, where the LLM itself acts as the interpreter of potentially malicious logic. This raises a fundamental challenge: how to identify and constrain harmful behavior when it is represented as semantically meaningful but syntactically benign text. An open question is what forms of analysisâsemantic, behavioral, or provenance- basedâare sufficient to detect such attacks, and how these approaches can scale with the rapid growth of open agent ecosystems. 8.3 Ecosystem Research RQ5: What governance models can sustain open-source AI agent ecosystems while mitigating systemic supply chain risks at scale? As discussed in Section 6, OpenClawâs plugin-based ecosystem enabled rapid growth but also expanded the attack surface, while its permissive licensing and lack of built-in governance mechanisms provided no structural safeguards against malicious contributions. The ClawHavoc campaign illustrates how such a largely permissionless contribution model can lead to large-scale compromise in agent skill marketplaces. In contrast, tightly controlled ecosystems such as Appleâs App Store significantly reduce supply chain risk through centralized review, but at the cost of reduced openness and developer flexibility. This contrast highlights a fundamental tension between accessibility and security in agent ecosystems. While intermediate approachesâsuch as reputation systems, staged trust models, or automated screeningâhave been explored in other software ecosystems, their applicability and effectiveness in AI agent ecosystems remain unclear. An open question is how gover- nance structures can be designed and evaluated to balance ecosystem growth, developer participation, and systemic security under adversarial conditions. RQ6: How do the architectural choices of single-agent (OpenClaw) ver- sus multi-agent (CrewAI/AutoGen) systems affect fault isolation, security boundary enforcement, and emergent behavior at deployment scale? As discussed in Section 6, the distinction between single-agent and multi-agent archi- tectures is one of the most fundamental design choices in the agent framework landscape, yet their comparative security and reliability properties remain poorly understood. The Moltbook phenomenonâemergent collaborative behaviors among multiple OpenClaw instances communicating through social networks [13][12]âsuggests that multi-agent dynamics can arise even in systems not explicitly designed for them, with unclear im- plications for coordination, fault isolation, and security boundaries. In addition, recent evidence of cross-agent prompt injection propagation indicates that vulnerabilities may spread across interacting agents, but no formal threat model yet exists for such behaviors. This raises an open question of how architectural choices across the single-agent/multi- agent spectrum shape blast radius of compromise, boundary enforcement, emergent coordination, and performance trade-offs in real-world deployments. 33 8.4 Sociotechnical Research RQ7: What factors explain the divergent regulatory responses to au- tonomous AI agents across jurisdictions, and how do existing AI governance frameworks apply to agentic systems? Recent developments suggest growing regulatory attention to autonomous AI agents across multiple jurisdictions, including emerging scrutiny of agent-level system access and data governance concerns. However, as discussed in Section 7, there is limited systematic analysis of how these emerging responses relate to existing AI governance frameworks. While frameworks such as the EU AI Act and the NIST AI Risk Management Frame- work provide general approaches to risk classification and lifecycle governance, it remains unclear how well they capture the specific properties of agentic systems, including system- level access, persistent state, and autonomous multi-step action. This raises an open question of how existing regulatory frameworks can be interpreted, adapted, or extended to address agentic AI, and what factors drive variation in regulatory responses across jurisdictions. RQ8: How can the security risk of autonomous AI agents be systemati- cally characterized and quantified for enterprise adoption decisions, given the absence of standardized benchmarks and the rapid evolution of the threat landscape? As discussed in Section 7, there is a notable gap between community adoption and en- terprise deployment, with highly popular agent platforms lacking corresponding enterprise uptake. This discrepancy is partly attributed to the absence of standardized methods for assessing security and operational risk in agent systems. Existing efforts, such as the Personalized Agent Security Bench (PASB) [42], provide initial evaluation directions, but remain limited in scope and adoption. In practice, enterprise decision-making relies on heterogeneous sources, including vendor claims, security audits, and informal assessments [14][15], resulting in inconsistent and difficult- to-compare evaluations. These observations suggest an open question of how risk in agent systems can be defined, measured, and compared, particularly given their unique characteristics such as persistent state, tool access, natural language attack surfaces, and multi-step execution under dynamic conditions. 8.5 Meta-Observations Three cross-cutting observations emerge from the research questions above: Security failures originate from missing boundaries across abstraction levels. The challenges identified in RQ1âRQ4 collectively point to a common issue: the absence of clear separation between instruction, data, and execution across the agent stack. Whether at the architectural level (RQ1), human-in-the-loop control (RQ3), or ecosystem interfaces (RQ4âRQ5), vulnerabilities arise when control signals and operational effects are not cleanly aligned. This suggests that agent security is fundamentally a problem of boundary definition and enforcement, rather than isolated implementation flaws. Irreducible trade-offs drive ecosystem stratification. The questions raised in RQ5 and RQ6 reflect a deeper tension between openness, flexibility, and security. Empirical evidence from the ecosystem analysis and derivative landscape shows that no single architecture simultaneously satisfies these objectives, leading to the emergence of specialized system tiers. Rather than convergence, the field is undergoing structured 34 fragmentation, implying that future progress depends on interoperability and cross-system guarantees rather than universal design solutions. Adoption is constrained by unresolved sociotechnical alignment. The issues highlighted in RQ7 and RQ8 indicate that technical capability alone is insufficient for widespread deployment. Gaps in governance models, regulatory interpretation, and risk quantification create barriers to enterprise and institutional adoption. This suggests that the long-term trajectory of agent systems will depend on aligning technical design with policy frameworks, organizational practices, and economic incentives. 9 Conclusion This paper introduced ASTELD, a six-axis classification framework for autonomous AI agent platforms, and evaluated it through an eight-framework comparison and an in-depth OpenClaw case study. Rather than treating heterogeneous platforms as an undifferentiated list of capabilities, ASTELD represents each system through Architecture, Security, Tool integration, Execution, Level of autonomy and human control, and Deployment coordinates. Explicit category definitions, a dominant-configuration assignment rule, and range notation make the comparison operational while preserving important configuration variation. The evaluation produced three principal results. First, ASTELD yielded distinct dominant profiles for all eight platforms in the study, demonstrating discrimination within the selected sample. Second, the mapped profiles exposed recurrent structural patterns: a securityâaccessibility diagonal, strong coupling between architecture and execution, and convergence in surface capabilities despite persistent architectural differentiation. Third, analysis of 50+ OpenClaw derivatives showed that modifications concentrate on Security, Execution, and Deploymentâthe axes on which the base platform faces its most visible constraints. This provides case-based evidence that ASTELD is not only descriptive but can organize explanations of ecosystem fragmentation. OpenClaw supplies the empirical depth behind this evaluation. Its monolithic local-first architecture, reactive security posture, marketplace tool model, single-agent loop, and practical shift from guided to delegated autonomy produce a distinctive A1âS2âT2âE1â L2/L4âD1 profile. The architecture, six-category vulnerability taxonomy, institutional security assessments, adoption evidence, and derivative mapping show how those coor- dinates connect to observable outcomes: accessibility, viral growth, security debt, and specialized forks. The framework also identifies an important unoccupied region in the current sample: local-first personal deployment combined with enterprise-grade security (D1 + S4). ASTELD should be interpreted as an empirical classification method rather than a universal score or causal model. Its present evaluation is limited to eight representative frameworks, dominant configurations, and evidence available at the time of analysis. Future work should test coding reliability across independent annotators, expand the platform sample, quantify distances between profiles, and evaluate whether ASTELD coordinates predict security incidents, adoption patterns, or framework-selection outcomes in larger datasets. The central implication is that autonomous-agent platforms are not converging toward a single optimal architecture. Their design space is structured by persistent trade-offs among accessibility, security, expressiveness, autonomy, and deployment control. A common classification coordinate system makes those trade-offs explicit and provides a basis for 35 cumulative comparison, system selection, and future empirical study. As agent platforms continue to evolve, the practical question is not only which system has more capabilities, but which design coordinates produce those capabilities, risks, and governance requirements. ASTELD provides a concrete starting point for answering that question consistently. References [1]OpenClawVPS. OpenClaw statistics 2026: Growth, users, security, and data, 2026. URL https://openclawvps.io/blog/openclaw-statistics. Public metric roundup citing GitHub, Similarweb, npm, and security reporting. [2] Aftab. OpenClaw just beat Reactâs 10-year GitHub record in 60 days, 2026. URL https://medium.com/@aftab001x/openclaw-just-beat-reacts-10-year-github- record-in-60-days-now-nobody-knows-what-to-do-with-it-937b8f370507. [3]OpenClaw Blog. 250,000 stars: OpenClaw surpasses React, 2026. URL https: //openclaws.io/blog/openclaw-250k-stars-milestone. [4]GitHub. openclaw/openclaw, 2026. URL https://github.com/openclaw/openclaw. Repository page accessed April 25, 2026. [5]jgamblin. OpenClawCVEs tracker, 2026. URL https://github.com/jgamblin/OpenCl awCVEs/. GitHub repository tracking all OpenClaw CVEs and advisories. [6]Blink. Openclaw security overview: 138 cves and severity distribution, April 2026. URL https://w.blinkops.com/blog/openclaw-security-overview-138-cves-risk-and- response. Vendor security overview aggregating 138 tracked vulnerability records and severity counts; broader than the manuscriptâs narrower published-CVE count. [7] CyberPress. ClawHavoc poisons OpenClawâs ClawHub with 1,184 malicious skills, 2026. URL https://cyberpress.org/clawhavoc-poisons-openclaws-clawhub-with-1184- malicious-skills/. [8] Koi Security. ClawHavoc: 341 malicious clawed skills found by the bot they were targeting, February 2026. URL https://w.koi.ai/blog/clawhavoc-341-malicious- clawedbot-skills-found-by-the-bot-they-were-targeting. [9] Surada Suwansathit, Yuxuan Zhang, and Guofei Gu. A systematic taxonomy of security vulnerabilities in the OpenClaw ai agent framework. arXiv preprint arXiv:2603.27517, 2026. [10]Zhengyang Shan, Jiayun Xin, Yue Zhang, and Minghui Xu. Donât let the claw grip your hand: A security analysis and defense framework for OpenClaw. arXiv preprint arXiv:2603.10387, 2026. [11]Preprints.org. OpenClaw as language infrastructure: A case-centered survey of a public agent ecosystem in the wild. Preprints.org, 2026. NLP-centered survey using GATE/AERO frameworks on 38 papers. [12] Md Motaleb Hossen Manik and Ge Wang. OpenClaw agents on Moltbook: Risky instruction sharing and norm enforcement in an agent-only social network. arXiv preprint arXiv:2602.02625, 2026. [13]OpenClaw. Agent runtime â OpenClaw official documentation, 2026. URL https: //docs.openclaw.ai/concepts/agent. [14] Microsoft Defender Security Research Team. Running OpenClaw safely: Identity, isolation, and runtime risk, February 2026. URL https://w.microsoft.com/en-us/s 36 ecurity/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/. Microsoft Security Blog. [15] CertiK. OpenClaw security report, March 2026. URL https://w.certik.com/blog/ openclaw-security-report. [16]Elia Zaitsev. What security teams need to know about OpenClaw, the ai super agent, February 2026. URL https://w.crowdstrike.com/en-us/blog/what-security-teams- need-to-know-about-openclaw-ai-super-agent/. CrowdStrike Blog. [17]Fernando Tucci. CISOs in a pinch: A security analysis of OpenClaw, March 2026. URL https://w.trendmicro.com/en_us/research/26/c/cisos-in-a-pinch-a-security- analysis-openclaw.html. Trend Micro Research. [18] Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei. Language models are few-shot learners. Advances in Neural Information Processing Systems, 33:1877â1901, 2020. [19]LangChain Blog. LangChain and LangGraph agent frameworks reach v1.0 milestones, 2025. URL https://blog.langchain.com/langchain-langgraph-1dot0/. [20]GitHub. Significant-Gravitas/AutoGPT, 2026. URL https://github.com/Significant- Gravitas/AutoGPT. Repository page accessed in late April 2026. [21] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang. AutoGen: Enabling next-gen LLM applications via multi-agent conversations. In Proceedings of the First Conference on Language Modeling (COLM), 2024. URL https://openreview.net/forum?id=BAakY1hNKS. Conference version of the AutoGen framework paper. [22] The Agent Times. CrewAI: Multi-agent collaboration, 2026. URL https://theagentti mes.com/articles/44335-stars-and-counting-crewais-github-surge-maps-the-rise-of- the-multi-agent-e. [23]Milvus Blog. What is OpenClaw? complete guide to the open-source ai agent, 2026. URL https://milvus.io/blog/openclaw-formerly-clawdbot-moltbot-explained-a- complete-guide-to-the-autonomous-ai-agent.md. [24] KDnuggets. OpenClaw explained: The free ai agent tool going viral already in 2026, 2026. URL https://w.kdnuggets.com/openclaw-explained-the-free-ai-agent-tool- going-viral-already-in-2026. [25] Arunkumar V, Gangadharan G.R., and Rajkumar Buyya. Agentic artificial intelli- gence (AI): Architectures, taxonomies, and evaluation of large language model agents. arXiv preprint arXiv:2601.12560, 2026. [26]Bin Xu. AI agent systems: Architectures, applications, and evaluation. arXiv preprint arXiv:2601.01743, 2026. [27]Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Jirong Wen. A survey on large language model based autonomous agents. Frontiers of 37 Computer Science, 18:186345, 2024. doi: 10.1007/s11704-024-40231-1. URL https://link.springer.com/article/10.1007/s11704-024-40231-1. [28] Ranjan Sapkota, Konstantinos I. Roumeliotis, and Manoj Karkee. AI agents vs. Agentic AI: A conceptual taxonomy, applications and challenges. Information Fusion, 2025. [29]Interface EU. An autonomy-based classification of ai agents. In NeurIPS 2024 Workshop, 2024. 5-level autonomy classification for policy and liability. [30]Penligent AI. The OpenClaw prompt injection problem: Persistence, tool hijack, 2026. URL https://w.penligent.ai/hackinglabs/the-openclaw-prompt-injection- problem-persistence-tool-hijack-and-the-security-boundary-that-doesnt-exist/. [31] Arnav. Why you cannot prevent prompt injection, 2026. URL https://arnav.au/202 6/04/02/why-you-cannot-prevent-prompt-injection/. [32]Oasis Security Research Team. ClawJacked: OpenClaw vulnerability enables full agent takeover, February 2026. URL https://w.oasis.security/blog/openclaw- vulnerability. [33]ARMO. CVE-2026-32922: Critical privilege escalation in OpenClaw, 2026. URL https://w.armosec.io/blog/cve-2026-32922-openclaw-privilege-escalation-cloud- security/. [34]Wikipedia contributors. OpenClaw â Wikipedia, 2026. URL https://en.wikipedia.o rg/wiki/OpenClaw. Accessed April 2026. [35] Peter Steinberger. OpenClaw, OpenAI and the future, 2026. URL https://steipete .me/posts/2026/openclaw. [36]OpenClaw Blog. OpenClaw creator peter steinberger joins OpenAI, 2026. URL https://openclaws.io/blog/openclaw-creator-joins-openai/. [37] star-history.com. OpenClaw star history, 2026. URL https://w.star-history.com/ openclaw/openclaw. Interactive GitHub star growth visualization. [38] OSS Insight. 116,000 stars in 8 weeks: Four teams rewrote OpenClaw, 2026. URL https://ossinsight.io/blog/the-openclaw-forks-wave-2026. [39]Finn Hillebrandt and Gradually.ai. OpenClaw statistics 2026: Key numbers, data & facts, 2026. URL https://w.gradually.ai/en/openclaw-statistics/. Statistics roundup citing Similarweb, ClawHub, GitHub, and OpenRouter. [40]SecurityScorecard. How exposed openclaw deployments turn agentic ai into an attack surface, February 2026. URL https://securityscorecard.com/blog/how-exposed- openclaw-deployments-turn-agentic-ai-into-an-attack-surface/. STRIKE research on exposed OpenClaw instances and RCE exposure rate. [41]Louis Columbus. Openclaw has 500,000 instances and no enterprise kill switch, March 2026. URL https://venturebeat.com/security/openclaw-500000-instances- no-enterprise-kill-switch/. VentureBeat report citing an RSAC 2026 interview with Cato Networks. [42] Yuhang Wang, Feiming Xu, Zheng Lin, Guangyu He, Yuzhe Huang, Haichang Gao, Zhenxing Niu, Shiguo Lian, and Zhaoxiang Liu. From assistant to double agent: Formalizing and benchmarking attacks on OpenClaw for personalized local ai agent. arXiv preprint arXiv:2602.08412, 2026. Proposes the Personalized Agent Security Bench (PASB). [43]The Hacker News. ClawJacked flaw lets malicious sites hijack local OpenClaw ai 38 agents, 2026. URL https://thehackernews.com/2026/02/clawjacked-flaw-lets- malicious-sites.html. [44] eSecurity Planet. OpenClaw or open door? prompt injection creates ai backdoors, 2026. URL https://w.esecurityplanet.com/threats/openclaw-or-open-door- prompt-injection-creates-ai-backdoors/. [45]Repello AI. ClawHavoc: Inside the supply chain attack that targeted 300,000 ai agent users, 2026. URL https://repello.ai/blog/clawhavoc-supply-chain-attack. [46]OpenClaw Pulse. OpenClaw security guide 2026: Every CVE, exploit and fix, 2026. URL https://openclawpulse.com/openclaw-security-guide-2026/. [47]GitHub. NousResearch/hermes-agent, 2026. URL https://github.com/NousResearc h/hermes-agent. Repository page accessed April 26, 2026. [48] n8n. n8n: Ai workflow automation platform, 2026. URL https://n8n.io/. [49]Dify Blog. Dify: 100k stars on GitHub, 2025. URL https://dify.ai/blog/100k-stars- on-github-thank-you-to-our-amazing-open-source-community. [50]Microsoft Learn. Microsoft agent framework overview, 2026. URL https://learn.micr osoft.com/en-us/agent-framework/overview/agent-framework-overview. [51]Letâs Data Science. Ai agent frameworks 2026: LangGraph vs CrewAI & more, 2026. URL https://letsdatascience.com/blog/ai-agent-frameworks-compared. [52] openclaw-ai.net. OpenClaw vs AutoGPT: Which ai agent framework should you choose, 2026. URL https://openclaw-ai.net/en/blog/openclaw-vs-autogpt. [53]NocoBase. Top 20 ai projects on GitHub 2026: Not just OpenClaw, 2026. URL https://w.nocobase.com/en/blog/best-open-source-ai-projects-github-2026. [54]Hassan Abou Ali et al. Agentic AI: A comprehensive survey of architectures, appli- cations, and future directions. Artificial Intelligence Review, 2025. Dual-paradigm framework (symbolic vs neural); PRISMA review of 90 studies. [55]Francesco Piccialli et al. AgentAI: A comprehensive survey on autonomous agents in distributed ai for industry 4.0. Expert Systems with Applications, 2025. [56] Frontiers in Computer Science. The dark side of autonomous intelligence: Data leakage and privacy failures in agentic AI. Frontiers in Computer Science, 2026. 5-category data leakage taxonomy (memory, tools, planning, inter-agent, feedback). [57]GitHub. crewAIInc/crewAI, 2026. URL https://github.com/crewAIInc/crewAI. Repository page accessed April 25, 2026. [58]GitHub. langchain-ai/langgraph, 2026. URL https://github.com/langchain- ai/langgraph. Repository page accessed April 25, 2026. [59] GitHub. n8n-io/n8n, 2026. URL https://github.com/n8n-io/n8n. Repository page accessed April 25, 2026. [60]GitHub. langgenius/dify, 2026. URL https://github.com/langgenius/dify. Repository page accessed April 25, 2026. [61] GitHub. microsoft/autogen, 2026. URL https://github.com/microsoft/autogen. Repository page accessed in late April 2026. [62]star-history.com. Star history monthly september 2024 | ai agents, 2024. URL https://w.star-history.com/blog/ai-agents/. Blog post published on September 19, 2024. [63] fatjoe. OpenClaw AI Stats 2026: Uses, Users, Market Share, and More, 2026. URL https://fatjoe.com/blog/openclaw-ai-stats/. Statistics roundup published on March 39 11, 2026; includes country traffic share and month-over-month change figures, citing Similarweb for web traffic data. [64] GitHub. HKUDS/NanoBot, 2026. URL https://github.com/HKUDS/NanoBot. Repository page accessed April 25, 2026. [65]GitHub. zeroclaw-labs/zeroclaw, 2026. URL https://github.com/zeroclaw-labs/zer oclaw. Repository page accessed April 25, 2026. [66]GitHub. sipeed/picoclaw, 2026. URL https://github.com/sipeed/picoclaw. Reposi- tory page accessed April 25, 2026. [67]GitHub. qwibitai/nanoclaw, 2026. URL https://github.com/qwibitai/nanoclaw. Repository page accessed April 25, 2026. 40