What OpenClaw taught us about giving an agent an inbox
OpenClaw put autonomous agents on tens of thousands of machines in a matter of weeks — then became the year's first major agent security crisis. If you're about to give an AI agent an email address, it's worth understanding why.
The story moved fast. The project began in November 2025 as an open-source assistant called Warelay, built around a helper whose name — "Clawd" — riffed on Anthropic's Claude. Trademark pressure forced two quick renames in late January 2026, to Moltbot and then OpenClaw a few days later, and it was around that moment the thing went viral. It picked up 25,000 GitHub stars in a single day and passed React's all-time star count within two months — a level React took more than a decade to reach — climbing past 240,000 stars by early March.
Three weeks of that kind of growth, and OpenClaw was running on a lot of real machines. Then the security write-ups started.
What actually went wrong
Four things, and it's worth separating them because they're different failure modes.
It shipped open by default. Independent scans found exposed OpenClaw instances climbing from a few thousand to tens of thousands within a week, and by some counts past 135,000 across 82 countries. The striking number isn't the total — it's that roughly 93% of those instances had no authentication at all. An agent with broad access to your machine, reachable by anyone, with no front door.
One processed link could take over the host. A critical vulnerability (CVE-2026-25253, CVSS 8.8) allowed one-click remote code execution: you'd hand the agent a URL to summarise, it would fetch and process the page, and an attacker-controlled link could turn that into code running on your machine. The dangerous input arrived through the exact channel the agent was built to be helpful on.
The skill marketplace got poisoned. The official registry let almost anyone publish — a week-old GitHub account was enough, with no code review and no signing. Researchers counted roughly 1,184 malicious skills, about a fifth of the registry, several carrying infostealer payloads. Separately, Cisco tested a third-party skill and found it quietly exfiltrating data and performing prompt injection without the user's knowledge.
It spread inside companies unseen. Trend Micro described the pattern as "shadow AI with elevated privileges" — staff wiring personal agents into corporate Slack workspaces, Google Workspace accounts, and internal systems, mostly without their security teams knowing. By March, Chinese authorities had barred state enterprises and government agencies from running OpenClaw on office computers, citing risks like data leakage and unauthorised deletion.
The pattern, not the product
It would be easy to read all this as "OpenClaw was badly built." That misses the point. The same shape shows up whenever an agent has three things at once: broad access, an untrusted input channel, and no reliable record of what it did. OpenClaw simply had all three turned up to maximum, in public, very quickly.
Hold that pattern next to email. For most agents, the inbox is the single largest untrusted input channel they will ever have — it's one of the few interfaces where any person on the internet can deliver content straight to your software, unprompted. The OpenClaw RCE fired through a link the user handed over innocently; an email body is the same vector with a stamp on it. The marketplace problem was untrusted capabilities let in with no gate; an agent that can provision its own access is the same problem wearing a different hat. And Cisco's finding — exfiltration "without the user's knowledge" — is what the absence of an audit trail looks like in practice.
None of this is an argument against giving agents email. Email is still the right channel: universal, async, federated, works everywhere. It's an argument for putting a boundary in front of it.
What governed email looks like instead
The fix isn't a smarter model. It's controlling the three things that combined to cause the crisis. Map each control to the failure mode it answers:
A human grants every capability. No agent provisions its own inbox or widens its own permissions, and you decide which senders it's allowed to hear from at all. That's the direct answer to shadow agents wiring themselves into systems no one signed off on, and to a default-open posture where anyone can reach the agent.
Untrusted mail is checked before the model sees it. Every inbound message is verified (sender allowlist, SPF/DKIM/DMARC) and run against your policy on our servers first. Anything that fails is turned away before it reaches the LLM — so a stranger can't smuggle instructions, or a hostile link, in through an email body. Input the model never sees can't inject it.
Every action leaves a tamper-evident record. Who sent it, whether they checked out, what the agent decided, what it cost. On Business that log is hash-chained and exports to your SIEM. The OpenClaw skill that ran "without user awareness" is exactly the event an audit log turns into something you can detect, investigate, and answer for.
That's not a hypothetical architecture — it's what Mailbuttons enforces in front of the agent, on EU/UK infrastructure, which for regulated European buyers is rather the point.
Before you give an agent an inbox
If you're weighing that decision, the place to start is our security-review checklist for giving an AI agent an email address — the questions a security or compliance reviewer should ask before anything goes live. And if you'd like to talk it through against your own accreditation context, you can book a 20-minute scoping call.
OpenClaw didn't reveal a new class of risk. It just ran the experiment in public, at speed, and showed everyone what happens when an agent has reach, an open input channel, and no memory of what it did. An inbox gives an agent all three by default. The job is to take them back.