The paper’s practical point is that autonomous agent security cannot be bolted on after adoption. Once an agent can use tools, touch files, run code, install skills, and act through messaging channels, security becomes part of the product architecture itself.

Source note: 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, and Tianming Liu. “The Rise of Autonomous AI Agents: A Comprehensive Survey of OpenClaw — Architecture, Security, Ecosystem, and Beyond.” 2026 preprint. https://www.researchgate.net/profile/Siyuan-Li-112/publication/404248344_The_Rise_of_Autonomous_AI_Agents_A_Comprehensive_Survey_of_OpenClaw_-_Architecture_Security_Ecosystem_and_Beyond/links/69f02eeddb00ec75d02e08d9/The-Rise-of-Autonomous-AI-Agents-A-Comprehensive-Survey-of-OpenClaw-Architecture-Security-Ecosystem-and-Beyond.pdf

Why This Paper Matters

Most conversations about autonomous agents still treat security as a checklist: add approvals, sandbox the shell, scan plugins, redact secrets, warn the user before dangerous actions.

This survey argues that the checklist view is too small. The moment an agent becomes useful, it also becomes embedded in a messy operating environment: local files, credentials, browsers, messaging platforms, APIs, plugins, memory, scheduled jobs, and human trust. A vulnerability in that world is rarely just a bug. It is often the result of a product choice.

OpenClaw is the paper’s case study. The authors describe it as moving from a weekend project to enormous GitHub attention in a few months, while also accumulating advisories, CVEs, marketplace attacks, and governance pressure. The specifics will need to be checked against live project data over time, but the broader argument is useful even if the numbers change: agent systems create security debt precisely through the same features that make them compelling.

An agent that can do real work has to touch real surfaces. That is the promise. That is also the problem.

The Idea in Plain English

The paper treats OpenClaw as a sociotechnical system.

That phrase matters. It means the system is not just the daemon, the model, the terminal, or the plugin marketplace. It is the whole arrangement: how users talk to the agent, what permissions it has, how skills are installed, where memory lives, how cron jobs run, how approvals are handled, how updates ship, and how the community grows around it.

The authors argue that autonomous agents differ from chatbots because they turn language models into controllers. A chatbot answers. An agent plans, calls tools, reads and writes files, invokes APIs, and sometimes keeps acting without a human approving every step.

Once that happens, architecture and governance become inseparable. A messaging UI makes an agent accessible, but it also brings social-channel spoofing and command ambiguity. A local-first daemon gives users power over their machine, but it also puts sensitive files and credentials nearby. A skill marketplace makes the system extensible, but it creates a supply-chain attack surface. A permissive approval flow makes the agent feel smooth, but it can weaken the boundary between intent and execution.

The paper’s central claim is that these are not isolated mistakes. They are structural tensions in the agent design space.

What the Researchers Tested

This is a survey, not a benchmark paper. The authors do not introduce a new model or run a controlled training experiment. Instead, they synthesize OpenClaw’s architecture, security history, ecosystem position, derivative projects, adoption dynamics, and governance questions.

The paper organizes its analysis around five dimensions: architecture, security, ecosystem comparison, derivative ecosystem, and adoption dynamics. Governance appears across all of them.

Its security section proposes a six-category vulnerability taxonomy. Its comparison section introduces ASTELD, a six-axis framework for classifying agent platforms by Architecture, Security, Tool integration, Execution, Level of autonomy, and Deployment. Its ecosystem section maps more than 50 derivative projects across community forks, enterprise adaptations, and research platforms.

The paper also formulates eight research questions covering architecture, security, ecosystem evolution, and sociotechnical adoption.

What They Found

Accessibility and security pull against each other

The strongest finding is the accessibility-security trade-off.

The paper argues that OpenClaw’s accessibility came from product choices that lowered friction: messaging-platform control, local deployment, broad tool access, and a marketplace for skills. Those same choices expanded the attack surface.

This is a useful frame because it avoids a lazy conclusion. The lesson is not simply “agents are insecure” or “open source moves too fast.” The lesson is that usability and power often arrive through channels that security teams would normally want to narrow.

For builders, the implication is blunt: security cannot be a late-stage hardening sprint. If the product promise is “the agent can act on your behalf,” the permission model is part of the product.

Agent marketplaces change the threat model

The paper treats ClawHub-style skill distribution as one of the defining risks of the ecosystem. It describes the ClawHavoc supply-chain attack as exposing 1,184 malicious marketplace skills, and later reports a deterioration in marketplace integrity from 12% malicious skills in February to 36% containing prompt injection vectors by April across a 40,000+ skill marketplace.

Those figures should be read as the paper’s reported evidence, not as independently verified current counts. Still, the mechanism is easy to understand.

Plugins and skills are not passive content. They can carry instructions, code, permissions, descriptions, dependencies, prompts, and social proof. In an agent system, the marketplace is not just an app store. It is a channel through which strangers can influence what an autonomous system is allowed to know, believe, and do.

That makes provenance, signing, review, dependency scanning, runtime permissions, and post-install monitoring core product features.

One architecture cannot serve every use case

ASTELD is the paper’s attempt to explain why agent ecosystems fragment.

The six axes are Architecture, Security, Tool integration, Execution, Level of autonomy, and Deployment. The authors use the framework to compare agent platforms and argue that projects tend to specialize because the axes constrain each other.

A local-first personal assistant has different needs from an enterprise workflow runner. A research harness can assume a different threat model than a consumer messaging agent. A high-autonomy tool runner must make different trade-offs than a tightly governed copilot.

The paper’s conclusion calls out an “empty quadrant”: no surveyed platform combines local-first accessibility with enterprise-grade security. Whether that remains true is less important than the design challenge it identifies. The agent market may not converge on one universal architecture. It may split into specialized tiers with different guarantees.

Popularity and enterprise readiness are separate metrics

The authors call this the adoption paradox. The paper reports enormous GitHub popularity while also claiming zero Fortune 500 customers, using that contrast to argue that community attention does not equal institutional readiness.

That point travels well beyond OpenClaw. Star counts, viral demos, Discord activity, and community plugins are signs of energy. They are not proof of governance maturity.

Enterprise adoption asks different questions. Who signs off on tool permissions? How are credentials isolated? Can the agent operate under policy? How are skills reviewed? What happens when a model ignores a policy instruction? Can an audit reconstruct what happened? How are updates rolled back?

Agent products have to earn trust through operational proof, not only community momentum.

Why It Happens

Agent systems collapse boundaries that software used to keep separate.

The model reads natural language from humans and the web. It interprets that language as intent. It calls tools that affect files, accounts, channels, and workflows. It may install new capabilities. It may store memory. It may wake up later through cron. It may talk through channels where identity and context are messy.

That turns security into a boundary-definition problem.

Where does instruction end and data begin? Which user asked for the action? Which tool is allowed in this context? Which skill is trusted? Which memory can be used? Which file path is safe? Which external text is allowed to influence execution?

Traditional software security already deals with many of these questions. Agents make them harder because the control layer is probabilistic and language-mediated. A policy that is obvious to a human may be ambiguous inside a prompt. A malicious instruction can arrive as content. A harmless-looking skill can become dangerous when combined with file access and credentials.

What This Means for Builders

Builders should treat the permission model as a first-class product surface.

That means permissions should be legible, scoped, revocable, and testable. Tool access should be contextual. Marketplace packages should carry provenance and minimal permissions. Cron and background work should have separate policies from interactive chat. Local-first access should come with clear boundaries around files, credentials, network calls, and destructive actions.

The paper also suggests that agent builders need ecosystem-level defenses. A single-agent sandbox is not enough if the marketplace can distribute malicious skills faster than reviewers can inspect them. Signing, reputation, automated scanning, dependency policy, runtime behavior monitoring, and quarantine flows all matter.

For OpenClaw-like systems, the hard part is keeping the product usable. If every action requires a scary approval, users route around the system. If approvals are too loose, the agent becomes a confused deputy with a friendly chat interface. The product challenge is designing consent that is both safe and tolerable.

What This Means for Buyers and Operators

Buyers should evaluate agent systems by their operating model, not only their demos.

Ask what the agent can touch. Ask how tools are granted. Ask whether plugin permissions are static or contextual. Ask how prompts, tool calls, files, memory, and background jobs are logged. Ask whether dangerous actions require fresh consent. Ask how marketplace packages are reviewed and removed. Ask what happens when a malicious document, web page, email, or plugin tries to steer the agent.

Operators should also separate personal-productivity risk from enterprise risk. A local personal assistant can accept trade-offs that a regulated enterprise deployment cannot. The question is not whether one model is right. It is whether the architecture matches the risk.

The paper’s warning is that adoption pressure can hide this distinction. A system can feel magical in personal use and still be immature for institutional deployment.

What to Watch Next

The field should watch whether local-first agents can close the security-accessibility gap without becoming too painful to use.

Researchers should watch marketplace security. Agent skills combine code, prompts, dependencies, permissions, and reputation. That makes them stranger than browser extensions and more active than ordinary packages.

Builders should watch policy ergonomics. The winning systems will not simply maximize safety or autonomy. They will make the right boundary obvious at the right moment.

Buyers should watch for auditability. If an agent cannot explain which instruction led to which action, it will be hard to trust in real operations.

Limitations and Caveats

This is a broad survey of a fast-moving ecosystem. Some of its quantitative claims may age quickly, and some deserve independent verification before being used as hard facts in a buying decision or security review.

The paper also focuses heavily on OpenClaw as a representative case. That makes the analysis vivid, but it can blur the line between what is specific to one project and what is true of autonomous agents generally.

The ASTELD framework is useful, but it is still a taxonomy. Taxonomies help organize thinking; they do not prove causal claims by themselves.

Finally, the paper’s strongest contribution is not any one number. It is the frame: autonomous agents are not just model wrappers. They are operating systems for delegated action. Their safety depends on architecture, product design, ecosystem governance, and human trust all at once.

Source

Li, Siyuan; Shu, Peng; Yu, Churan; Wang, Peilong; Zhang, Ruidong; Guo, Bowen; Li, Xinliang; Yan, Ruiyu; Zidan, Arif Hassan; Pan, Yi; Ruan, Wei; Chen, Lifeng; Chen, Junhao; Ding, Zhaojun; Li, Yiwei; Liu, Zhengliang; Dai, Haixing; Zhao, Lin; Bao, Yu; Li, Xiang; Zhang, Wei; Liu, Tianming. (2026). The Rise of Autonomous AI Agents: A Comprehensive Survey of OpenClaw — Architecture, Security, Ecosystem, and Beyond. ResearchGate PDF. Available at: https://www.researchgate.net/profile/Siyuan-Li-112/publication/404248344_The_Rise_of_Autonomous_AI_Agents_A_Comprehensive_Survey_of_OpenClaw_-_Architecture_Security_Ecosystem_and_Beyond/links/69f02eeddb00ec75d02e08d9/The-Rise-of-Autonomous-AI-Agents-A-Comprehensive-Survey-of-OpenClaw-Architecture-Security-Ecosystem-and-Beyond.pdf