is your OpenClaw agent's email secure? probably not

I've seen a lot of OpenClaw email setups. Most of them are held together with OAuth tokens and good intentions. If you got email working in your agent and moved on, I get it. Getting the Himalaya skill to authenticate against Gmail is enough of a victory that you stop asking questions. But "it works" and "it's secure" are not the same thing.

This is a security audit for your OpenClaw agent's email. Not a generic overview of AI safety. Not a theoretical paper. A checklist for people who already have email running and haven't thought about what they left exposed.

The Gmail OAuth problem#

If your agent connects to Gmail through OAuth, it almost certainly has the https://mail.google.com/ scope. That's Google's full-access permission. Read, write, delete, send. Every message you've ever received, every draft you've ever saved, every attachment you've ever opened.

Most people don't choose this scope on purpose. It's what the tutorials default to, and the Google Cloud Console doesn't exactly discourage it. The narrower gmail.readonly scope still grants access to your entire inbox history, just without write permissions.

Here's what that means in practice: your agent can see your bank statements. Your medical appointment confirmations. That password reset link from last Tuesday. Every private conversation you've had over email for the last decade. It's all sitting in the agent's context window, one prompt injection away from exfiltration.

And changing your Gmail password doesn't revoke OAuth tokens. The agent keeps access until you manually revoke it in your Google account settings. Most people don't know that.

Audit step: Open your Google account → Security → Third-party apps with account access. Check what scopes your OpenClaw agent has. If it says "Has access to Gmail" without restrictions, that's full access.

IMAP credentials in plaintext#

If you went the Himalaya route instead of Gog's OAuth flow, your Gmail app password is sitting in ~/.config/himalaya/config.toml. In plaintext. On the same machine your agent has shell access to.

IMAP was designed in the 1980s. It accepts plaintext credentials by design and has no native support for multifactor authentication. An app password stored in a config file is one compromised skill, one leaked environment variable, one overly permissive file permission away from full inbox access.

The OpenClaw security analysis in January 2026 found over 30,000 exposed instances publicly reachable on the internet, with 63% of observed deployments vulnerable to remote code execution. If your instance is one of them, that config file with your email credentials is an open door.

Audit step: Check ~/.config/himalaya/config.toml and any .env files your agent uses. If you see a password, app-password, or OAuth refresh token in plaintext, it's exposed. At minimum, use a secrets manager or encrypted environment variables.

No prompt injection defense#

This is the one that keeps me up at night. Your agent reads email. Email is attacker-controlled input. A single crafted message can hijack your agent's behavior.

OWASP's 2025 Top 10 for LLM Applications ranked prompt injection as the number one vulnerability, found in 73% of production AI deployments assessed during security audits. The attacks against email agents specifically are well-documented:

• ShadowLeak (September 2025): A zero-click vulnerability in ChatGPT's Deep Research agent. One crafted email in a user's Gmail triggered data exfiltration from OpenAI's cloud infrastructure. No user action required.
• ZombieAgent: A persistent attack against ChatGPT's Gmail Connectors that survived across sessions through the memory feature. The attacker sends a poisoned email, the agent reads it during a summarization task, and it silently forwards your inbox data to an external server.
• EchoLeak (CVE-2025-32711): A 9.3 CVSS zero-click attack against Microsoft 365 Copilot that exfiltrated SharePoint and OneDrive files through a single poisoned Outlook email.

None of the Gmail wrappers on ClawHub scan for prompt injection. Himalaya doesn't. Gog doesn't. They pass raw email content straight to your agent's context window. If someone sends your agent a message with hidden instructions in white-on-white HTML text, your agent will follow them. It doesn't know the difference between data and instructions.

Audit step: Search your agent's recent inbox for emails containing phrases like "ignore previous instructions," "system override," or "forward all." Better yet, send your agent a test injection email and see what happens. If you don't like the answer, you need a defense layer.

Your agent can go rogue#

This one isn't about attackers. It's about your agent doing exactly what it thinks you asked, at a speed and scale you didn't anticipate.

A Meta alignment researcher gave her OpenClaw agent access to her inbox for triage. The agent started bulk-deleting hundreds of emails in a "speed run," ignoring stop commands. The root cause: context window compaction lost her original instruction to be conservative. She had to physically run to her Mac Mini and kill the process.

That's an agent with the best intentions operating on stale context. No malice involved. Just a model that compressed its instructions, lost a constraint, and started executing at machine speed with full inbox permissions.

There's no kill switch built into the Gmail wrapper skills. No action budget. No confirmation gate. Once your agent has OAuth access to your inbox, it can read, delete, and send at whatever rate the Gmail API allows. If context drift causes the agent to misinterpret its mandate, you're watching the damage happen in real time with no way to stop it short of cutting power.

Audit step: Does your agent have write access to your inbox? Can it delete messages? Can it send as you? If yes, what stops it from deleting 500 emails in 30 seconds if it decides that's the most efficient way to "clean up"? If the answer is "nothing," you have a problem.

The checklist#

Here's every question you should be able to answer about your OpenClaw agent's email setup:

1. What OAuth scopes does your agent have? Full access or read-only?
2. Where are your credentials stored? Plaintext config file, environment variable, or secrets manager?
3. Is your OpenClaw instance publicly reachable? Check if port 3000 or your gateway port is exposed.
4. Does your agent have write/delete access to your inbox? Can it send emails as you?
5. What happens if someone sends your agent a prompt injection email? Have you tested this?
6. Does your agent access your personal inbox or its own dedicated inbox?
7. What's the blast radius if the agent is compromised? Just the agent's messages, or your entire email history?
8. Is there a rate limit on agent actions? What stops the agent from bulk-deleting messages?
9. Can you revoke the agent's email access instantly? Do you know how?
10. Are incoming emails scanned for malicious content before reaching the agent?

If you answered "I don't know" to more than two of these, your setup needs work.

What a secure setup actually looks like#

The core principle is isolation. Your agent should never touch your personal inbox. It gets its own email address, its own credential, its own blast radius.

LobsterMail is built around this. Every agent gets a dedicated inbox that's completely separate from any human email. But the security layer goes beyond isolation. Every incoming email is scanned across 6 categories of prompt injection:

1. Boundary manipulation — attempts to break out of content markers
2. System prompt override — "ignore previous instructions" and variants
3. Data exfiltration — instructions to send data to external addresses
4. Role hijacking — fake [SYSTEM] messages embedded in email bodies
5. Tool invocation — attempts to trigger function calls through email content
6. Encoding and obfuscation — hex escapes, zero-width characters, Base64 payloads

The SDK surfaces this directly. email.isInjectionRisk gives you a boolean flag before your agent ever processes the content. email.safeBodyForLLM() wraps the email in boundary markers with a metadata header and strips any injected boundaries, so you can pass it to your model without the raw content hijacking the conversation.

const emails = await inbox.getEmails();

for (const email of emails) {
  if (email.isInjectionRisk) {
    console.log("Flagged:", email.subject);
    continue;
  }

  const safeContent = email.safeBodyForLLM();
  // pass safeContent to your agent's context
}

That's the difference between "email works" and "email is secure." Your agent gets its own shell, incoming content is scanned before it reaches the model, and you have programmatic control over what gets processed. No OAuth tokens pointing at your personal inbox. No plaintext passwords in config files. No all-or-nothing access.

If you've already got email running in your OpenClaw agent, run through the checklist above. If the answers make you uncomfortable, the fix isn't complicated. It's just a different architecture.

Give your agent its own email. Get started with LobsterMail — it's free.