Inboxes · September 21, 2026

AI Agent Inbox vs Connecting Gmail: How to Choose

Giving an agent its own inbox versus wiring it into an existing Gmail or Microsoft 365 mailbox: identity, blast radius, OAuth scope and revocation.

There are two ways to get an agent onto email. Connect it to a mailbox that already exists — a Gmail account, a Microsoft 365 mailbox — or give it a mailbox of its own. Both work. They fail differently, and the failure modes are what should decide it.

This is a comparison of the two models, not a pitch. We build one of them, so read the “when connecting an existing mailbox is right” section with that in mind; it is there because that answer is correct more often than vendors admit. Specifics about a dedicated agent inbox are drawn from the implementation. Specifics about mailbox providers are drawn from their published API documentation, and provider limits change — verify the current figures before you rely on them.

Two different models, not two vendors

Connecting an existing mailbox means the agent authenticates as a person — or as a service account impersonating one — and operates inside a mailbox built for a human, with folders, filters, a signature and years of history.

A dedicated agent inbox means the agent is the mailbox owner. The address exists only for the agent’s job, the store contains only what that job produced, and the credentials name the agent rather than an employee.

The difference is not the API surface. It is who the mailbox belongs to, and therefore who is accountable when something goes wrong.

Whose name is on the From line

With a connected mailbox, the From line says a person. If the agent sends an incorrect refund confirmation, the recipient’s reply, their escalation and their eventual complaint all name someone who did not write it. Internally, the mail log says that person sent it too.

You can soften this with an alias or a “sent on behalf of” header, but display names are advisory and many clients show the underlying account anyway.

With a dedicated inbox, the From line says support-triage@agents.example.com. A recipient replying to it reaches the agent’s thread, where the agent — or the human watching the queue — can act. Nobody’s personal mailbox absorbs the fallout.

This is the single most underrated difference. It is not about branding; it is about whether the reply path is correct. Getting that From line onto your own hostname is a DNS exercise rather than a mail-client one: agent email on a subdomain covers the records and how to leave employee routing untouched.

Blast radius when the agent gets it wrong

Assume the agent will, at some point, be talked into something by an email it reads. Prompt injection through inbound mail is not hypothetical; the content arrives in the model’s context and it was written by a stranger. Design for the case where the model is convinced.

In a connected human mailbox, the blast radius is that mailbox: everything in it, and everyone it can write to. If the token can read, it can read the thread about the acquisition. If it can send, it can send anywhere, as the employee.

In a dedicated inbox, the blast radius is what the grant named. A grant covers specific inbox IDs inside one project. A read_draft preset — drafts:read, drafts:write, drafts:submit, without messages:send — cannot transmit at all: the send call returns approval_required with the reason code draft_only_principal regardless of what the inbox policy allows. Recipient allow lists narrow it further, and blocked recipients always win over allow rules.

Neither model makes prompt injection go away. One of them bounds the damage in a way you can state in a sentence.

How granular the OAuth scopes really are

This is where the comparison is most concrete, because scope names are published.

Gmail’s API scopes are mailbox-wide. gmail.readonly reads all resources and metadata. gmail.modify covers everything except permanent deletion. gmail.send sends on behalf of the account. gmail.compose creates, reads, updates and deletes drafts and sends messages. There is no scope that means “only the threads with this label” or “only messages from this counterparty” — filtering is something your code does after the API has already handed it everything. The most useful scopes are classed as sensitive or restricted, which brings app verification and, for restricted scopes, a periodic third-party security assessment. Microsoft Graph is the same shape: Mail.Read, Mail.Send, Mail.ReadWrite are mailbox-wide, with application permissions narrowed only by a separate tenant-level access policy that an administrator configures outside your app.

A dedicated agent inbox inverts the default. The grant enumerates inbox IDs. Scopes are per-capability — reading threads, reading messages, writing drafts, submitting drafts, sending — and the administrative ones are structurally unavailable to an agent connection: keys:manage, members:manage, billing:manage, policies:write, inboxes:delete, messages:delete, messages:raw and exports:write cannot be granted to one at all. An agent cannot mint itself a broader credential, rewrite the policy that constrains it, read raw MIME, or delete the record of what it did.

There is also a ceiling on delegation: a credential cannot carry a permission its creator lacks. If your own role does not include messages:send, no grant you make includes it.

Provisioning the tenth agent, and the hundredth

Connected mailboxes provision like people, because they are people. Each agent needs a licensed account or a service account with domain-wide delegation, a mailbox, an owner of record, a recovery path, and a spot in whatever access review process you run. Ten is tedious. A hundred is a directory-management project.

Dedicated inboxes provision like resources: one API call.

curl -X POST "https://api.emailforagents.ai/v1/projects/$EFA_PROJECT_ID/inboxes" \
  -H "Authorization: Bearer $EFA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"display_name":"Invoice intake","local_part":"invoices"}'

The honest counterweight: this is early access, and the free allowance is one complimentary live inbox and 100 email units a month per verified owner identity, claimed by that identity’s first eligible workspace — creating another workspace does not renew it. Test projects allow three active inboxes per workspace. Higher volumes need a paid plan, and paid checkout is currently disabled, so Builder and Team are proposed prices you cannot buy today. If your plan requires a hundred live inboxes this quarter, that is a real constraint, and you should weigh it against the per-seat licensing on the other side rather than assuming either is free.

Per-seat cost and sending limits

A connected mailbox usually costs a seat. Whether that is acceptable depends less on the number than on what else comes with it: a licensed account is also an identity in your directory, with a password, an MFA enrolment and an offboarding checklist. Automation accounts are where offboarding processes quietly fail.

Both models have sending limits. Mailbox providers publish per-account daily sending caps — these differ between consumer and business tiers and change over time, so check the current documented figure rather than a number from a blog post. Here, the limits are the inbox’s configurable daily_recipient_limit, which resets at midnight UTC and meters live recipients only, plus the plan allowance. Test sends consume neither.

The structural difference is what happens at the cap. A shared human mailbox that hits its daily limit stops sending the human’s mail too. A dedicated inbox’s cap is scoped to the agent.

What the agent can see that you did not intend

This is the question to sit with before connecting a real mailbox: what is in that mailbox that has nothing to do with the task?

An account used by a person for two years contains calendar invitations, password resets, HR correspondence, recruiting threads, vendor contracts and personal mail that arrived by accident. A mailbox-wide read scope reads all of it, and every one of those messages becomes model context the moment the agent runs a broad search.

A fresh dedicated inbox contains exactly what has been sent to it since it was created. That is not a security control by itself, but it removes a very large category of accident. Combined with a per-inbox grant, the agent’s visible world is small enough to describe in one sentence.

Two related points on the dedicated side, stated plainly. Search covers stored subjects, senders and previews — not full bodies and not attachment contents — so it is a way to find a conversation, not a corpus-retrieval tool. And attachments must pass a safety scan before they can be sent or downloaded; sending one that has not cleared returns HTTP 422 attachment_not_ready rather than silently dropping the file.

Auditing and revoking access

Revoking a mailbox OAuth grant is one entry in a settings page that lists every app the account holder ever connected, and the audit trail lives in your mail tenant’s admin logs — real, but not organised around “what did this agent do”.

On the dedicated side, credentials are first-class objects. An MCP connection is a con_ record with a project, an inbox list, a preset, an expiry 30 days out and a last-use timestamp. An API key is a key_ record with a prefix, scopes and an authorising identity. Both revoke with one call, and both are re-evaluated from current database state on every request rather than trusted from the token — so when the human who authorised a credential loses a role, every credential they created narrows on the next request, without anyone remembering to revoke.

Refresh-token replay on an MCP grant is treated as compromise: the connection is revoked outright rather than issuing another token.

Whichever model you pick, verify revocation instead of assuming it. Make one call with the dead credential and confirm you get a 401.

When connecting an existing mailbox is genuinely the right call

Four cases, and they are common.

The work is in that mailbox. If the task is “triage the last three years of billing@”, the history is the point. A new inbox has no history and never will.

Continuity of an existing address matters. Customers already write to support@example.com. Standing up a parallel address means either redirecting mail or splitting the conversation, and both are worse than connecting.

The agent only reads. A read-only assistant that summarises a shared mailbox each morning and sends nothing carries much less of the risk described above. Mailbox-wide read is still broad, but no message leaves under a person’s name.

You cannot add a domain or a subdomain. If DNS is outside your control, a dedicated inbox on your own domain is not available to you. A platform-domain address is, but it will not look like your organisation.

Pick a dedicated inbox when the agent is going to write, when it will handle mail from outside your company, when you want the From line to be honest about who is answering, or when you expect more than a handful of agents.

Decision table

Neither column is a safety guarantee. Neither prevents prompt injection, neither guarantees inbox placement, and there is no published uptime SLA on either side of this table.

If the dedicated column is the one you want, how to give an AI agent its own email address is the setup path, and test an agent’s email without sending real mail is how to prove it before a real recipient is involved. For the underlying model, how agent inboxes actually work; for the controls named in the table above, sending controls.

inboxes permissions foundations

Keep reading

All guides · Documentation · Inboxes