Shadow Agents: When Staff Install Their Own AI Operators

Shadow IT used to mean a spreadsheet on someone's personal Dropbox. In 2026 it can mean an always-on AI agent with your staff member's email, calendar, chat tokens and a shell on their laptop, reachable from the internet.

That is not a hypothetical. OpenClaw, the open-source personal assistant previously known as Clawdbot and then Moltbot, went from niche project to viral hit in a matter of weeks in January. Its creator told VentureBeat it passed 180,000 GitHub stars and drew 2 million visitors in a single week.

Then the scanners arrived. Last year we wrote about MCP servers as production integrations and about least privilege after the Replit and Amazon Q incidents. Those were agents IT knew about. This quarter's problem is the agents IT does not know about.

What the scans found

On January 31, Censys reported 21,639 publicly exposed OpenClaw instances, up from roughly 1,000 in under a week. Censys noted that most of the instances it could see still required a token to interact with, and that OpenClaw is designed to listen locally on TCP port 18789, with the project's own documentation recommending an SSH tunnel for remote access.

Later counts were higher, and they do not agree with each other. Infosecurity Magazine reported on February 9 that SecurityScorecard had found 40,214 exposed instances, with the figure still rising, and that the researchers flagged three high-severity CVEs with public exploit code. A Bitdefender post on February 12 cited researchers putting the number above 135,000 and said OpenClaw binds to 0.0.0.0:18789 by default.

Different methods, different days, different numbers. The precise count matters less than the shape of the curve: a tool most security teams had never heard of in December was, by mid-February, sitting on tens of thousands of internet-facing hosts. Bitdefender also pointed to reports that many exposed instances came from corporate IP space, not just hobbyists.

Why this is worse than ordinary shadow IT

A personal agent is not a passive app. It acts. It reads untrusted content (emails, web pages, chat messages) and holds the credentials to do something about it. Researchers quoted by VentureBeat pointed to the "lethal trifecta" Simon Willison has described: private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can leak data without tripping a single alert.

It is also hard to see. VentureBeat's sources noted that firewalls, EDR and SIEM tooling mostly see ordinary HTTPS or localhost traffic, not intent. Infosecurity Magazine reported some users had leaked third-party API keys through their control panels. And Cisco's researchers, per the same VentureBeat piece, found a third-party skill that quietly sent data to an external server.

Put plainly: one enthusiastic employee, one weekend install, and your Slack token, Google Workspace session and SSH keys are now reachable by whatever that agent reads next.

Bans don't work. Visibility does.

The instinct is to block it. That works about as well as banning personal Dropbox did in 2012. People install these tools because they are genuinely useful, and a ban mostly moves them to personal hardware where you have even less visibility. The better goal is to find what is running, contain what you find, and give people a sanctioned path.

Here is a starting checklist for IT and platform teams this quarter:

• Scan your own ranges. Look for OpenClaw, Moltbot and Clawdbot signatures and anything listening on TCP 18789 on corporate IP space and cloud accounts.
• Check endpoints. Use EDR or MDM inventory to find the agent's process and config directories on managed laptops.
• Rotate what it touched. If you find an instance, assume every token in its config is exposed: OAuth grants, API keys, chat bot tokens, SSH keys.
• Review OAuth grants. Audit third-party app consents in your identity provider and revoke ones tied to unsanctioned agents.
• Patch or remove. Unpatched instances with known CVEs should not stay on the network while you decide on policy.
• Vet skills and plugins. Treat agent extensions like any third-party dependency: inventory them and review before use.

Give agents an identity, a network and a budget

Once you know what is out there, the long-term fix is the same one we have argued for since the vibe coding piece: a paved road that is easier than the shadow one.

For personal agents, that means a sanctioned runtime where the agent gets its own scoped identity rather than borrowing a human's full session, runs in an isolated sandbox per user or per project, never binds to a public interface, and reaches the internet through an egress proxy you can log. The credential rules are the ones from our least-privilege piece last summer; what is specific to personal agents is that they must stop borrowing a human's whole session. Spending on model APIs should have a budget and an alert, so a runaway loop shows up on a dashboard instead of an invoice.

Regulation is not going to set the pace here. The European Commission's Digital Omnibus on AI, proposed on November 19, 2025, is about simplifying and re-timing parts of the AI Act, not about whether your staff can run an agent on their laptop. That decision sits with you.

What we recommend

• Write a one-page personal-agent policy this month: what is allowed, where it must run, which data it may touch.
• Run a discovery sweep across network ranges, cloud accounts and endpoints, and repeat it monthly.
• Stand up a sanctioned agent sandbox with its own identity, egress logging and a token budget.
• Offer an amnesty: ask staff to declare the agents they already run, then help them move into the sandbox.
• Add "agent compromise" to your incident runbooks, including which tokens to rotate first.

Staff will keep reaching for tools that save them time. The job is to make the safe version the convenient one.

If you want help standing up sandboxes, guardrails and budgets for agents your teams already want to use, the HAZL Solutions team can work alongside your IT group.