# OpenClaw is the right idea with the wrong defaults I recently wrote about [the system I built around my Obsidian vault](https://dev.to/prefrontalsys/i-built-a-second-brain-that-runs-while-i-sleep-4gc1): two machines, a Telegram bot, background agents, 40+ Claude Code skills, and git as the only database. A few people pointed out that what I described functions a lot like [OpenClaw](https://openclaw.ai). They're right. OpenClaw is a personal AI assistant you run on your own devices. It connects messaging channels (WhatsApp, Telegram, Signal, Slack, Discord) to an LLM runtime, with skills for extension and a gateway as the control plane. My system does the same thing, just assembled from parts instead of installed as a package. Same architecture. Very different outcomes. In January 2026, security researchers found 42,665 OpenClaw instances exposed to the public internet. A critical vulnerability (CVE-2026-25253, CVSS 8.8) allowed one-click remote code execution through a crafted URL. Hundreds of malicious skills were found in the ClawHub marketplace distributing the Atomic macOS stealer. Microsoft, Cisco, and Trend Micro all published advisories. To their credit, the OpenClaw team has moved fast. The RCE was patched in v2026.1.29 on January 30. February alone brought v2026.2.12 (40 security fixes), v2026.2.14 (50+ more), and v2026.2.23 with further hardening. ClawHub now scans uploads with VirusTotal. But as of mid-February, Bitdefender was still finding roughly 900 malicious skills across the expanded 10,700+ skill registry, and the ClawHavoc supply chain campaign that planted them hasn't been fully cleaned up. My system, running the same architectural pattern, never had these problems. Not because I'm smarter than the OpenClaw developers. Because the defaults are different. ## The product problem OpenClaw wants to be everyone's personal AI assistant. That means it needs to be easy to install and easy to extend. These are reasonable goals. They also create a security surface that's very hard to defend. The Gateway binds to a port. If you expose that port to the internet (which thousands of people did), anyone can reach it. The Control UI accepts a `gatewayUrl` parameter from the query string and auto-connects a WebSocket, transmitting the auth token without confirmation. Skills install from a public marketplace with no code review. The default DM policy on most channels accepts messages from unknown senders via a pairing code, which is one social engineering step away from exploitation. None of these are bugs in isolation. They're product decisions. Easy onboarding, flexible deployment, an open skill ecosystem. Each one makes the product more accessible and more dangerous at the same time. ## What different defaults could look like My system makes the opposite tradeoffs. It's harder to set up, only works for one person, and has no marketplace. But it's also unexploitable from the outside because there's no outside. ### No ingress The VPS has no public ports. The entire firewall policy is two rules: ```yaml ufw_rules: - rule: allow port: "41641" proto: udp comment: "Tailscale WireGuard" - rule: allow interface: tailscale0 direction: in comment: "Tailscale interface" ``` Every connection runs over Tailscale's mesh network. SSH, git sync, the API bridge between machines, the health dashboard. If you're not on my tailnet, the VPS doesn't respond. It doesn't reject connections — it literally doesn't exist on any routable address. OpenClaw supports Tailscale Serve/Funnel as an option. But it's not the default. The default is binding to a port, and the docs walk you through exposing it. 42,665 people followed those instructions. The difference between "supported" and "default" is the difference between 0 exposed instances and 42,665. ### No marketplace I have about 40 skills. They live in a private git repo at `~/.claude/skills/`, version-controlled, synced across machines via Ansible. To add a skill, I write a markdown file describing what it does, what tools it can use, and how to invoke it. Then I commit it. OpenClaw's ClawHub has grown to over 10,700 skills. As of mid-February, Bitdefender estimated roughly 900 of them were malicious. A coordinated operation called ClawHavoc planted trojanized skills that looked legitimate, with fake "Prerequisites" sections that tricked users into installing the Atomic macOS stealer. OpenClaw has since added VirusTotal scanning for new uploads, but the existing poisoned skills took weeks to identify and remove. The marketplace model assumes you can scale trust. You can't. Not with AI skills that execute arbitrary tool calls on the user's machine. The only skill system that's safe is one where you wrote the skills, or you read and understood every line before installing them. That doesn't scale, which is exactly the point. ### No web UI accepting untrusted input The one-click RCE (CVE-2026-25253) happened because the Control UI's web page accepted a URL parameter and used it to establish a WebSocket connection. An attacker could craft a link, send it to a victim, and the victim's browser would connect their authenticated session to the attacker's server. My system has no web UI. The interface is a Telegram bot that bridges to tmux, or a terminal running Claude Code directly. There's a health dashboard served over Tailscale, but it's a static HTML page with no JavaScript, no WebSocket connections, and no query parameters that do anything. The absence of a web surface isn't a missing feature. It's a security decision. Every interactive web page you serve is an attack surface. If you don't need it, don't ship it. ### All connections are outbound CCBot, the Telegram bridge, uses long polling (`getUpdates`). It calls out to Telegram's API. Telegram never calls in. There are no webhooks, no callback URLs, no public endpoints. This matters because inbound connections require authentication, and authentication systems have bugs. Outbound-only means the VPS initiates every connection. The only way to reach it is to already be on the Tailscale network, which requires a device I've authorized. ### Budget caps and failure limits Background agents on the VPS have hard budget caps ($3-$10 per task) and a three-strike failure policy. If a task fails three times, it moves to a Failed section and stops retrying. I'm on Claude Code Max, so I'm not billed per token. The caps aren't about cost. They're about preventing runaway loops. An agent that can churn forever without limits will eventually do something stupid, and the budget cap is what stops it. It limits the blast radius of a misbehaving agent in a way that an open-ended runtime doesn't. ## This doesn't scale, and that's fine I can already hear the objection: "Not everyone can write Ansible playbooks and manage a VPS." True. This is a system built by one person for one person. The infrastructure came together in about three weeks, though the vault itself has been growing and morphing for years. It requires comfort with terminals, YAML, systemd, and git. But the lesson isn't "everyone should do this." The lesson is about what secure defaults for personal AI agents could look like. The agent runtime should not be reachable from the public internet. Mesh networks like Tailscale or WireGuard should be the default transport, not an optional add-on. Skills should be local, version-controlled, and auditable, not pulled from a marketplace with no review process. If the agent needs a visual interface, it should be a local application, not a web page served over HTTP that accepts parameters from the URL bar. The agent should call out to services; services should not call in to the agent. And there should be hard resource limits: budget caps, timeouts, failure thresholds. An agent that can spend unlimited money and retry forever is a liability even without an attacker. OpenClaw could ship these defaults tomorrow. Tailscale-only by default, local skills only, no Control UI query parameter injection. It would be harder to onboard. It would be much harder to exploit. The question is whether a product can survive being hard to set up. The answer, historically, is no — ease of use wins every time. But when ease of use means 42,000 exposed instances and 900 malicious skills in the marketplace, maybe the calculus is different. Or maybe it isn't, and the only safe personal AI agent is one you built yourself. I genuinely don't know. But I know what the right defaults could look like, because I'm running them. --- *This is a follow-up to [I Built a Second Brain That Runs While I Sleep](https://dev.to/prefrontalsys/i-built-a-second-brain-that-runs-while-i-sleep-4gc1).