Shadow Agents: What OpenClaw Taught Security Teams
In February 2026, SecurityScorecard observed 40,214 OpenClaw instances exposed to the internet, with 35.4% flagged as vulnerable. The detail that should concern security teams is that very few of those instances belonged to a sanctioned deployment. Most companies that found OpenClaw on their network never decided to put it there.
OpenClaw is the best-known example of a self-hosted open agent runtime: software that runs on a laptop, a VM or a container with access to the shell, the file system and the browser, using whichever model the person who installed it prefers. These runtimes are genuinely capable, which is why engineers install them. They also ship with limited built-in security controls, which is Microsoft's own plain description of OpenClaw, and they usually arrive with no owner, because they start as shadow IT.
The problem changed shape in about a year
In 2024, the shadow AI problem was staff pasting company data into consumer chatbots. The exposure was real but bounded: data left the building, and the fix was policy, training and blocking a few domains.
The 2026 problem is different in kind. Self-installed agent runtimes and local MCP servers hold real credentials, and they act. An agent with shell access and a saved API key can read files, operate a browser and send things outside the company. OpenClaw went from launch in late 2025 to tens of thousands of exposed instances within weeks, which tells you how fast an individually installed tool can spread ahead of any review process.
Microsoft's security team describes the core issue precisely: the execution boundary has shifted from static application code to dynamically supplied content and third-party capabilities, without matching controls on identity, input handling or privilege. In practice that means the thing deciding what happens next on the machine is no longer code your team reviewed. It is whatever content the agent read most recently.
Prompt injection cannot be fully patched, so defense has to assume hostile input will reach the agent eventually. Any agent that can read private data, take in untrusted content and send things outside the company needs a check that does not depend on the model behaving.
What security teams took from the episode
Three lessons stand out from how the organizations we work with responded.
First, discovery comes before policy. You cannot write a useful rule about software you have not found. The companies that handled this well started by looking: endpoint inventories, the identity provider's application list, expense reports with AI subscriptions on them. Most found more than they expected, and not only OpenClaw.
Second, the credentials matter more than the runtime. The dangerous part of a shadow agent is rarely the agent itself. It is the API keys, tokens and session cookies it was given, often stored in plain config files under a personal account. Moving agents onto their own scoped, revocable credentials, and getting shared keys out of config files, removes most of the blast radius even where the runtime stays.
Third, a flat ban does not hold. Engineers install these tools because they work. The organizations that only said no found the same tools reinstalled a quarter later. The ones that offered a sandboxed, IT-run environment for experimentation kept the curiosity away from production credentials while keeping the learning.
Scheduled tasks need their own monitoring. A prompt injection that creates or alters a recurring task persists silently: the attacker does not need to succeed twice, because the schedule keeps firing on its own. Treat the creation of a scheduled task, by any agent or assistant, as a security event worth logging and reviewing, the same way you would treat a new mail-forwarding rule.
Where this is heading
Our expectation is that by the end of 2027, self-hosted runtimes like OpenClaw will be banned on managed endpoints at most regulated firms, and will survive in sandboxed, IT-run form for engineering teams. The capability is too useful to disappear and too sharp to run unmanaged next to production credentials. The buying signals point the same way: in CrewAI's survey of 500 senior executives at large enterprises, security and governance ranked first among platform selection factors at 34%, ahead of integration at 30%, with time to value last at 2%.
For most organizations the practical sequence is short. Find what is already running, including the installs nobody approved. Give every sanctioned agent its own identity and scoped credentials. Put a sandbox in place so experimentation has somewhere safe to go. Then decide, workload by workload, what belongs on a governed platform instead of someone's laptop.
The full analysis of all five deployment patterns, and the nine controls that apply to every one of them, is in our white paper, Deploying AI at Scale.