On February 22, 2026, security researcher @GrMPbody posted a set of screenshots on Twitter: a Shodan search showed more than 40,000 OpenClaw instances with their web ports exposed directly to the public internet. No password, no auth token — open a browser, type the IP, and you're in. Including conversation history, configuration data, and in some cases API keys.
The tweet got more than 3,000 retweets in 12 hours. The OpenClaw community issued an emergency advisory recommending users immediately configure reverse proxies and authentication middleware. But 40,000 exposed instances meant a lot of users probably didn't know their agent was wide open to the entire internet.
The root cause was clear enough: OpenClaw starts a web server by default to provide a management interface and API endpoints, and most users don't configure additional security layers when they deploy.
The Default Configuration Trap
A default OpenClaw install starts an HTTP server on port 3000 (or whatever port the user configured). The server hosts the web interface, REST APIs, WebSocket connections, and health check endpoints. In a local development environment, that's fine — localhost isn't exposed externally.
The problem is deployment environments. When users deploy OpenClaw to a VPS, cloud instance, or home server without configuring firewall rules or a reverse proxy, that port is suddenly on the public internet. OpenClaw's install documentation does mention security recommendations, but "mentions" and "enforces" are very different. Forty thousand exposed instances prove that most users don't read the security docs.
This is a classic security design problem: security should be the default, not an option. When secure configuration requires active user effort, it effectively doesn't exist — because there will always be users who don't do it.
NanoClaw's Zero Attack Surface
NanoClaw doesn't start any web server. It doesn't listen on any TCP port. It doesn't expose any HTTP API.
NanoClaw's communication model is entirely built on outbound connections: it initiates a connection to WhatsApp (via the Baileys library's WebSocket connection) and to the Anthropic API (via HTTPS). Both connections are outbound — NanoClaw connects to external services, external services don't connect to it.
From a network security perspective, this means NanoClaw's attack surface is zero. You can't find it with Shodan, because it doesn't listen on any port. You can't connect to it from outside, because it offers no services that accept inbound connections. You can't retrieve its data via HTTP, because there's no HTTP server.
This isn't a security feature — it's a natural result of the architecture. NanoClaw's functionality doesn't need a web server. Users interact with the agent through WhatsApp, not a web interface. Administrative operations happen through the command line, not a REST API. So there's no reason to start a web server at all.
The most secure code isn't code with lots of security checks. It's code that doesn't need security checks — because the attack surface doesn't exist.
Server Ports vs Message-Driven
The difference between the two architectures comes down to a simple model.
OpenClaw uses a server architecture: it starts, listens on a port, waits for requests, processes them, returns responses. This architecture inherently needs to answer the question "who is allowed to connect to me?" — that's authentication and authorization.
NanoClaw uses a message-driven architecture: it starts, connects to a message source (WhatsApp), waits for messages, processes them, sends responses through the same connection. It doesn't need to answer "who is allowed to connect to me?" because nobody connects to it — it connects to others.
Message-driven architecture isn't universally better than server architecture. If you need a web interface, you need a web server. If you need an API for other systems to call, you need to listen on a port. But if your core use case is interaction through a chat platform, message-driven architecture offers a fundamental security advantage: no inbound attack surface.
40,000 Lessons
Those 40,000 exposed OpenClaw instances are an industry-level lesson: don't assume users will configure security correctly.
Security has to be the default. If your software is insecure by default, most of its deployments will be insecure. That's not the users' fault — it's a design failure. Security shouldn't be an extra step, a chapter in the documentation, or an optional configuration.
NanoClaw's approach is the most thorough: eliminate the attack surface that would need securing. You don't need to configure firewall rules because there are no ports to protect. You don't need to set up authentication middleware because there are no HTTP endpoints to authenticate. You don't need to read security configuration docs because there's no security configuration to do.
The best state of security isn't "secure when configured correctly." It's "secure regardless of configuration" — or better still, "no configuration required."