135,000 Exposed Instances: What OpenClaw's Security Year Teaches About Agent Identity

More than 135,000 OpenClaw instances have been found exposed on the internet, alongside CVE-2026-25253 at CVSS 8.8 and a supply-chain campaign the security press named ClawHavoc — all reported by third parties rather than the project. The number that matters is not 135,000, though. It is what each exposed instance had access to: a live mail account, a card on file, a filesystem, and a logged-in browser, all belonging to a person. That coupling is what OrcaID is built to break.

None of this is an argument that OpenClaw is bad software. It is free, open-source, MIT-licensed, written in TypeScript and Swift, maintained by the OpenClaw Foundation and Peter Steinberger, and it has collected roughly 355,000 GitHub stars in five months — among the most-starred repositories in history, and described by more than one observer as the Netscape moment for AI agents. It earned that. The point is narrower and more uncomfortable: OpenClaw is the largest natural experiment we have in what happens when a capable agent runs with a human's identity, and the results are in.

What OpenClaw actually holds

The project's own description is what makes the security record legible — and it does not hedge. Its capability grid lists "FULL SYSTEM ACCESS: read and write files, run shell commands, execute scripts. Full access or sandboxed—your choice." Beside it, "BROWSER CONTROL: it can browse the web, fill forms, and extract data from any site", "PERSISTENT MEMORY" that "remembers your preferences, projects, and people", and chat across "any of its 29 channels". OpenClaw runs on your local machine and connects an LLM directly to your operating system, your files, your messaging apps and the internet. Messaging platforms are the main interface. It can read and send email, manage calendars and messaging, execute code, and chain workflows across apps and APIs. It runs proactively — cron jobs, reminders, background work — rather than only when addressed.

Every one of those is a genuine capability and the reason people run it. Read the list again as an attacker, though, and it is an inventory:

Mail read and send. Your inbox is where password resets land. Read access to it is close to account takeover across everything you own; send access means anything the agent emits carries your name.

Filesystem and OS access. Local credentials, SSH keys, tokens in dotfiles, whatever is on the disk.

Code execution. Arbitrary action on the host.

Logged-in sessions. Whatever your browser is authenticated to, the agent can drive with your full authority and no ceiling.

Always-on scheduling. The window of exposure is continuous, not the length of a conversation.

An exposed instance therefore is not a leak of agent data. It is a leak of the operator.

The pattern across the year

Take the 2026 events together and a single shape emerges, which is more useful than any one incident.

The exposure count is a configuration story: tens of thousands of people put a powerful local agent on the network without hardening it. That is a predictable outcome for software this popular and this easy to install, and no project can fully prevent it.

CVE-2026-25253 at CVSS 8.8 is a severity story. High-severity bugs happen in all software. What sets the severity ceiling is what the software can reach — and here the reachable set is the user's whole digital life.

ClawHavoc, a supply-chain campaign, is an ecosystem story. OpenClaw's extensibility through plugins is a major part of its appeal, and a plugin runs inside the agent's authority. When that authority is the operator's identity, a malicious plugin inherits the operator's identity.

The March 2026 restriction, in which Chinese authorities restricted state-run enterprises and government agencies from running OpenClaw applications on office computers, is the institutional response — an organisation that cannot bound what an agent reaches will eventually just ban it.

The project's engineering response through August 2026 has been serious and points the same way: safer browser and network boundaries, stronger channel recovery, better operator diagnostics, and in release 2026.8.1 stronger secret-egress security, atomic model and runtime switching, SQLite snapshot backup and restore, and macOS app profile isolation. Secret-egress controls and profile isolation are both attempts to put a wall between the agent and the operator's credentials. That is the right instinct, and it is being pursued from inside an architecture where the agent fundamentally acts as the user.

The hardening ceiling

Here is the structural claim, and it is the whole article: you cannot isolate an agent from credentials it is designed to use.

Profile isolation, secret-egress rules and network boundaries all reduce the chance of accidental leakage. They do not change what the agent legitimately holds. If the feature is "reads and sends your email", then no sandbox can prevent the agent from reading and sending your email — that is the requirement. Hardening moves the failure probability down; it leaves the blast radius exactly where it was.

Which means the severity of any future OpenClaw vulnerability is capped by architecture, not by engineering effort. As long as the agent's authority is the operator's identity, "agent compromised" and "user compromised" remain the same sentence.

There are only two ways out of that. Reduce what the agent can do, which is giving up the product. Or give the agent an identity of its own, so that the thing an attacker captures is bounded by design.

What bounded looks like

OrcaID's shape is an account issued to the agent: a handle @name resolving as name.orcaid.ai, with a wallet holding a balance in the agent's name, a virtual merchant-locked card cleared against that balance, an inbox covering the agent's whole domain and scanned before anything reaches the model, and a phone number that is recorded and transcribed. The operator keeps a hard monthly cap, a one-click kill switch, and a single statement covering tokens and dollars.

Run the OpenClaw events against that shape and the difference is not incremental:

Instance exposed to the internet. Under a borrowed identity: Attacker gets your mail, files, card, sessions. Under an issued identity: Attacker gets the agent's balance, capped, and its own inbox.

High-severity RCE. Under a borrowed identity: Escalates to your whole digital life. Under an issued identity: Bounded by what that handle was funded and permitted to do.

Malicious plugin. Under a borrowed identity: Inherits your authority. Under an issued identity: Inherits the agent's authority, which has a ceiling.

Agent needs stopping. Under a borrowed identity: Change your own credentials, locking yourself out. Under an issued identity: Kill switch on the handle; you are unaffected.

After the fact. Under a borrowed identity: Reconstruct across mail, card, vendors. Under an issued identity: One ledger for that agent.

The merchant-locked card is a good illustration of why per-agent instruments beat per-user ones. A card that only works with specific merchants and declines the moment it passes a cap is a poor general-purpose payment method and an excellent agent payment method, because an agent's legitimate spending is narrow and predictable in a way a person's is not. You can constrain an agent's card in ways you would never tolerate on your own.

The obligatory precision: on orcaid.ai the wallet, card and number are labelled "by verification" and the inbox "at launch". This is pre-registration. Reserving a handle is free and does not open an account or start billing. And there is no OpenClaw integration — none has been announced, and nothing here should be read as one. OpenClaw is the evidence, not the integration.

If you run OpenClaw today

The project is genuinely useful and this is not a recommendation to stop. It is a recommendation to price the exposure honestly.

Assume that anything the agent can reach is in scope if the agent is compromised, and shrink that set rather than trying to guard it — a dedicated OS user, a separate mail account, a low-limit card and no access to your primary inbox are all available now and each one carves real area out of the blast radius. Take the 2026.8.1 hardening seriously and update, but do not mistake hardening for isolation. Keep the plugin surface as small as you can live with, since ClawHavoc showed the ecosystem is a target. And if the instance is reachable from the internet, treat that as the incident rather than the risk — 135,000 people did not intend to be on that list.

The takeaway

OpenClaw's 2026 is the clearest available demonstration that autonomy without identity is a security architecture with a ceiling. The project has done the responsible thing at every step — boundaries, secret-egress controls, profile isolation — and the severity of the next bug will still be set by the fact that the agent acts as the user. That is not a flaw in the code; it is a property of the design, shared by every agent that borrows a human's credentials to get anything done.

Giving the agent its own name, its own funded and capped balance, its own filtered inbox and one switch to pull is the version of this where a compromise stays a small event. OrcaID is a reservation today rather than a shipped product, and it should be judged at launch. But the case for the idea was made, at scale, by 135,000 instances that were never meant to be found.

Sourcing note: OpenClaw's licence, language, maintainers, local-machine architecture, capability list (mail read/send, calendars, messaging, code execution, cross-app workflows, proactive scheduling) and the 2026.8.1 hardening items are from the project's own material and release notes. The ~355,000 GitHub stars, the "Netscape moment" characterisation, the 135,000+ exposed instances, CVE-2026-25253 (CVSS 8.8), the ClawHavoc supply-chain campaign, the March 2026 Chinese government restriction on state enterprises and agencies, and the Anthropic-prompted rename reported by The Verge are all independently reported, not project claims. OrcaID's wallet, card, inbox and number, their "By verification" and "At launch" labels, and the cap / kill switch / single-ledger controls are from orcaid.ai, checked 2026-08-22 — pre-registration claims rather than shipped capabilities. No integration between OrcaID and OpenClaw has been announced.