Before You Connect an AI Agent to Your Email: What That Access Really Means
Before you connect an AI agent to your email, understand that "connect" usually means access to your entire mailbox and its history, not a single message. Reading your mail is one risk; letting the agent send is a much bigger one. Grant the least scope possible, keep sending behind human approval, and store the key encrypted.
The connect button hides this on purpose. It says "connect your email" as if you are handing over one folder or one thread, but the permission you approve is almost always mailbox-wide. That gap between what the words imply and what the token grants is where non-technical owners get hurt, so it is worth slowing down for the two minutes it takes to read what you are actually agreeing to.
The reason this matters is that reading and sending are two different risk classes, and most connect flows blur them together. An agent that can read everything is a privacy exposure; an agent that can send is a party that can act in the world under your name. Treating those as the same decision is the mistake, and this is closely tied to the rule that an agent should never take irreversible actions without asking first.
What exactly can the agent read once connected?
Once connected, the agent can usually read your whole mailbox and its full history, not the single thread you had in mind. The standard email permission scopes are coarse: they grant "read your mail," which means every message, every folder, every archived conversation going back years, plus attachments and contacts in many cases. There is rarely a "just this one email" option, because the connection is a broad scope by default.
This is worth sitting with, because your mailbox is not just email. It is the reset link for every other account you own - your bank, your domain registrar, your cloud storage, your other logins. Anything that can send a "forgot password" link to your inbox is effectively controlled by whoever can read that inbox. So "read my mail" is not a small privacy concession; it is read access to the recovery keys for most of your digital life.
None of that means you should never connect an agent to email. It means you should connect it the way you would hand a spare key to a contractor: knowing exactly which doors it opens, for how long, and how to take it back. The next section is the practical version of that - how to grant the smallest amount of access that still gets the job done.
How do you connect with the least access possible?
You connect with the least access possible by granting the narrowest scope the task needs, defaulting to read-only, and never granting send unless a specific job requires it. If the agent only needs to summarize or triage, a read scope is enough, and a read-only token cannot send a single message no matter what it is told to do. That one choice removes the entire category of "the agent emailed someone by mistake."
Use a separate or limited account where you can. An agent that only needs to watch a support inbox does not need your personal mailbox with fifteen years of history and every password reset in it. A dedicated address, or a provider that supports scoped app permissions, shrinks the blast radius from "everything" to "this one job." The goal is that even a worst case only exposes what that account holds, not your whole life.
Then protect the key itself. Our own access policy is one rule per line: one key equals one scope, secrets are encrypted locally and read into memory only at the moment of use, and they are never written to logs or transcripts. Reading is treated as a lower risk than sending, and sending is a hard guardrail that requires human approval every single time - the agent can draft, but a person clicks send. If you keep only that last habit, you have removed the scariest failure mode while keeping the agent genuinely useful. It also blunts the case where a hostile email tries to hijack the agent, because a reader with no send tool cannot be turned into a sender.
FAQ
Can the agent send emails as me?
Only if you grant send access, so do not grant it by default. Sending is a separate, higher-risk permission from reading, and most connect flows will ask for both together if you let them. Keep sending behind human approval every time: let the agent draft, but require a person to click send. A read-only connection cannot send a message no matter what instruction it receives.
What if a malicious email instructs my agent?
That is prompt injection, and it is real. A message can contain hidden text telling your agent to forward your inbox or reset a password, and a naive agent may obey. The defense is structural: an agent that reads untrusted messages must not also hold send or payment tools. If the reader cannot send, a hostile email can instruct all it wants and still cannot make anything happen.
How do I revoke an agent's email access?
Revoke the token or app permission in your email provider's security settings, then rotate the key so the old one is dead. Look for "connected apps," "third-party access," or "app passwords" in your account security page and remove the entry. Because the access is a granted scope rather than something baked in, pulling it takes effect immediately and the agent goes blind the moment you revoke.