What if the answer to AI agent security isn’t better patches — it’s a fundamentally different architecture?
That’s the bet behind NanoClaw, a new open-source agent platform that runs every agent in its own container by default. And when Andrej Karpathy called it out as “really interesting,” people started paying attention.
The Security Problem NanoClaw Solves
OpenClaw runs bare metal. It uses application-level checks to prevent agents from accessing things they shouldn’t. But as recent incidents have shown — from the ClawJacked vulnerability to a Meta exec’s deleted inbox — those checks have gaps.
Creator Gavriel Cohen, a software engineer based in Israel, experienced this firsthand. He’d been using OpenClaw as a sales pipeline manager for his AI marketing agency, connected to WhatsApp, Obsidian, and Kanban boards. It worked well — too well.
“I started to see massive security issues,” Cohen told The Register. “We were getting a ton of value from it, but it’s burning a hole in my subconscious. It was literally keeping me up at night.”
The problem: even on a dedicated Mac mini, the agent had access to his Chrome profile, social media accounts, and everything else in its environment.
Architecture: Containers All the Way Down
NanoClaw’s key insight is isolation by default:
- Each agent runs in its own container — just the agentic loop and the Anthropic Agent SDK, nothing else
- Data access is scoped — connect an agent to WhatsApp and it only sees the specific group you assign, not your entire message history
- Full bash access within the sandbox — agents can install tools and work freely, but only within their container boundaries
This is different from just putting OpenClaw in a container. As Cohen points out, containerizing the entire OpenClaw instance doesn’t help because all its integrations and data are still inside the same boundary.
4,000 Lines vs. 400,000
Karpathy highlighted another advantage: NanoClaw’s core engine is roughly 4,000 lines of code.
“Anybody could review it, understand it, ask Claude a few questions if you need, and get the sense of what’s the security model, what’s the architecture,” Cohen said.
OpenClaw’s 400,000-line codebase, by contrast, makes the open-source assumption that “many eyes will find bugs” largely theoretical. It’s unlikely anyone has reviewed the full codebase.
NanoClaw doesn’t try to replicate OpenClaw’s breadth. Cohen built it around Claude Code in a weekend, deliberately not reinventing what already exists.
“I don’t need three thousand integrations. I only need like three things.”
What This Means for the Ecosystem
NanoClaw isn’t trying to replace OpenClaw. It’s solving a different problem: giving people who want strong isolation a platform that provides it architecturally rather than through policy.
For OpenClaw users, the lesson is clear: the security model matters as much as the feature set. If you’re running agents with access to sensitive data — email, messaging, financial tools — the container-first approach addresses a class of vulnerabilities that application-level sandboxing can’t fully prevent.
The broader trend is encouraging. Between NanoClaw’s container isolation, ClawBands for human-in-the-loop oversight, and OpenClaw’s own rapid patching cadence, the ecosystem is taking security seriously.
Competition on security architecture is exactly what this space needs.
Getting Started
NanoClaw is open source on GitHub. If you’re running agents with sensitive data access and container isolation appeals to you, it’s worth evaluating — especially if your use case fits a focused, few-integration setup rather than OpenClaw’s kitchen-sink approach.
For most users running OpenClaw today, the practical takeaway: review our guardrails guide and keep your instance updated. The February security patches addressed the most critical vulnerabilities, and strong configuration goes a long way. For a comprehensive look at OpenClaw’s security model, read our complete security guide.