In early February 2026, GitGuardian published a report that should have alarmed every developer running a personal AI assistant. Their secret-scanning infrastructure had detected over 200 leaked credentials directly tied to OpenClaw deployments — API keys, database passwords, OAuth tokens, and cloud provider credentials, scattered across public repositories, log files, and error reports. Some belonged to healthcare companies. Others to fintech startups. All of them were live.
A few days later, Northeastern University published an article with a headline that cut deeper than any CVE number: "Why the OpenClaw AI Assistant is a 'Privacy Nightmare.'" The researchers didn't focus on a single vulnerability. They focused on the architecture itself — the way OpenClaw handles data, stores credentials, and exposes user information by design, not by accident.
These weren't isolated incidents caused by careless users. They were the predictable result of running AI agents in environments where secrets, user data, and agent code all share the same address space with no isolation between them.
How Secrets End Up in the Wrong Places
The typical OpenClaw setup works like this: you install it on your machine, configure your API keys in environment variables, and start chatting. The agent process runs as your user, with your permissions, reading your environment variables. Every skill you install runs in the same process, with the same access.
This means that when you ask your AI assistant to help you debug a deployment script, the agent can see your AWS credentials. When a skill processes your email, it can read your database password. When an error occurs and a stack trace gets logged, those environment variables can end up in the log file. And when that log file gets committed to a repository, or uploaded to a bug report, or synced to a cloud service — your secrets are now public.
GitGuardian's 200+ leaked secrets weren't the result of 200 separate mistakes. They were the result of one architectural mistake repeated 200 times: putting secrets in process.env where every piece of code in the process can read them.
The problem compounds with skills and plugins. OpenClaw's skill system runs third-party code in the same process as the core agent. A malicious skill doesn't need an exploit to steal your credentials — it just reads process.env. A poorly written skill doesn't need to intentionally leak your data — it just includes environment context in an error report. The attack surface isn't a vulnerability to be patched. It's the architecture itself.
What Northeastern Got Right
The Northeastern researchers identified something that the security community had been dancing around: the privacy problem with AI assistants isn't about encryption or authentication. It's about the fundamental question of what the agent can access and what boundaries exist between the agent's world and yours.
When an AI agent runs as your user, with your permissions, on your machine, there is no boundary. The agent can read your files, your credentials, your browsing history, your SSH keys. It can access anything you can access. The only thing preventing it from doing something harmful is the prompt — and prompt injection attacks have demonstrated repeatedly that prompts are not a security boundary.
This is what Northeastern meant by "privacy nightmare." Not that OpenClaw was deliberately stealing data, but that the architecture made it impossible to guarantee that data wouldn't leak. The agent's access was bounded only by the operating system's user permissions, which is to say, it wasn't meaningfully bounded at all.
How NanoClaw's Container Isolation Changes the Equation
NanoClaw takes a fundamentally different approach. Every agent runs inside its own Linux container — Apple Container on macOS, Docker on macOS and Linux. The container is not a convenience feature or a deployment option. It's the security model.
When you send a message to NanoClaw, the host process doesn't run Claude directly. It spawns a container, mounts only the specific directories that agent needs access to, and passes the conversation context in. The agent runs inside the container with its own filesystem, its own process space, and its own network stack. When it's done, the container is torn down.
Here's where the secret handling gets interesting. NanoClaw never loads your ANTHROPIC_API_KEY into process.env. Instead, it reads the key from .env at runtime and passes it to the container process via stdin as a JSON payload. Inside the container, the agent-runner receives the key, uses it for API calls, and never writes it to disk or exports it to the environment.
This means that even if a malicious prompt tricks the agent into running `printenv` or `cat /proc/self/environ`, the API key isn't there. It exists only in the agent-runner process memory, for the duration of that single conversation turn. A compromised container can't leak what it doesn't have access to.
The mount system adds another layer. NanoClaw maintains an allowlist of directories that can be mounted into containers, stored outside the project root. Each group gets its own isolated filesystem — its own CLAUDE.md memory file, its own writable workspace. The allowlist includes symlink escape detection, so a crafted symbolic link can't trick the mount system into exposing directories outside the permitted set.
Containers also run as a non-root user, with the project source mounted read-only. An agent can read the codebase to understand context, but it can't modify the host's files. Writable paths are scoped per-group and cleaned up when the container exits.
The Per-Group Isolation Model
NanoClaw's isolation goes beyond just separating the agent from the host. Each WhatsApp group gets its own container, its own memory, and its own filesystem. Group A cannot see Group B's conversations, files, or CLAUDE.md memory — not because of application-level access controls, but because they run in physically separate containers with separate mount points.
This matters for a scenario that most AI assistants ignore entirely: shared devices and multi-user setups. If you use NanoClaw with your family, your work group's conversations and files are isolated from your family group's conversations and files at the container level. There's no application bug that can leak data between groups, because the isolation is enforced by the container runtime, not by the application.
Your main WhatsApp channel — the direct message with the assistant — serves as the admin interface. It's the only channel that can manage scheduled tasks, modify configuration, and access cross-group state. Group channels are restricted to their own sandbox by default.
What the Industry Should Learn
The GitGuardian report and the Northeastern analysis point to the same conclusion: AI agents are infrastructure, and infrastructure requires infrastructure-grade security. Running an AI agent in the same process as your credentials, with the same permissions as your user account, is the equivalent of running a web server as root with no firewall. It works until it doesn't, and when it doesn't, the blast radius is everything.
Container isolation isn't a new idea. The web hosting industry figured this out two decades ago — you don't run multiple customers' code in the same process. The database industry figured it out even earlier — you don't give every query access to every table. But the AI agent ecosystem is still in its "run everything as root" phase, and the leaked secrets and privacy nightmares are the predictable result.
NanoClaw's approach isn't the only way to solve this problem, but it demonstrates that the problem is solvable without sacrificing functionality. Agents running inside containers can still search the web, browse pages, read and write files, and execute shell commands. They just do it inside a sandbox where the blast radius of any failure — whether it's a bug, a prompt injection, or a malicious skill — is limited to that single container's scope.
The 200 leaked secrets that GitGuardian found didn't have to happen. They happened because the architecture made them inevitable. The fix isn't better user education or more careful credential management. The fix is an architecture where secrets can't leak because they're never in a place where leaking is possible.