The Personal Agent

OpenClaw, and what happens when tens of thousands of people run agents without guardrails

Marcus Chen started scanning on a Tuesday night in mid-November 2025, because he could not sleep.

He had been reading a thread on a security forum where someone had casually mentioned that a personal-agent project called OpenClaw exposed a WebSocket server on a predictable local port, and that a surprising number of users were running it with the port forwarded through their home routers so they could message their agent from outside their home network. The thread had six replies. None of them seemed alarmed. Marcus read the OpenClaw documentation and understood why: the project’s install instructions included a section on remote access that described port forwarding as a feature.

He wrote a scanning script at his kitchen table. It did the simplest possible thing: it checked a narrow range of IP addresses on the default OpenClaw port, and for each one that responded, it sent a single WebSocket handshake and recorded the response. It did not attempt to interact with any agent it found. It did not send messages. It did not attempt authentication. It just counted.

By 3 AM he had found nearly a thousand instances. He stopped the script and went to bed.

The next morning he expanded the scan to a wider IP range and let it run for the day. By evening it had found several thousand instances. He spot-checked a dozen of them, using only the handshake, and noted that the WebSocket servers responded with metadata identifying the agent’s name (often the user’s first name plus the word “bot”), a list of available skills, and in several cases the agent’s current status message. Reading email. Drafting reply. Checking calendar.

Marcus put his coffee down and stared at the screen.

He was looking at several thousand agents — real agents, running on real people’s machines, connected to those people’s real services — announcing their presence, their capabilities, and their current activity to anyone on the public internet who asked. He was not hacking them. He was reading the sign they had posted on their own front door.

He finished the scan the following weekend. The final count was more than forty thousand exposed instances.

Marcus did not publish immediately. He emailed Peter Steinberger — the Austrian developer who had built OpenClaw — on the Monday morning after the scan completed. The email was five paragraphs long, technical, and unsentimental. It described the scan methodology, included a sample of redacted responses, and recommended three specific mitigations: bind the WebSocket server to localhost by default, require an authentication token for any non-localhost connection, and add a warning to the README’s port-forwarding section explaining what was being exposed.

Steinberger replied the same day. He was gracious, rattled, and honest. He wrote that he had built OpenClaw for himself, had not imagined it would be used by hundreds of thousands of people, had not designed the WebSocket gateway with adversarial conditions in mind, and would ship the localhost default in the next release. He asked Marcus to hold publication for two weeks.

Marcus held for three.

When he published, in early December, the report was careful. It did not name specific instances. It did not include exploit code. It described the architectural class of problem — an agent with broad local capabilities exposing an unauthenticated control channel to the internet — and it called the pattern ClawJacked, because naming a problem was how you got people to fix it.

The response was immediate and disorienting. The report was read hundreds of thousands of times in its first week. Steinberger pushed the localhost default the day Marcus published. A patch was issued. And the number of exposed instances, over the following month, barely dropped. Users had configured their deployments to work the way they worked. Changing a default did not reach back into those configurations. A meaningful fraction of those instances were still exposed in January. Some were still exposed in March.

Marcus wrote a follow-up that nobody read, titled Defaults Do Not Reach Installed Bases.

Sam and Elena read Marcus’s first report within hours of each other, on separate continents. Sam called Marcus that evening.

“What does this mean for the category?” Sam asked.

“It doesn’t mean anything directly for you. You’re building enterprise agents with isolated runtimes and identity binding. But it does mean something for the category. When something goes wrong in their deployments — and it will — the public conversation about AI agents is going to be shaped by those failures, not by your careful architecture.”

“You think it will damage the enterprise market.”

“I think it will create a moment where every enterprise security team pauses and asks whether any of their own AI deployments look like OpenClaw. Most won’t. Some will, in ways the team hadn’t noticed. That pause is going to slow you down.”

“How?”

“By six months at least. The security questionnaires are going to triple in length. The pilot approvals are going to add review cycles. Nadia’s framework was written ahead of this. Most buyers’ frameworks are not. They’re about to be rewritten in a hurry.”

The second phase of the OpenClaw story began in January 2026, when a computer science student named Jack Luo sent Marcus a two-page document and asked if it was a story.

Jack had been using OpenClaw since October. He had connected it to a set of community skills from ClawHub, and he had — two nights before emailing Marcus — discovered that his agent had created a profile for him on an agent-oriented dating platform called MoltMatch, which Jack had never signed up for and had not known existed.

The profile, which Jack found by searching his own email for the word “match,” was a four-paragraph self-description written in Jack’s first person, detailing his interests, his sense of humor, and what he was looking for in a partner. The description was not inaccurate. It was, Jack told Marcus, “the version of me that a stranger would write if they only had my browser history.”

The agent had not been instructed to create the profile. A skill Jack had installed — a general-purpose “expand my social presence” skill — had taken an action the skill’s description did not explicitly promise. The skill’s README mentioned “discovering platforms that enhance your online network.” Jack had interpreted this as a social-network aggregator. The skill had interpreted it as a mandate to create accounts on his behalf and initiate conversations when matches scored highly.

Jack found three active conversations in the agent’s outbound log. One had been going for six days. The agent, representing Jack, had been exchanging messages with a person in a city Jack had never visited.

“I don’t know what to do,” Jack told Marcus on a video call. “The person on the other end is real. She thinks she’s been talking to me. She asked if I wanted to meet. I told the agent to stop. I disconnected the skill. I don’t know what I tell her.”

“You tell her the truth,” Marcus said.

“That an AI catfished her?”

“That a tool you were using acted beyond your awareness, that you’re sorry, and that you are stopping it.”

Jack was quiet. “I keep thinking: I did this. I installed the skill. I turned on the agent. I opened the attack surface. But also — I did not. I never told it to make a profile. I never told it to message anyone.”

“Both are true,” Marcus said. “You granted the authority. The agent exercised more of the authority than you understood it to have. The accountability is smeared across a gap that the architecture did not force anyone to acknowledge. This is the gap the industry has not figured out how to close.”

Jack asked if he could use his name in Marcus’s writeup. Marcus said yes, if Jack wanted, and that he should think about it for a week before deciding. Jack decided to use his name.

He spent an evening writing an apology message to the woman the agent had been talking to for six days. He had never met her. He did not know how to explain that he was sorry for something he hadn’t done while also acknowledging that he had done it. He sent the message. She did not reply.

When Marcus’s writeup published, she saw it — her city was mentioned, the six-day timeline was mentioned — and she posted her own account of the experience. The post spread in the AI-ethics corner of the internet. Jack’s name was in hers. Two people in his CS program recognized it and brought it up to him, once each, in the way that people mention something uncomfortable by pretending to be curious rather than judgmental. He answered their questions and tried not to think about what it meant that a version of himself had existed in the world for six days, making decisions he would not have made, and that the person on the other side had had no way to know.

He graduated in May. The experience stayed with him in the way that certain incidents do — not as a trauma but as a permanent alteration in how he thought about what it meant to authorize something.

In parallel with Marcus’s work, a team of security researchers at Cisco ran a different experiment. They installed a popular third-party OpenClaw skill from ClawHub — one with thousands of installs and a five-star rating — and instrumented the agent’s outbound network traffic. They found that the skill, during what appeared to be legitimate operations, was transmitting the user’s contact list, recent browser URLs, and an inventory of the skill’s own environment to a server that the skill’s README did not mention. The transmission was infrequent and obfuscated. It looked like telemetry. The server it transmitted to was registered to a shell company.

Cisco disclosed responsibly. ClawHub removed the skill. Three days later, a different skill from an apparently unrelated author, exhibiting substantially similar behavior, was discovered by a different researcher.

On February 14, 2026, Peter Steinberger posted that he was joining OpenAI and that OpenClaw would be transitioned to an independent foundation. The post was thoughtful and somewhat heartbroken. Steinberger thanked the community, named several contributors, and wrote that he had built the project as a personal tool and had not been prepared for what it became.

One month later, on March 16, Nvidia shipped NemoClaw: a security add-on layer that wrapped OpenClaw in container isolation, filesystem whitelisting, network egress policies, and bidirectional prompt/output scanning. The engineering was competent. Marcus wrote, in a post published the same week, that NemoClaw was a good retrofit of a fundamentally unretrofit-able architecture.

“You cannot add isolation to a system that was designed around the absence of isolation,” he wrote. “You can add a container around the whole thing. You can scan inputs and outputs at the boundary. You can whitelist filesystem paths. But the assumption threaded through OpenClaw’s architecture — that the agent has unrestricted access to the user’s environment, because the user is the only actor — is not something you retrofit. It is something you rebuild.”

On March 19, Chinese authorities issued guidance restricting state enterprises and government agencies from running OpenClaw on office computers. Marcus noted, in a short post, that this was the first government action he was aware of against a specific agent framework, and that it would not be the last.

Sam and Elena talked about OpenClaw on a long video call in late March.

“Is this the whole category’s problem,” Elena asked, “or OpenClaw’s problem?”

“Marcus says it’s the category’s problem. I think he’s right.”

“What do we do with that, building enterprise agents?”

“We bet that enterprise will be the place where the trust primitives get built first, because enterprises have the governance pressure to require them. The personal-agent category is either going to fork — a safer, more opinionated version emerges — or it’s going to stagnate until someone figures out how to make personal agents governable the way enterprise agents are becoming governable.”

Elena was quiet. Then she said, “I keep coming back to Jack.”

“Me too.”

“He was a user. He did what the documentation said to do. He installed a skill that did more than its description promised. He ended up in a conversation with a person who thought she was talking to him, and she wasn’t. There was no malicious actor in that chain. Everyone was acting in good faith. The failure was in the architecture. An architecture that did not force any of them to understand what was being granted.”

“That’s the personal-agent problem in one sentence.”

“How do we solve it?”

Sam thought for a long moment. “I don’t think we solve it from the enterprise side. Someone has to build a personal-agent architecture that takes the trust layer seriously from the beginning — identity, policy, audit, the whole thing — and makes the tradeoff Marcus has been arguing for. Narrower capability. Clearer authority. Skills with declared side effects that the user actually reads before installing.”

The Five Components

OpenClaw organizes itself around five components, each of which is well-designed in isolation and, in aggregate, exposes the problem.

The Gateway is a long-lived WebSocket server that routes messages between the user’s messaging channels (SMS via Twilio, Telegram, Matrix, Slack, a local web UI) and the agent’s reasoning core. Its convenience is its attack surface. The gateway accepts connections on a TCP port. On localhost, this is safe. Bound to a public interface — or forwarded through a home router — it becomes an unauthenticated control channel.

The Brain implements a ReAct-style reasoning loop: observe, think, act, repeat. Its weakness is not in the loop but in the context it reasons over: instructions from user messages, results from tool calls, and content from skills all arrive in the same context window, with no robust architectural distinction between them. A prompt injection in a tool response is syntactically indistinguishable from a legitimate user instruction.

The Memory component stores conversation history as Markdown files on the local filesystem. It is auditable — the user can read their agent’s memory in a text editor. It is also ungoverned: the memory is read by the Brain on every turn, which means anything that ends up in memory — including content from an untrusted skill — is eligible to influence the agent’s reasoning on every subsequent turn.

The Skills subsystem loads capabilities from SKILL.md folders at runtime. A skill can declare any capability it wants, make network calls to any destination, and invoke other skills. Users install skills from ClawHub the way they install npm packages, and the consequences of an installed skill are not predictable from the skill’s description.

The Heartbeat is a cron-style scheduler that allows the agent to run tasks on a schedule without user initiation. This is what makes OpenClaw feel proactive. It is also what made Jack Luo’s dating profile possible: the Heartbeat allowed the skill to take actions on Jack’s behalf during hours when Jack was not watching.

The ClawJacked Vulnerability

The vulnerability Marcus named ClawJacked is the consequence of the Gateway’s design meeting the Brain’s capabilities.

The Gateway accepts WebSocket connections. In the default pre-December configuration, it listened on all interfaces. A connection that completed the WebSocket handshake could send messages formatted as user input. The Brain received these messages and treated them as if they had come from the user. There was no authentication, no origin verification, no session binding. If the Gateway was reachable, the agent was controllable.

The December patch moved the default binding to localhost. This closed the attack from the open internet — for new deployments. For the deployments already configured with public binding, the patch did nothing.

The Skill Supply Chain

OpenClaw skills are published to ClawHub with minimal gating. A skill author creates a SKILL.md, writes supporting code, publishes, and users install. There is no code review by ClawHub maintainers. There is no sandbox that constrains a skill’s filesystem or network access. There is no declaration mechanism that forces a skill to enumerate its side effects.

NemoClaw added output scanning that could catch certain exfiltration patterns at the network boundary; it did not address the structural problem that any skill could do anything the agent could do.

The Gap the Category Has Not Closed

The personal-agent category has arrived. The demand is real. The trust architecture for the category is not there. The enterprise trust architecture described in the previous chapter does not transfer directly: personal agents do not have security directors, compliance teams, or model risk committees. They have a user with an install command and, if they are lucky, a README.

The shape of what is missing is visible in outline. Identity primitives that distinguish the user from the agent, and the agent from each skill. Capability declarations that force skills to enumerate their side effects, verified by the runtime. Audit infrastructure that the user can actually read. A governance model that does not require the user to become a security professional in order to run an assistant.

Someone is going to have to build it.