Email is the Most Dangerous Thing You Can Give an AI Agent

It's 7:43am. Your AI assistant has been running overnight, triaging your inbox. You get to your desk and find that the proposal you were still editing — marked as a draft, saved but not sent — went out at 3am. To your biggest prospect. Without the pricing section. With a placeholder still in the subject line that says “SUBJECT TBC.”

You stare at it. The agent logged the action as “sent draft per detected urgency signals.” It was trying to be helpful.

Or: you asked the agent to “clean up the thread with the customer onboarding team.” It parsed that as delete. You can't find the thread. It's gone. EXPUNGE is permanent. There's no trash. There's no undo. Your onboarding history for a $200k account is just missing.

Or: the agent, instructed to reply to a question from your VP of Engineering, hits reply-all on a thread that includes three external contractors and your board chair. The message contains salary details. The agent was following the instruction. It had no way to know the context.

These aren't hypotheticals. Variations of all three have already happened. They will keep happening as long as we keep giving AI agents raw IMAP access and hoping for the best.

Every other AI tooling layer has a review step. Email has nothing.

Think about how we've built guardrails everywhere else.

When an AI agent writes code, we don't just let it commit directly to main. We have pull requests. The diff is visible. A human reviews the change before it merges. If the diff looks wrong, we reject it. If we approve it and it breaks something, we have the full history of what changed and when.

When an AI agent makes infrastructure changes, we have approval gates. Terraform plans. Change management tickets. Someone with the authority to say “yes, apply this” before anything touches production.

When an AI agent edits a Google Doc, track changes are on. You can see what it touched. You can accept or reject each edit. You have a named history of every modification.

Email has none of this.

When you give an AI agent IMAP credentials, you are handing it unmediated write access to one of the most sensitive communication channels in your organization. It can read everything. It can send anything. It can delete threads permanently — not to trash, actually deleted, gone — with no record of what it did or why.

There is no staging environment for email. There is no branch to merge. There is no diff to review. The agent acts and the action is real.

What raw IMAP access actually means

IMAP is a 1986 protocol that has aged well enough but was never designed for autonomous agents. When you authenticate an agent to your IMAP server, you are giving it the following capabilities:

• —Read any message, folder, or label in the account
• —Write (move, flag, mark read/unread, create folders)
• —EXPUNGE: permanently delete messages. Not soft-delete, not trash — gone. The IMAP spec was clear that this is a final operation.
• —Send via SMTP: anything, to anyone, on your behalf

There are no built-in permission scopes. There is no “read-only plus send drafts.” You can build something approximating it if you write your own wrapper, but most teams don't. They provision credentials and move on.

There is also no audit log built into IMAP. If your agent deletes 200 messages and you want to know which ones and why, your options are: look at what's missing, or hope your email provider kept a server-side log you can request. Gmail has some deletion history. Most providers don't.

When something goes wrong — and it will — you will be looking at a gap in your inbox trying to reconstruct what the agent did from first principles.

Git gave us the answer for code. We built it for email.

Here is the core insight behind Nuvrail:

Git didn't make AI coding agents safe by making them smarter. It made them safe by making them reviewable. The diff is the mechanism of trust. You can see exactly what the agent wants to do before it does it. You can say yes or no. The history is immutable.

We asked: what would email look like if it had the same primitive?

Every proposed email action is a diff. The agent wants to send a message — that's a proposed commit. It wants to delete a thread — that's a proposed destructive change. It wants to move messages to a folder — that's a refactor. None of it happens until a human approves it.

That's Nuvrail. An IMAP/SMTP proxy that sits between your AI agent and your real inbox. Every action goes into a staging queue. You review it. You approve or reject it. When you approve, it executes. When you reject, it doesn't. Either way, the record is there.

What Nuvrail actually does

Nuvrail is a proxy. Your AI agent talks to Nuvrail exactly the way it would talk to your real IMAP/SMTP server. You point it at our endpoint, give it credentials scoped to Nuvrail, and Nuvrail handles the relay.

When the agent tries to send a message, Nuvrail intercepts it. It creates a staged action — a diff, effectively — that shows you exactly what would happen: who the message is to, what the subject is, what the body is, what thread it's in reply to. You review it. Approve it and it sends. Reject it and it doesn't. The agent receives a response either way.

When the agent tries to delete, same flow. You see what it wants to delete, with enough context to understand why. You decide.

The audit log is immutable. We don't allow retroactive deletion of log entries. Every approval and every rejection is a permanent record — who reviewed it, when, what was approved or rejected. If something goes wrong six months from now and your CEO asks “what did the agent do in March?” you can answer that question.

Nuvrail is agent-agnostic and provider-agnostic. It works with any IMAP/SMTP provider and any AI agent that can be configured with a custom email endpoint. You don't have to change your agent code. You change the endpoint.

“Doesn't this slow things down?”

Yes. Deliberately.

If your use case requires an AI agent to take email actions at machine speed with no human in the loop, Nuvrail will add latency. That's a feature, not a bug. Our assumption is that if you're sending email from an AI agent, someone should be verifying it before it goes out. If that assumption is wrong for your use case, Nuvrail isn't the right tool.

For most developer teams building AI email agents, the actual flow is: agent proposes, human reviews, action executes. That cycle might be 30 seconds on mobile or a few minutes at your desk. The agent can continue other work while it waits. The inbox doesn't move in real time anyway — a two-minute review lag is invisible to the recipient.

There is also a bypass mode for trusted read-only actions. If you've decided that the agent can read and search without approval, you can configure that. Writes and deletes always require approval. That's not configurable — it's the point.

Open source, because you should be able to verify this

We open-sourced the proxy core. The IMAP/SMTP intercept logic, the staging queue, the audit log format — all of it is on GitHub. You can read the code that sits between your agent and your inbox. You can run it yourself.

If your threat model includes “I don't trust the vendor,” you can self-host Nuvrail and own the entire stack. We think that's the right option for a lot of teams, especially early on.

The cloud version adds managed infrastructure, a hosted review UI, team management, and an extended audit log. Cloud Starter is free: one account, one agent, 30-day audit history. No credit card required. It's the fastest way to see how it works.

If you're building an AI email agent today and you want to stop worrying about what it might do, start here.

The pull request model exists for code because we decided that autonomy without review was too risky. Email is more sensitive than most code. It's time to build the same thing.

Nuvrail is open source. The core proxy is available on GitHub. Cloud Starter is free — no credit card required.