Guide
Agent Account vs Delegated OAuth
An AI agent can own a managed inbox or OAuth into a user's mailbox. Compare agent accounts and delegated access on setup, isolation, and shutdown blast radius.
Written by Aaron de Mello Senior Engineering Manager
What's the difference between an agent account and delegated OAuth?
An agent account gives an AI agent a fresh, managed email identity that the agent owns outright, such as bot@yourapp.nylas.email. Delegated OAuth connects the agent to a human's existing mailbox after that person grants consent, so the agent reads and sends as the user.
The split is ownership: one inbox starts empty and belongs to the agent, the other is full of a person's mail and belongs to them. That ownership line drives every other trade-off. An agent account holds zero personal history on day one, so an injected instruction in an inbound email has no private threads to reach. A delegated mailbox can hold years of mail, which is exactly the private data a prompt-injection attack wants. The same CLI sends and reads from both, but the blast radius behind each is different by design.
When should an AI agent get its own inbox?
Give an AI agent its own inbox whenever it acts as itself rather than on behalf of one named person. Support bots, signup agents, notification senders, scheduling assistants, and any autonomous worker that runs without a human session fit this pattern.
The agent needs a real, addressable identity, and it should not be able to see a person's private mail to do its job. An agent account is the right default for production agents because containment lives outside the agent's decision loop. The inbox starts with no contacts and no history, outbound rules cap what the agent can send, and suspending the whole pipeline is a single operation. On the free tier you can connect up to 5 accounts, and a new agent inbox is live the moment create returns — no Google Cloud project, no app-verification queue, no DNS records.
When is delegated OAuth the right choice?
Delegated OAuth is the right choice when the agent must operate inside a specific user's real mailbox: triaging the threads already in their inbox, replying from their actual address, or reading mail that only exists in their account. A personal assistant that drafts replies in your own Gmail needs your mailbox, not a fresh one.
There's no way to fake that with a separate inbox. The cost is operational weight. Delegated access runs the OAuth 2.0 authorization-code flow defined in RFC 6749, which means a real consent screen per provider. According to Google's OAuth API verification documentation, apps requesting restricted Gmail scopes must pass Google's verification — and, for server-side access to restricted data without an applicable exception, an annual third-party security assessment — before they can serve an uncapped number of users. Microsoft's platform is documented to require registering an Entra application and consenting to Graph mail permissions. Delegated access also inherits the user's full inbox: the agent sees every thread, and revoking access means clearing one grant per connected mailbox, not one identity.
Agent account vs delegated OAuth: side by side
The two models differ on five practical axes: what the agent can see, how long setup takes, whose identity the mail carries, the prompt-injection blast radius, and how you shut it off. The table below compares them directly. The agent-account column is the safer default for autonomous workloads; the delegated column wins only when a specific human mailbox is the target.
| Dimension | Agent account | Delegated OAuth |
|---|---|---|
| What the agent sees | Empty inbox, no personal data | The user's entire mailbox |
| Setup time | Seconds, one command | App registration + user consent |
| Identity on sent mail | The agent's own address | The user's address |
| Injection blast radius | No private threads to reach | Full inbox is exposed |
| Shutdown | One account delete | One grant revoke per mailbox |
| Best for | Autonomous agents acting as themselves | Assistants inside one human inbox |
How do you set up each one?
Both paths use the same CLI, so an agent's code calls the identical email send and email list commands regardless of which identity backs them. An agent account is provisioned in one step and returns a live inbox; delegated OAuth opens a browser consent flow for the chosen provider.
The nylas agent account create command provisions a managed inbox the agent owns. Pass the address you want and read the result as JSON so your provisioning script can store the grant. One command replaces a Google Cloud project, an OAuth consent screen, and MX records.
# Path A — give the agent its own managed inbox
nylas agent account create support@yourapp.nylas.email --json
# The agent then reads and sends from its own identity
nylas email list --unread --json
nylas email send --to customer@example.com --subject "Re: order" --body "On it."The nylas auth login command connects an existing user mailbox through delegated OAuth. The --provider flag picks the consent flow. A Google access token expires after 3,600 seconds, and the CLI refreshes it automatically before it lapses so the agent never re-prompts. After consent, the same email list command now reads the user's real inbox.
# Path B — connect a user's existing mailbox via delegated OAuth
nylas auth login --provider google
# Now the agent reads and sends inside the user's mailbox
nylas email list --unread --jsonWhat happens when you need to shut an agent off?
Shutting an agent off is where the two models diverge most. An agent account is one identity, so one command ends every read and send it can do. Delegated access spans every mailbox the agent connected, so containment scales with the number of grants — revoke them one at a time, and any you miss stays live.
Deleting the agent account removes the inbox and the grant behind it in a single call. Because the agent never held a user's mail, there's nothing left to clean up and no personal data to worry about. This is the fast path when an agent misbehaves.
# Agent account — one identity, one shutdown
nylas agent account delete support@yourapp.nylas.email
# Delegated OAuth — revoke the grant for each connected mailbox
nylas auth revoke grant_abc123For a deeper containment model — outbound rules, kill switches, and prompt-injection defense that sit outside the agent's reasoning — pair the agent account with rules and policies. The lethal trifecta of private data, untrusted content, and external communication is far easier to break when the agent's inbox holds no private data in the first place.
Next steps
- Getting Started with Agent Accounts — the workspace model and grant lifecycle behind the agent inbox
- Create an AI Agent Email Identity — provision a dedicated inbox and send your first message in 2 minutes
- Agent Rules and Policies — every trigger, condition, and action for outbound containment
- Stop Your AI Agent From Going Rogue — the full lethal-trifecta containment model for agents that read untrusted email
- Revoke an AI Agent's Email Access — the off switch for a delegated grant when a user disconnects
- Connect an Agent to Gmail and Outlook — give one agent delegated access to two providers at once
- Full command reference — every
nylas agentandnylas authsubcommand