Email is the master credential. Most accounts route password resets through it; many financial accounts treat email-confirmed-this as proof of identity. Granting an AI agent access to email is the most consequential integration decision in personal automation. The four guardrails below are how you grant access without taking on the risk of an agent that reads, writes, or sends in ways you did not intend.

The threat model is simple. Read access exposes private content to the agent and to whoever logs the agent's reasoning trace. Write access (labels, archive) modifies your inbox state. Send access lets the agent email people from your address. The risk increases with each level. The guardrails increase with it.

Why email is the highest-stakes integration

Three properties make email a higher-stakes integration than calendar, files, or chat. First, email is identity. Most other accounts (banks, services, social) verify ownership via email-based password reset. An attacker with email access can take over most other accounts. Second, email is reputation. Anything an agent sends from your address is attributable to you. A wrong send to a customer is a customer-trust event. Third, email is volume. The blast radius of a misbehaving agent is the size of your inbox times the number of recipients you have ever emailed.

OWASP's published guidance on agentic AI risks classifies "tool integrations with broad scope" as one of the top risk categories (OWASP, "Top 10 for LLM Applications"). Email is the canonical broad-scope integration.

Guardrail 1: Read-only by default

Start every email integration with read-only scope. Most agent use cases (digest, triage summary, watch list) need only read. Read-only access can be granted on day one, runs unattended, and surfaces the value of the agent without any send-side risk.

The agent earns write access after a supervised run window. The 80-tests methodology in how we test AI agents provides the structure for this earning process. For personal automation the bar is lower, but the principle is the same: write access requires evidence of correct behaviour under read-only.

Guardrail 2: Domain allowlist for outgoing addresses

When the agent does need to send, the recipient address must match a domain or address allowlist that you control. The allowlist is a small text list: domains your team uses, customer domains you have explicitly added, your own personal contacts.

If the agent attempts to send to an address outside the allowlist, the send is blocked at the integration layer. The agent never gets the chance to compose. This eliminates the entire class of "agent emailed the wrong recipient" failures, which is the failure mode most likely to produce a customer-trust incident.

The allowlist concept generalises. The same blast-radius reasoning applies to any integration where the agent can produce external effects, covered in AI agent safety and guardrails.

Email access tiers, lowest to highest risk Tier 1: Read-only gmail.readonly Day 1 grant. Triage, digest, watch list. No state change. Reversible: revoke OAuth. Tier 2: Modify + Drafts gmail.modify, gmail.compose After 10 supervised runs. Labels, archive, drafts. No external send. Reversible: scope-down. Tier 3: Send (gated) gmail.send, allowlist required After 30 days drafts mode. Domain allowlist enforced. Per-day send cap. Audit log on every send. Source: Aryan Agarwal, Gravity email integration spec, May 2026.
Each tier earns the next through evidence of correct behaviour at the previous tier.

Guardrail 3: Drafts mode for the first 30 days

Drafts mode is the most under-used safety feature in agent integrations. The agent composes the message and saves it as a draft for human review. The agent does not send. You see exactly what the agent would have sent, in the same client where you read your normal email.

For 30 days, the agent runs in drafts mode. You review each draft. Approve, edit, or discard. Track how many drafts you would have sent unmodified. When the unmodified-approval rate is above some threshold (90% is reasonable for low-stakes content; 99%+ for customer-facing), the agent earns send rights.

If at any point the agent produces a draft that would have caused a problem (wrong recipient, wrong tone, fabricated information), reset the 30-day clock. The cost of this discipline is your time during the first 30 days. The cost of skipping it is whatever the agent would have sent in error.

Guardrail 4: Audit log + anomaly detection

Every email read, every label change, every draft, every send: logged. The log captures who (which agent), what (action and target), when (timestamp), and why (the agent's reasoning trace if available). Logs go to a separate destination from the email account so the agent cannot delete its own audit trail.

Anomaly detection sits on top of the log. Spikes in send volume trigger alerts. Sends to unrecognised domains trigger alerts. Reads that touch a folder the agent has never read before trigger alerts. The alerts go to you, not to the agent. The thinking on monitoring is covered in AI agent monitoring and observability (forthcoming) and applies to email integrations specifically.

OAuth scopes that matter

For Gmail, the scopes form a least-privilege ladder.

What to avoid: gmail.full or full-mailbox scopes. These grant more than the agent needs and create a blast radius an order of magnitude larger than the task requires. Microsoft Outlook and other providers have analogous scope ladders; the principle is the same.

Frequently asked questions

Is it safe to give an AI agent access to my email?

It can be, but only with explicit guardrails. Email is the master credential for most accounts because it controls password resets. The risk of an agent reading email is mostly privacy. The risk of an agent sending email is reputational and financial. Read access can start safely; write access should start in drafts mode and earn the right to send.

What OAuth scopes should an email agent request?

For Gmail: gmail.readonly for triage and digest agents; gmail.modify for label and archive actions; gmail.compose to draft messages without sending; gmail.send only when the agent has earned send rights via supervised drafts mode. Avoid gmail.full or full-mailbox scopes. The principle of least privilege applies.

Can an AI agent send email from my address by mistake?

Only if you grant the send scope without guardrails. With drafts mode for the first 30 days, the agent composes; you approve. With a domain allowlist, the agent can only send to recipients you have pre-authorised. With a per-day send cap, the agent cannot send more than your specified ceiling. Combine all three for production.

What is drafts mode and why does it matter?

Drafts mode is when the agent composes the message and saves it as a draft for human review instead of sending. It is the safest first 30 days of any email-write agent. You see exactly what the agent would have sent, you correct anything wrong, and the agent only earns send rights after a track record of good drafts.

How do I revoke an AI agent's email access?

Revoke the OAuth grant from your email provider's account settings. For Google accounts: myaccount.google.com/permissions. The agent immediately loses access. Do this if the agent behaves unexpectedly or if you stop using the integration. Revocation is the kill switch; treat it as such.

Three takeaways before you close this tab

Sources