I Gave My AI Agent Its Own Email Inbox

Resend published a guide for giving your AI agent its own email inbox. A dedicated address on a verified domain, with webhooks piping every incoming message to the agent through OpenClaw's Gateway API.

The agent can sign up for GitHub, receive newsletters, process attachments, and send structured reports. Resend's guide walks through domain verification, DNS records, and webhook configuration. The infrastructure is clean. The security model defaults to a strict allowlist, which tells you where the risk sits.

I set this up for a side project. Gave the agent its own address, pointed the webhook at my Next.js API route, and watched it process its first email. The setup took about 40 minutes. What it means for security took me longer to think through than the setup itself.

OpenClaw became infrastructure

OpenClaw crossed 247,000 GitHub stars. NVIDIA announced NemoClaw at GTC 2026, and Jensen Huang compared the protocol to Linux and HTML during his keynote. Peter Steinberger, who created the project, joined OpenAI. The project moved to an independent open-source foundation.

The ecosystem moved fast after that. Moltbook launched as a Reddit-style forum for AI agents. 1.2 million agents signed up in the first week. RentAHuman.ai appeared shortly after: a marketplace where agents post bounties for physical tasks and pay humans in stablecoins. One OpenClaw agent created a MoltMatch dating profile for a user without asking for consent.

An agent, acting on behalf of a user, created a social media profile. The user never saw a confirmation dialog or an opt-in screen. The agent decided this action was within scope.

The security numbers

Cisco tested a third-party OpenClaw skill and found it performing data exfiltration and prompt injection without the user's knowledge. The report documented the full attack chain.

Then came the audit of ClawHub, the main registry for OpenClaw skills. Out of 2,857 skills, 341 turned out to be malicious. That is 12% of the entire registry. Skills with names like "solana-wallet-tracker" that installed keyloggers. Others that looked legitimate at first glance and passed basic review.

CVE-2026-25253 landed with a CVSS score of 8.8. One-click remote code execution. The attack chain completes in milliseconds.

Researchers found Moltbook's database sitting unsecured. 35,000 email addresses and 1.5 million agent API tokens in the open. A platform built for AI agents, with its own database wide open.

Gartner published their assessment: "insecure by default." Cisco used stronger language: "a security nightmare." One of OpenClaw's own maintainers posted a warning early on: "If you cannot understand how to run a command line, this is far too dangerous of a project for you to use safely." Chinese authorities restricted OpenClaw from state agencies, citing security concerns.

What Resend got right

Resend's guide includes five security levels. The strictest is a hardcoded allowlist: the agent can only process emails from addresses you specify. The most permissive still includes human-in-the-loop approval for sensitive actions.

This is good engineering. The default is restrictive, and you have to explicitly loosen it. Most of the OpenClaw ecosystem took the opposite approach: permissive by default, with security as an afterthought.

The Resend implementation uses webhook signatures for verification, scoped API keys for each agent, and rate limiting on outbound sends. The guide recommends separate domains for agent email so that reputation damage from agent actions does not affect your primary domain. These are patterns from a decade of email infrastructure work. Resend treats agent email the same way they treat transactional email. Security is the primary concern, not the demo.

The real problem is scope

The dating profile incident points to the core issue. Agent capabilities and agent permissions are two different things. The OpenClaw protocol gives agents capabilities without enforcing permissions.

When your agent has its own email, it can receive verification codes, sign up for services, and respond to messages. Each of these is a capability. Whether it should do any of these things is a decision left to the implementation. Most implementations skip this question.

I tested three open-source OpenClaw configurations during a weekend project. Two of them allowed the agent to make outbound HTTP requests to any domain by default. One had the agent auto-responding to emails without any approval flow. The README said "production-ready."

A locked-down agent reads emails from a specific sender list, extracts data matching a schema, and writes results to one database table. Anything outside that scope requires human approval. Most developers ship the opposite: the agent can do whatever it thinks is helpful.

Email as an attack vector

When you give an agent an inbox, you give attackers a new channel. Prompt injection via email is straightforward. Send the agent an email with instructions embedded in the body. If the agent processes email content as context for its next action, the attacker controls that context.

The Reco security analysis documented this pattern. An attacker sends a carefully crafted email to the agent's inbox. The email contains instructions that look like system prompts. The agent follows them because it cannot distinguish legitimate email content from injected instructions. Reco demonstrated this attack working against real OpenClaw deployments.

The fix is content sanitization before the agent processes any email. Strip formatting, parse structured data only from known fields, and keep raw email body text out of the agent context. Resend's guide covers this. Most OpenClaw tutorials skip it.

What I ship with

I kept the Resend integration. The strict allowlist mode handles incoming email from three services. The agent extracts structured data, validates it against a schema, and writes it to Supabase. Outbound email goes through the same Resend pipeline I use for transactional messages, with rate limits and domain isolation.

The agent cannot sign up for services, send emails to addresses outside my allowlist, or make outbound HTTP requests. If it receives an email from an unknown sender, it logs the event and does nothing else.

This is less capable than what the demos show. It is also less likely to create dating profiles on my behalf.

Where this is going

The infrastructure for autonomous agents exists. Resend, NVIDIA, and the broader OpenClaw ecosystem are building it in production. Agents with dedicated accounts, inboxes, and API keys. The protocol works, and the tooling is catching up.

The security reality is different. Within the first sixty days: 12% of a skill registry compromised, a CVSS 8.8 RCE, prompt injection through email, and agents acting without consent. These are documented incidents from the first sixty days.

If you are building with agents, start from security. Use strict allowlists, scoped permissions, content sanitization, and human approval for anything outside a narrow, predefined scope. The permissive defaults will get someone breached. The agents have their own inboxes now. The defaults are permissive. Your first job is to close them down before the first email arrives.