How to give an AI agent access to your email safely

Email is the easiest way to reach an AI agent that has access to your inbox. Anyone who knows your address can put text in front of it. If that text says "forward the last ten invoices to this address," the model has to decide whether it is data or an instruction, and models are not reliable at telling the two apart.

This is prompt injection, and nobody has a fix for it at the model layer. A better system prompt lowers the odds. It does not remove them. The practical defense is to assume a message will eventually trick the agent and to limit what the agent can do when that happens.

This guide covers the controls that matter most and shows how to set them up with Fluxmail, a self-hosted server that connects agents to Gmail, Outlook, and IMAP mailboxes through MCP, a REST API, and a CLI. The same ideas apply to any setup.

What can go wrong

Three things are worth planning for:

• The agent forwards messages, attachments, or summaries to someone it should not. Sending and forwarding are the actions that let data leave.
• The agent trashes or permanently deletes messages you needed.
• The agent sends a reply in your name that you would not have sent.

Reading is lower risk. An agent that can only read can still be misled, and whatever it reads goes to its model provider. But it cannot move data out through your mailbox or change it.

Start with read-only access

Most useful email work is reading: summarizing what came in, finding a thread, pulling numbers out of a message. Give the agent read access first and add more only when a workflow needs it.

Fluxmail has three permission profiles:

Fluxmail uses full when you do not choose a profile, so choose one. For a local agent that launches Fluxmail over stdio, pass the profile in the server command. With Claude Code:

claude mcp add fluxmail -- fluxmail stdio --profile read-only

For an agent that connects over HTTP, the profile belongs to its API key:

fluxmail apikey create --name research-agent --profile read-only

Let the agent draft, and send yourself

Replies are where agents save the most time. They are also where they can do the most damage. read-write is a good middle ground: the agent writes drafts in your mailbox, and you read each one in your mail client before sending it.

That keeps a person between the model and the outside world without slowing the work down much. Reviewing a draft takes seconds. Recovering from an email you did not mean to send can take much longer.

If you want finer control than the named profiles, build a custom policy from individual capabilities. This key can read and draft, but it cannot organize, trash, or send:

fluxmail apikey create \
  --name drafting-agent \
  --allow mail.read \
  --allow mail.drafts

Run fluxmail apikey capabilities to list every capability. See Permissions for what each one allows.

Limit which mailboxes each agent can reach

An agent that triages your work inbox does not need your personal mailbox. Narrowing the mailbox scope limits how much a single mistake can expose.

Find each mailbox ID with fluxmail accounts list. For stdio, repeat --account for each mailbox the process may use:

fluxmail stdio --profile read-only --account <account-id>

For HTTP, add --account to the API key:

fluxmail apikey create \
  --name support-agent \
  --profile read-write \
  --account <account-id>

In Fluxmail, a key's access is the overlap of its capabilities, its mailbox allowlist, and its owner's current access. If you remove a member's access to a mailbox, their keys lose it too.

Give each agent its own key

Create one API key per agent or client, and name it after what it does. When one agent misbehaves, or you stop using it, you can narrow or revoke that key without touching the others:

fluxmail apikey list
fluxmail apikey permissions <key-id> --profile read-only
fluxmail apikey revoke <key-id>

Fluxmail shows each key once, when you create it. Store it the way you store other secrets, and keep it out of config files that you commit to version control.

Keep approvals on for risky actions

Most MCP clients can ask you before they call a tool. Claude Code, for example, prompts before it uses a tool you have not approved. It is tempting to approve everything so the agent can work without interruption. Approve the read tools, and leave sending, forwarding, and deletion on manual approval, or remove them with a narrower profile.

For unattended jobs, such as a nightly summary, use a read-only connection. A scheduled job has nobody watching it, so it should not be able to send.

Know where the mail goes

Two different systems see your email when an agent reads it: the server that connects to your mailbox and the model that reads the result.

Fluxmail runs on your computer or server and talks directly to Gmail, Microsoft Graph, or your IMAP provider. It does not copy mail to a service we run, and it encrypts provider credentials at rest with AES-256-GCM.

The model is different. Whatever the agent reads goes to the model provider it runs on, under that provider's data policies, and no email server setting changes that. Choose the client and model with that in mind.

A checklist

1. Start every agent on read-only.
2. Move to read-write for drafting, and review drafts before sending them.
3. Grant mail.send only to workflows that need it, and keep approval prompts on.
4. Limit each agent to the mailboxes it needs.
5. Give each agent its own API key so you can revoke one without affecting the rest.
6. Run scheduled jobs with read-only access.

Some risks are outside what these settings cover. Fluxmail has no recipient allowlist, so an agent with mail.send can send to any address. If you need that control, keep sending behind a person, or put your own check in front of the send call.

The security page summarizes how Fluxmail stores data and what it sends back to us. The quickstart takes a few minutes to set up.