OpenLegion vs nanobot: What a CVSS 10.0 Vulnerability Teaches About Agent Security

Q: How does credential handling compare between OpenLegion and nanobot?

nanobot stores API keys in ~/.nanobot/config.json (initially world-readable until patched). Keys are loaded into the Python process memory at runtime. OpenLegion uses a vault proxy — agents make API calls through a proxy that injects credentials at the network level. Agents never hold, read, or have access to API keys in any form.

nanobot is probably the most instructive case study in the AI agent security space. Created by an academic research lab in early 2026, it distills OpenClaw's 430,000+ lines down to approximately 4,000 lines of Python — a 99% code reduction that earned 218 points on Hacker News (the strongest reception of any Claw alternative) and roughly 20,000-26,000 GitHub stars.

Then, within weeks of launch, security researchers disclosed a critical vulnerability (CVSS 10.0): nanobot's WhatsApp bridge bound its WebSocket server to 0.0.0.0:3001 without any authentication. Anyone on the network could hijack WhatsApp sessions. Additional critical vulnerabilities followed — shell command injection, path traversal bypass, and a remote code execution flaw inherited from a LiteLLM dependency.

nanobot is a well-intentioned teaching tool that accidentally became a case study in why lightweight code alone does not equal secure code. OpenLegion exists to make this lesson structural.

OpenLegion is a security-first AI agent platform with mandatory Docker container isolation, vault proxy credential management, per-agent budget enforcement, and deterministic YAML workflows.

What is the difference between OpenLegion and nanobot?

nanobot is a ~4,000-line Python reimplementation of OpenClaw focused on educational simplicity and readability. It supports 11+ LLM providers and 8+ messaging channels but has suffered critical WhatsApp bridge vulnerability (CVSS 10.0, unauthenticated WhatsApp session hijack), shell injection, path traversal, and LiteLLM RCE vulnerabilities. OpenLegion is a security-first Python framework with mandatory Docker container isolation per agent, vault proxy credential management where agents never see API keys, per-agent budget enforcement, and deterministic YAML DAG workflows. nanobot optimizes for learning and simplicity; OpenLegion optimizes for production security.

TL;DR

Dimension	OpenLegion	nanobot
Primary focus	Production security infrastructure	Educational simplicity
Language	Python	Python (~4,000 lines)
Agent isolation	Docker container per agent, non-root	`restrict_to_workspace` flag (application-level)
Credential security	Vault proxy — agents never see keys	Config file (`~/.nanobot/config.json`)
Budget controls	Per-agent daily/monthly hard cutoff	None built-in
Orchestration	Deterministic YAML DAG workflows	Single agent with background sub-agents
LLM providers	100+ via LiteLLM	11+ (OpenRouter, Anthropic, OpenAI, DeepSeek, etc.)
Messaging channels	5	8+ (Telegram, Discord, WhatsApp, Feishu, DingTalk, etc.)
Multi-agent	YAML-defined fleets with per-agent ACLs	Sub-agent spawning (no fleet orchestration)
Memory	Persistent per-agent with vector search	Grep-based retrieval (deliberately avoids RAG)
GitHub stars	~59	~20,000-26,000
License	BSL 1.1	MIT
Known CVEs	0	critical WhatsApp bridge vulnerability (CVSS 10.0) + 3 additional critical patches
Origin	Independent	Academic research lab

Choose nanobot if...

You want to learn how AI agents work. nanobot is a teaching skeleton. At 4,000 lines with clear structure, it is the best codebase for understanding the core agent loop: provider abstraction, tool dispatch, memory retrieval, and chat gateways. DataCamp published a full tutorial. The creators explicitly designed it for educational readability.

You need Asian messaging platform support. nanobot has first-class support for Feishu (Lark), DingTalk, QQ, and WeChat-adjacent platforms — channels that no Western-focused framework covers well. If your deployment targets Chinese enterprise messaging, nanobot's ecosystem is uniquely positioned.

You want to run agents on a Raspberry Pi. nanobot is lightweight enough for single-board computers. Combined with Ollama for local inference, you get fully offline agent operation.

You value simplicity over infrastructure. JSON config, grep-based memory (no vector database required), and pip install. No Docker, no YAML workflows, no vault setup. From install to running agent in under five minutes.

Community momentum matters to you. nanobot's 218-point HN launch, active Discord, DataCamp integration, and ~20,000+ stars represent significant community investment and a large pool of contributors fixing issues quickly (the CVSS 10.0 was patched within days).

Choose OpenLegion if...

Security must be architectural, not optional. nanobot's restrict_to_workspace flag is the primary isolation mechanism — a boolean that can be toggled off. Its API keys live in a plaintext JSON config file. Its WebSocket server shipped without authentication. These are not obscure edge cases; they are fundamental architectural decisions that produced a CVSS 10.0 within weeks. OpenLegion makes insecure configurations structurally impossible: container isolation is mandatory, vault proxy is the only credential path, and YAML workflows are acyclic by design.

You cannot afford a CVSS 10.0 in production. critical WhatsApp bridge vulnerability allowed unauthenticated network-adjacent attackers to hijack WhatsApp sessions by connecting to nanobot's unprotected WebSocket server on port 3001. The additional shell injection and path traversal vulnerabilities were found by a single security researcher in a single audit. OpenLegion's vault proxy architecture means there are no credentials to hijack — agents call through a proxy that injects keys at the network layer.

You need per-agent cost control. nanobot has no budget enforcement. With 11+ provider support and the ability to spawn background sub-agents, uncontrolled API spend accumulates silently. OpenLegion enforces per-agent daily and monthly limits with automatic hard cutoff.

You need deterministic multi-agent workflows. nanobot supports spawning sub-agents, but orchestration is LLM-driven and non-deterministic. OpenLegion's YAML DAG workflows define exact execution order, tool access, and dependencies — auditable before deployment, acyclic by design.

You need to prove security posture to stakeholders. nanobot's CVE history makes it a difficult sell to security teams, compliance reviewers, or enterprise procurement. OpenLegion's vault proxy architecture, mandatory container isolation, and per-agent ACLs provide demonstrable security controls.

Security Model Comparison

Where secrets live

nanobot stores API keys in ~/.nanobot/config.json — a plaintext JSON file on disk. The config file was initially written with 0644 permissions (world-readable); this was later patched to 0600. At runtime, keys are loaded into the Python process memory. Any code executing within the agent's process can read them.

OpenLegion stores credentials in a vault that agents cannot access. API calls route through a vault proxy that injects credentials at the network level. No config files with plaintext keys, no environment variables with secrets, no mounted credential files. The agent process never holds API keys.

Isolation model

nanobot uses a restrict_to_workspace flag that limits file operations to the workspace directory. This is an application-level check in the Python code — if an agent achieves arbitrary code execution (which the shell injection vulnerability demonstrated was possible), the workspace restriction can be bypassed. No OS-level isolation is enforced.

OpenLegion uses Docker container isolation per agent. Each agent runs in a separate container with non-root execution, no Docker socket access, no-new-privileges, and per-container resource caps. Even if an agent achieves arbitrary code execution inside its container, it cannot access other agents, the host system, or credential stores.

The CVE record

nanobot has accumulated significant security issues in its brief existence:

critical WhatsApp bridge vulnerability (CVSS 10.0): WhatsApp WebSocket bridge bound to 0.0.0.0:3001 without authentication. Network-adjacent attackers could hijack sessions. Discovered by security researchers.
Shell command injection (Medium): Unsanitized user input passed to shell execution.
Path traversal bypass (Medium): restrict_to_workspace could be circumvented.
LiteLLM RCE via eval() (Critical): Inherited from dependency. Remote code execution through crafted input.
Session poisoning (patched Feb 26, 2026): Message history manipulation.

OpenLegion has zero CVEs. Its architecture makes several of nanobot's vulnerability classes structurally impossible: vault proxy eliminates credential exposure, Docker isolation prevents path traversal escapes, and YAML workflows prevent arbitrary shell execution without explicit tool grants.

Budget controls

nanobot has no built-in spending limits. Background sub-agents can make API calls with no caps.

OpenLegion enforces per-agent daily and monthly limits with automatic hard cutoff.

nanobot's Ecosystem: What It Does Best

The teaching skeleton

nanobot's greatest contribution is educational. The core agent loop — receive message, retrieve context, call LLM, dispatch tools, return response — is laid bare in clean, readable Python. The deliberate choice to use grep-based memory retrieval instead of RAG makes the retrieval mechanism transparent. The JSON config is human-readable. Every architectural decision prioritizes understanding over sophistication.

For students, researchers, and developers learning how AI agents work internally, nanobot is arguably the best starting point.

Asian platform integration

nanobot's channel support includes Feishu (Lark), DingTalk, QQ, and Matrix — platforms that dominate Chinese enterprise communication. No other framework in the OpenClaw ecosystem provides comparable coverage. The project's academic origin likely explains this focus, and it represents genuine value for teams operating in Asian markets.

ClawHub skill compatibility

nanobot integrates with the ClawHub skill ecosystem, giving it access to community-contributed agent skills. The SKILL.md documentation format is shared across nanobot, PicoClaw, and other Claw-family projects.

The rapid response culture

When the critical WhatsApp bridge vulnerability was disclosed, the nanobot team patched it within days. The session poisoning fix landed February 26. Shell injection and path traversal were addressed quickly. The community's responsiveness is genuinely impressive — but it also highlights that the issues should not have shipped in the first place.

Common production pitfalls

The fundamental problem is architectural. nanobot was designed as a teaching tool that became production-popular. Its security model — application-level workspace restriction, plaintext config, no network isolation — is appropriate for local experimentation but dangerous in production. The CVSS 10.0 was not a bug in complex code; it was a WebSocket server without authentication. This is the kind of oversight that architectural security constraints prevent.

Dependency chain risk. The LiteLLM RCE (via eval()) demonstrates that even minimal codebases inherit vulnerabilities from their dependencies. nanobot's ~4,000 lines are auditable, but the full dependency tree is not.

No network security model. nanobot has no concept of network policies, ingress controls, or service mesh isolation. Agents can make arbitrary outbound connections. Combined with shell access, this creates a wide attack surface.

What OpenLegion covers differently

OpenLegion's architecture prevents nanobot's vulnerability classes by design:

critical WhatsApp bridge vulnerability (unauthenticated network service): OpenLegion agents run in Docker containers with no exposed ports by default. Network access is explicitly granted per-agent.
Shell injection: OpenLegion's YAML workflows require explicit tool grants. Shell access is not available unless specifically enabled in the agent's ACL.
Path traversal: Docker container isolation with read-only mounts and no Docker socket eliminates path traversal as a meaningful attack vector.
Credential exposure: Vault proxy means no credentials exist in the agent's environment to steal.
Dependency RCE: Container isolation limits blast radius — even if a dependency has an RCE, the attacker is contained within a sandboxed container with no credentials.

Hosting vs Self-Host Tradeoffs

nanobot is designed for local self-hosting. pip install, JSON config, and a running agent in minutes. No hosted service exists. The lightweight nature means any Linux system, macOS, or even a Raspberry Pi can host it.

OpenLegion requires Python, SQLite, and Docker. The hosted platform (coming soon) will offer per-user VPS instances at $19/month. The Docker requirement adds infrastructure overhead but provides the isolation layer that makes production deployment safe.

Who It's For

nanobot is for students, researchers, and individual developers who want to understand AI agent architecture through a clean, readable codebase. It is also valuable for teams targeting Asian messaging platforms (Feishu, DingTalk, QQ). The ideal user runs nanobot locally for personal tasks and does not expose it to untrusted networks.

OpenLegion is for engineering teams deploying agents in environments where security incidents have business consequences. The ideal user needs to demonstrate credential isolation, cost control, and audit trails to stakeholders — and cannot risk a CVSS 10.0 in production.

The Honest Trade-off

nanobot proves that you can rebuild an AI agent runtime in 4,000 lines. That accomplishment is real and valuable for the ecosystem. But the critical WhatsApp bridge vulnerability proves that simplicity and security are not the same thing. A 4,000-line codebase with a CVSS 10.0 is less secure than a 30,000-line codebase with architectural constraints that make that vulnerability class impossible.

If you want to learn how agents work, read nanobot's source. If you want to deploy agents safely, use a framework where unsafe configurations cannot occur.

For the full landscape, see our AI agent frameworks comparison.

Deploy agents with security that's architectural, not aspirational.

Start Free Trial Read the Docs See All Comparisons

Frequently Asked Questions

What is nanobot?

nanobot is a ~4,000-line Python reimplementation of OpenClaw created by an academic research lab. It supports 11+ LLM providers and 8+ messaging channels (including Asian platforms like Feishu, DingTalk, and QQ). It launched February 2, 2026 and has approximately 20,000-26,000 GitHub stars. It received the strongest Hacker News reception of any OpenClaw alternative (218 points, 111 comments).

OpenLegion vs nanobot: what's the difference?

nanobot is an educational teaching skeleton — minimal, readable, and designed for learning. OpenLegion is a production security framework. nanobot uses application-level workspace restriction and plaintext JSON config; OpenLegion uses Docker container isolation and vault proxy credentials. nanobot has suffered a critical WhatsApp bridge vulnerability (CVSS 10.0) plus three additional critical vulnerabilities; OpenLegion has zero CVEs and an architecture that makes those vulnerability classes structurally impossible.

Is OpenLegion a nanobot alternative?

Yes. Both are Python-based AI agent frameworks, but they serve different purposes. nanobot is best for learning and local experimentation. OpenLegion is an alternative for teams that need production-grade security — vault proxy credential isolation, per-agent budget enforcement, Docker container isolation, and deterministic YAML workflows.

How does credential handling compare between OpenLegion and nanobot?

nanobot stores API keys in ~/.nanobot/config.json (initially world-readable until patched). Keys are loaded into the Python process memory at runtime. OpenLegion uses a vault proxy — agents make API calls through a proxy that injects credentials at the network level. Agents never hold, read, or have access to API keys in any form.

Which is better for production AI agents?

OpenLegion is significantly better suited for production. nanobot was designed as a teaching tool and has accumulated a critical WhatsApp bridge vulnerability (CVSS 10.0), shell injection, path traversal, and dependency RCE vulnerabilities within weeks of launch. OpenLegion's mandatory container isolation, vault proxy credentials, per-agent budgets, and deterministic workflows address the exact vulnerability classes that affected nanobot.

Is nanobot the same as nanobot (Obot AI)?

No. There are two completely different projects sharing the name. The nanobot discussed on this page is a ~4,000-line Python OpenClaw alternative from an academic research lab. Obot AI's nanobot is a Go-based MCP agent platform backed by $35M in seed funding from the Rancher Labs team. This page compares OpenLegion with the Python OpenClaw alternative version.

What was nanobot's critical WhatsApp bridge vulnerability?

nanobot's WhatsApp bridge contained a critical vulnerability (CVSS 10.0) where the WebSocket server bound to 0.0.0.0:3001 without any authentication. Any network-adjacent attacker could connect and hijack active WhatsApp sessions. It was patched quickly but demonstrates the risk of deploying agent frameworks without architectural network isolation.

Can I migrate from nanobot to OpenLegion?

nanobot's JSON config and agent setup would be restructured as YAML DAG workflows with explicit tool grants, budget limits, and per-agent ACLs. LLM provider settings transfer directly since both use LiteLLM-compatible provider configurations. See our AI agent orchestration page.