oauth vs api keys for ai agent email authentication

Your AI agent needs to send email. Before it composes a single message, it needs to authenticate with something: an API key, an OAuth token, or some combination of both. This decision shapes everything downstream, from what happens when credentials leak to whether you can revoke access without torching your entire setup.

Most developers pick the path of least resistance. For a weekend project, that's fine. For an autonomous agent sending email on behalf of users at scale, the wrong choice creates compliance nightmares you won't discover until an incident forces you to care.

I've spent the last year building email infrastructure for agents, and the auth question comes up in almost every onboarding conversation. Here's what I've learned.

OAuth vs API keys for AI agents: at a glance#

For email agents acting on behalf of users, OAuth wins on every axis that matters for security and compliance. API keys identify the calling application but don't model user delegation or consent, which means your agent either has full access or none.

How AI agents authenticate with email APIs today#

There are three common patterns, each with different tradeoffs.

Pattern 1: Raw API key in environment variables. The agent reads EMAIL_API_KEY from its environment and uses it for every request. Simple to implement. Also means a single leaked key exposes every inbox the agent manages. There's no way to revoke access for one user without regenerating the key for everyone.

Pattern 2: OAuth with user delegation. The agent requests specific scopes (like gmail.send or mail.readwrite) and receives tokens tied to individual user grants. If one user revokes access, other users are unaffected. The agent can only do what users explicitly permitted.

Pattern 3: Agent-provisioned infrastructure. The agent provisions its own email identity rather than authenticating against a user's existing inbox. No OAuth dance, no shared API keys. The agent owns the mailbox outright. This is what LobsterMail does: the agent creates its own inbox with a single SDK call, and credentials are scoped to that specific mailbox from the start.

Why API keys fall short for autonomous email agents#

An API key is a static string. It doesn't expire, doesn't scope, and doesn't delegate. For an autonomous agent, this creates three specific problems.

No scope boundaries. When your agent holds a Gmail API key (or service account credential), it typically has access to the full mailbox. Read, send, delete, manage filters. If the agent's behavior drifts or its prompt gets manipulated, there's no guardrail limiting what it can do. OAuth scopes let you restrict access to gmail.send only, so even a compromised agent can't read the user's inbox.

Revocation is destructive. Compromised API key? You regenerate it. Every agent instance, every deployment, every integration using that key breaks simultaneously. With OAuth, you revoke the specific token that was compromised. Other grants continue working.

No user consent model. API keys don't capture who authorized what. If your agent sends email on behalf of 50 users via a single key, your audit log shows "the app sent email." Not "User A authorized sending at 3pm on Tuesday." When a compliance audit hits (and for email, they always do), you need that granularity.

What OAuth scopes should an AI email agent request?#

The principle of least privilege matters more for agents than humans. A human checks their own inbox and self-corrects. An agent follows instructions without judgment.

For Gmail, the minimum scopes for a send-only agent:

https://www.googleapis.com/auth/gmail.send For read-and-send:

https://www.googleapis.com/auth/gmail.send
https://www.googleapis.com/auth/gmail.readonly

For Microsoft 365:

Mail.Send
Mail.Read

Never request Mail.ReadWrite or gmail.modify unless your agent genuinely needs to move, delete, or label messages. Every extra scope is attack surface.

PKCE and the machine-to-machine problem#

OAuth was designed for interactive flows where a human clicks "Allow." AI agents don't click buttons. This mismatch has created real friction in the ecosystem.

For agents acting on behalf of users, the Authorization Code flow with PKCE (Proof Key for Code Exchange) remains the standard. OAuth 2.1 makes PKCE mandatory, closing the authorization code interception attack that plagued earlier implementations.

For server-to-server agent communication (no user involved), the Client Credentials flow is appropriate. The agent authenticates as itself, not on behalf of a user. This works well for agents that own their own resources rather than accessing someone else's mailbox.

Credential rotation at scale#

Here's the operational reality nobody discusses in the "just use OAuth" blog posts. If your agent manages 300 inboxes, you're handling 300 refresh tokens. Each expires independently. Each can be revoked independently. Your agent needs retry logic for expired tokens, a secure storage layer for refresh tokens, and monitoring for revocation events.

API keys avoid this complexity, but at the cost of all the security properties listed above. It's not a good trade.

The third option, agent-owned infrastructure, sidesteps this entirely. When the agent provisions its own inbox through a service like LobsterMail, there's one credential per agent (not per user), scoped to the agent's own mailbox. Rotation is straightforward because you're not coordinating across user grants.

Deliverability impact of your auth choice#

This is the gap nobody talks about. Your authentication method affects email deliverability in non-obvious ways.

Shared API keys mean shared sender reputation. If one agent instance using your key sends spam, every message from that key gets tainted. OAuth-scoped tokens at least isolate reputation by sender identity.

Dedicated agent infrastructure takes this further. When your agent has its own domain and its own IP, its reputation is entirely self-contained. Bad behavior by other agents doesn't affect your deliverability. Good behavior compounds into better inbox placement over time.

Compliance considerations for agent-sent email#

CAN-SPAM, GDPR, and SOC 2 all care about attribution. Who authorized this message? On whose behalf was it sent? Can the authorization be traced and revoked?

API keys answer none of these questions cleanly. OAuth tokens answer all of them: the grant captures the user, the scope, the timestamp, and the revocation path.

For agents sending on their own behalf (newsletters, notifications, outbound), the compliance picture simplifies. The agent is the sender. No delegation question exists. But you still need audit trails showing which agent sent what, when, and whether the recipient opted in.

When API keys are actually fine#

I'm not arguing that OAuth is always correct. API keys work well in specific scenarios:

• Your agent only accesses its own resources (not user mailboxes)
• The key is scoped to a single mailbox or service
• You have infrastructure-level key rotation (not manual)
• The blast radius of a leak is limited to one agent's data

If your agent provisions its own inbox and only touches its own email, a scoped API key with automatic rotation is perfectly reasonable. The danger is shared keys with broad permissions acting on behalf of multiple users.

The third path: agent-first email#

The OAuth vs API key debate assumes your agent is authenticating against someone else's infrastructure. There's a simpler framing: give the agent its own email identity from the start.

When an agent owns its inbox outright, the authentication question collapses. There's no user delegation because the agent is the user. There's no scope negotiation because the agent has full authority over its own mailbox and nothing else. Credential rotation is between the agent and its own infrastructure, not coordinated across user grants.

This is the approach we took with LobsterMail. An agent calls LobsterMail.create(), gets its own inbox, and authenticates with a token scoped exclusively to that mailbox. No OAuth consent screens. No shared API keys. No credential coordination across hundreds of user grants.

For agents that need to read a human's existing Gmail inbox, OAuth remains the right tool. But for agents that need their own email presence (sending notifications, receiving webheets, handling verification flows), agent-provisioned infrastructure is simpler and more secure than either alternative.