The security problem nobody wants to talk about

Andrej Karpathy did not hold back. He said he is "a bit sus'd" to give his private data and keys to what he called a 400,000-line vibe-coded monster that is being actively attacked at scale. He pointed to reports of exposed instances, RCE vulnerabilities, supply chain poisoning, and malicious skills in the registry. His words: "a complete wild west and a security nightmare."

That is not a dismissal of OpenClaw. It is a recognition that something this big, moving this fast, with this much community contribution, creates a massive attack surface.

And he is right to be concerned. An AI agent is not a chatbot. A chatbot generates text. An agent executes actions. It reads your files, runs shell commands, calls APIs, sends messages on your behalf. Give it your email credentials and it can read every message in your inbox. Give it filesystem access and it can see every file on your machine.

The security question is not theoretical. It is the most important design decision in the entire agent architecture.

In this fourth installment of our series on the claw ecosystem, we compare three different approaches to security, and what each one teaches us about building trustworthy autonomous systems.

Approach 1: OS-level isolation (NanoClaw)

NanoClaw takes the most radical approach to security in the ecosystem: it does not trust the application at all.

Instead of building permission checks into the agent code, NanoClaw gives each WhatsApp group its own isolated Linux container. On macOS, it uses Apple Container, lightweight VMs that ship with macOS Tahoe. On Linux, it uses Docker.

Each container has its own filesystem, IPC namespace, and process space. The agent running in Container A literally cannot access files in Container B, regardless of any bugs, prompt injections, or vulnerabilities in the agent's code.

The security boundary is the OS, not the application.

This is a different security model from everything else in the ecosystem. Your attack surface is 500 lines of auditable TypeScript plus the OS container runtime. Nothing else. No skill registry to poison. No plugin system to exploit. No 400,000-line codebase to find vulnerabilities in.

The tradeoff is capability. NanoClaw's container-per-group model means each agent instance is isolated from every other instance. That is great for security but limits multi-agent collaboration and shared state. You cannot have one agent check your calendar and another send a message based on the result without explicit cross-container communication.

But for the threat model NanoClaw addresses, preventing a compromised agent from accessing data it should not have, OS-level isolation is hard to beat.

NanoClaw also gives users granular control over what their autonomous agents can do. The emphasis is on agents that operate autonomously: scheduling tasks, running background processes, taking initiative. The security model makes this safer because even an autonomous agent operating inside a container can only affect what is inside that container.

Approach 2: defense-in-depth (IronClaw)

IronClaw is what happens when security researchers look at the agent ecosystem and build from first principles. Written in Rust, a language with memory safety guarantees, IronClaw implements five distinct security layers, each a hard boundary.

Layer 1, Network: TLS 1.3 encryption for all communication. SSRF protection prevents the agent from making requests to internal network addresses. Rate limiting is applied per tool to prevent abuse.

Layer 2, Request filtering: Every HTTP request the agent makes goes through an endpoint allowlist. If a URL is not explicitly approved, the request is blocked. This means a prompt injection that says "send my data to evil.com" fails at the network layer, not the application layer. Pattern detection catches common prompt injection techniques. Content sanitization strips potentially dangerous payloads.

Layer 3, Credential management: Secrets are encrypted with AES-256-GCM and injected at host boundaries. Tools never see raw credentials. Instead, they get opaque tokens that the host resolves. 22 regex patterns with Aho-Corasick optimization scan all requests and responses for credential leaks in real-time. If your API key accidentally appears in a response, IronClaw catches it before it reaches the output.

Layer 4, WASM sandbox: Untrusted tools (community plugins, experimental skills, anything not in the core) run inside isolated WebAssembly containers. Each WASM sandbox has capability-based permissions: it can only access the specific resources it has been granted. No ambient authority. No "the tool can do anything the host process can do."

Layer 5, Docker isolation: For resource-intensive tasks (code execution, file processing), IronClaw spins up Docker containers with per-job resource limits: CPU, memory, execution time. A runaway process hits its resource ceiling and gets killed, not your system.

The result: 3.4MB binary, <10ms startup, ~7.8MB memory. And five independent security boundaries between an attacker and your data.

The tradeoff is complexity in deployment. You need PostgreSQL with pgvector. You need Docker for the sandbox layer. You need to manage allowlists and credential configurations. This is not a "download and run" experience.

Approach 3: application-level permissions (OpenClaw)

OpenClaw takes the most conventional approach to security: application-level checks implemented in code. Allowlists define which tools the agent can use. Pairing codes authenticate users. Config flags control what actions are permitted. The sandbox runs tool execution in Docker containers with network isolation.

This approach has the advantage of flexibility. You can fine-tune permissions per user, per skill, per tool. The 5,700+ skills on ClawHub each declare their required permissions, and users can grant or deny them.

But the security boundary is the application code. If there is a bug in the permission check, the boundary fails. If a malicious skill declares misleading permissions, the user might grant access they should not. If a prompt injection bypasses the application logic, there is no OS-level backstop.

Karpathy's critique hits hardest here. In a 400,000-line codebase that moves fast and accepts community contributions, finding and exploiting a vulnerability is a matter of when, not if. The KoiSecurity Clawdex scanner helps identify malicious skills, but the verification process is largely manual.

OpenClaw's approach works well for the majority of users who want convenience and capability. But for high-security environments, handling sensitive data, running in production, operating in regulated industries, the application-level model requires significantly more trust in the codebase.

What the comparison teaches us

Three approaches, three threat models:

	NanoClaw	IronClaw	OpenClaw
Trust boundary	OS container	5-layer defense	Application code
Attack surface	~500 lines + OS	Rust binary + WASM + Docker	~400,000 lines
Credential protection	Container isolation	AES-256-GCM + leak scanning	Config-based
Prompt injection defense	Contained blast radius	Network-layer blocking	Application-layer checks
Ease of setup	Simple	Complex	Moderate

The lesson is not that one approach is universally better. The right security model depends on your threat model.

Running a personal agent that posts to social media and manages your calendar? OpenClaw's application-level permissions are probably fine. The convenience is worth the tradeoff.

Running an agent that handles student records, financial data, or health information? You want IronClaw's defense-in-depth or NanoClaw's OS-level isolation. The overhead is worth the protection.

Running an agent that operates autonomously, taking actions without human approval, on a schedule, in the background? NanoClaw's container model with user-defined controls gives you the best safety net. Even if the autonomous agent goes off the rails, the blast radius is contained.

The gaps that still exist

Even with these approaches, the ecosystem has unresolved security challenges.

Skill verification at scale: OpenClaw's ClawHub has 5,700+ skills. Verifying that each one is safe remains largely manual. The ecosystem needs automated skill auditing with static analysis, sandboxed execution testing, and reputation scoring.

Cross-agent security: As multi-agent systems emerge, the security model needs to account for agents communicating with each other. How do you prevent Agent A from manipulating Agent B through adversarial messages?

Supply chain integrity: A malicious dependency in a skill's requirements can compromise the entire agent. Package pinning and reproducible builds are not yet standard practice.

Observability: When your agent does something unexpected at 3 AM, how do you figure out why? The ecosystem lacks APM-style tracing for agent reasoning chains.

What this means for education

In educational settings, the security question is not abstract. Student data is governed by FERPA. Health records by HIPAA. Financial aid by federal regulation. An AI agent operating in a university environment needs security guarantees that go beyond "the application checks permissions."

At ibl.ai, our approach draws from the same principles as IronClaw and NanoClaw. Student data stays within institutional boundaries. The AI mentor operates within defined capability boundaries. Every action is auditable. Credentials are managed at the infrastructure level, not the application level.

The claw ecosystem's security conversation is directly relevant to education technology. As institutions deploy AI agents for advising, tutoring, and administrative support, the architecture decisions described here (OS isolation vs. defense-in-depth vs. application permissions) will determine whether those systems can be trusted with student data.

The answer is not "don't deploy agents." The answer is "deploy agents with the right security architecture for your threat model." The claw ecosystem is writing the playbook.

In the final post, we step back and look at the bigger picture: what is missing from the ecosystem, where the opportunities are, and where you should start if you want to build.