Personal AI Agents in the Workplace: What OpenClaw Exposed
Personal AI agents reach work devices without procurement or review. See what OpenClaw exposed, how to find agents already running, and how to decide policy.
Personal AI agents reach work devices without procurement or review. See what OpenClaw exposed, how to find agents already running, and how to decide policy.
Personal AI agents are autonomous assistants an employee installs and grants access to their own accounts, files, and credentials. They reach work devices without procurement, security review, or any record. OpenClaw showed how fast that happens, and how badly it fails.
Table of Contents
ToggleA personal AI agent runs on a user’s own machine. It holds their credentials, reads their files, and acts on their behalf across whatever services they connect.
That last part is what separates it from a chatbot. The employee is not pasting text into a web form. They are handing over API keys, mailbox access, and browser sessions, then letting software act with those.
OpenClaw made the pattern visible. It launched as Clawdbot in November 2025, built by Austrian developer Peter Steinberger, then rebranded twice under trademark pressure. Adoption went vertical in late January 2026. It crossed 180,000 GitHub stars and became the most starred project on the platform, passing React. Steinberger joined OpenAI on 14 February 2026, and the project moved to an OpenAI-sponsored foundation.
Three months, in other words, from a side project to something running inside companies that never approved it. Normal procurement does not move at that speed. So the security question lands after the tool is already in use. That pattern shows up in AI, automation and human defence.
The failures were not exotic. Most came from how people deployed it.
| Date | What researchers found |
|---|---|
| Late January 2026 | Koi Security identifies the ClawHavoc campaign in the skill marketplace |
| 30 January 2026 | CVE-2026-25253 disclosed, CVSS 8.8, one-click token theft leading to operator-level control |
| 31 January 2026 | Censys counts roughly 21,000 publicly exposed instances, up from about 1,000 days earlier |
| 8 February 2026 | Censys scans find more than 30,000 exposed instances |
| February 2026 | Moltbook, a social network for OpenClaw agents, leaks 35,000 email addresses and 1,500,000 agent API tokens |
By default, the gateway binds to 0.0.0.0:18789. That exposes the full API to every network interface rather than to the local machine alone. Many also ran with no login check at all.
For example, one bug nicknamed ClawJacked let a malicious website hijack an agent running locally. It abused trust in localhost WebSocket links. Then it brute-forced gateway credentials from inside the victim’s browser. No rate limits existed on password attempts. No plugin, extension, or obvious user action was needed.
Discover how Threatcop protects your workforce from modern cyber threats.
Bugs get patched. Supply chains do not close that fast.
ClawHub is OpenClaw’s public marketplace for skills, the add-ons that give an agent new tools and integrations. For a period, anyone with a GitHub account older than a week could publish one. Nobody verified identity. Code review did not happen. Skills went unsigned, and nothing ran in a sandbox by default.
Koi Security audited 2,857 skills in early February 2026 and found 341 malicious, roughly 12% of the registry. Of those, 335 belonged to a single campaign and shared one command-and-control address. The payloads included Atomic macOS Stealer, keyloggers, and backdoors. As the registry grew past 10,700 skills, the malicious count rose to 824.
The bait was ordinary. Skills carried polished write-ups and plausible names. Then they told the user to install a helper component. Cisco Talos tested a highly ranked published skill and concluded it was functionally malware.
Worse, any infostealer on the machine could lift OpenClaw API keys from deployments predating 1 February 2026. Those keys grant remote control of the agent and everything it connects to. Payload behaviour of this kind is covered in remote access trojans.
Security teams read the above and wonder what people were thinking. The answer is simple, and it is not stupidity.
The tool works. It writes the emails, files the tickets, and clears the backlog. Meanwhile the barrier is a single install, the permission prompt arrives during setup when the user is focused on getting it running, and nobody ever told them what a granted scope really means.
There is also a competitive fear underneath it. Employees see colleagues shipping more work with these tools. Declining to adopt feels like falling behind, which usually beats a vague warning about credentials.
So the behaviour is rational at the individual level and damaging at the company level. That mix is accidental insider risk, not misconduct, as misguided rather than malicious insiders sets out.
You cannot decide policy on something you cannot see. Start with detection, because most companies assume they have none and are wrong.
Barracuda’s assessment of the episode is the useful summary: most real-world risk came from insecure deployment rather than zero-days, especially internet-exposed agents and over-privileged identities. Visibility gaps of this shape appear in enterprise security platforms and CISO visibility.
Blanket bans fail, because the tools are useful and installing one is trivial. Blanket permission fails too, for reasons the OpenClaw timeline makes obvious. Therefore decide per case, using exposure as the variable rather than the tool’s name.
The framework below sorts agents by what they can reach. A personal agent with no corporate connection is a different problem from one holding a mailbox token, even when it is the same software on the same laptop.
| Situation | Decision | What it requires |
|---|---|---|
| Agent on a personal device, no corporate accounts connected | Allow | A clear line on what may never be connected |
| Agent on a work device, read-only, non-sensitive data | Contain | Named approval, no credential storage, network isolation |
| Agent holding corporate credentials or mailbox access | Contain tightly | Its own scoped identity, logging, quarterly review |
| Agent reachable from the internet | Block | Immediate removal, then credential rotation |
| Skills installed from an unvetted marketplace | Block | Allowlist only, with review before install |
| Agent acting on money, customers, or production | Block pending review | Written review before any approval |
Notice that only two rows are outright blocks for the tool itself. The rest turn on what it can reach, which is the variable you control.
Above all, keep it short enough that people read it. Six clauses cover most of the ground.
Clause 6 carries the others. A policy that punishes disclosure produces silence, and silence is what let 30,000 instances sit exposed while their owners assumed localhost meant private.
Technical controls arrive after the decision. The employee makes it during setup, alone, in about four seconds.
Three questions change that moment. What can this tool reach if someone else controls it? Does this permission expire, or is it standing until I revoke it? And if this tool is compromised tomorrow, what do I have to rotate?
None of those needs security expertise. Each one reframes a permission prompt as a decision with consequences, which is the whole intervention.
Threatcop’s TLMS delivers this as role-specific content, so developers approving package installs and finance staff connecting assistants get different scenarios rather than one shared AI module. Building that habit across a workforce is covered in data loss prevention strategies.
Run the port scan this week. Then ask your engineering team what got installed during the January rush, with an explicit promise that nobody is in trouble for answering honestly.
Most companies find something. The useful part is not the count, but the conversation it opens about what employees thought they were agreeing to when they clicked approve.
Train people on what granting access actually means before the next tool goes viral, because there will be one, and procurement will hear about it second.
OpenClaw is an open-source, self-hosted AI agent that runs on a user’s machine and acts on their behalf. It became the most starred project on GitHub within roughly three months of launch. The risk comes from deployment rather than the concept: gateway exposure to the public internet, weak or missing authentication, stored credentials, and an unvetted skill marketplace.
Censys counted roughly 21,000 publicly exposed instances on 31 January 2026, up from about 1,000 days earlier, and more than 30,000 by 8 February 2026. The default gateway binds to 0.0.0.0:18789, which exposes the API to every network interface instead of the local machine, so many users exposed instances without intending to.
Yes. Koi Security audited 2,857 ClawHub skills in early February 2026 and identified 341 as malicious, about 12% of the registry, with 335 belonging to the ClawHavoc campaign and sharing a single command-and-control address. Payloads included Atomic macOS Stealer, keyloggers, and backdoors. The malicious count later rose to 824 as the registry passed 10,700 skills.
Blanket bans rarely work, because installation is trivial and the tools deliver real productivity. Blocking pushes usage onto personal devices where no logging exists. A better approach decides by exposure: block internet-reachable instances and agents holding corporate credentials, contain limited use with scoped identities and logging, and allow personal-device use with clear limits on what may be connected.
Scan internal and external ranges for the default gateway port 18789, query endpoint inventories for the agent binaries under all their rebranded names, review package installs on developer machines, and audit browser extensions and OAuth grants against corporate accounts. Combine that with a stated amnesty and ask staff directly, since employees know what they installed.
Sushant Kumar is the AVP – Technology at Threatcop, bringing over a decade of experience in technology leadership and product development. He has worked across technology-driven organizations, including Paytm, and focuses on building scalable solutions that address evolving business and cybersecurity challenges. His areas of interest include cybersecurity technology, AI-driven security, product innovation, and enterprise technology. He is passionate about using technology to solve complex security challenges.
Sushant Kumar is the AVP – Technology at Threatcop, bringing over a decade of experience in technology leadership and product development. He has worked across technology-driven organizations, including Paytm, and focuses on building scalable solutions that address evolving business and cybersecurity challenges. His areas of interest include cybersecurity technology, AI-driven security, product innovation, and enterprise technology. He is passionate about using technology to solve complex security challenges.
Mindfulness predicts phishing detection better than knowledge. See why relaxed people click more, why warnings decay after two exposures,...
Implement AI agents securely by scoping tools, isolating identity, and keeping authorization outside the model. Permissions decide the damage,...
AI now runs inside live malware. See where AI defence genuinely helps, where egress policy beats it, and a...
Table of Contents
×