The pitch writes itself: an assistant that reads your mail, drafts the replies, chases the follow-ups. Email is where the work is, so of course you want the AI where the work is.
The uncomfortable part: your inbox is the most sensitive database you own — and it's the only one that accepts writes from strangers. Before you connect anything to it, it's worth being precise about what you're granting and what can go wrong.
What "connect your email" actually grants
For most tools, connecting email means OAuth access to the mailbox. In practice that's usually:
- Read access to everything. Not just the newsletters — password resets, contracts, medical mail, financial statements, and years of history. Mailbox permission scopes are coarse; "read the boring stuff only" is rarely an available option.
- Often, the right to send as you. Your outbound identity, attached to an automated process.
- A standing grant. It persists until you remember to revoke it.
None of this is automatically disqualifying. It is a lot to hand over on the strength of a landing page, and it deserves the same scrutiny you'd give any service holding your entire correspondence history.
The part people miss: inbound mail is instructions
An AI agent reading your inbox is reading text written by strangers, in the same context where its tools live. That's the setup for prompt injection: a message arrives containing instructions aimed at the model — buried in an HTML footer, a forwarded thread, an "urgent" request — and the model, whose whole job is to be steered by text, gets steered.
An agent that can only read makes this survivable: the damage is a bad summary. An agent that can read and send is the dangerous combination — private data, untrusted input, and an outbound channel in one place. That's the shape of every serious agent-exfiltration demo: the attack arrives as an email, and leaves as one too.
Narrower grants that keep most of the value
The good news is that "connect everything" is not the only design on offer.
- Read-only triage. Summaries and prioritization without send rights. A hijacked summarizer can lie to you, but it can't act. Forward-only tools narrow this further — they see only the mail you deliberately route to them.
- Draft-only, you send. The assistant composes; you press send in your own mail client. Good — but the separation lives in your discipline, not in the system. Nothing structurally stops the paste-and-send reflex at 11pm.
- A separate channel built for agents. The assistant gets no mailbox access at all. New correspondence flows through a relay where the safety properties are structural: drafting and sending are separate server-side steps, every field carries provenance, content is neutralized so it can't auto-fetch, and consent is enforced with contact pairs and hard caps.
RelayLink is the third design, and the cost is worth stating honestly: it does nothing about the mail you already get. It's not a triage tool — it's where your assistant-mediated correspondence happens, so the powers an agent needs are granted on a surface built to constrain them, instead of bolted onto the account that holds your password resets.
Where the line is
If you do grant inbox access, two rules cover most of the risk:
- Separate reading from sending. A tool may hold one or the other. The same automated hand should not both read strangers' text and transmit as you — not without a human step in between.
- Prefer revocable, scoped, forward-only designs over standing full-mailbox OAuth, and actually revoke what you stop using.
If you're still working out what "send email" even requires an assistant to be granted, can AI assistants send emails? walks the three ways that connection usually gets made and what each one actually hands over.
And if what you wanted from "AI email access" was mostly outbound — have the assistant handle a correspondence properly, with review and a reply path — you don't need to open the inbox at all. That's the case RelayLink was built for: connect your assistant, keep your mailbox to yourself.