TL;DR: Sending Gmail from an AI agent is mostly a scope decision, according to Agentic Fabriq: gmail.send supports per-user sending without triggering Google’s restricted-scope security assessment, while broader Gmail scopes add verification, refresh-token complexity, and governance risk. Draft-first design keeps the human in control and fits the narrowest workable permission model.
At a glance
What this is: This is a practitioner guide to sending Gmail through an AI agent using per-user OAuth, with the central finding that gmail.send is the narrowest workable scope and draft-first workflows avoid broader access.
Why it matters: It matters because mailbox access is an identity decision, not just an integration choice: the scope you request determines consent, verification burden, refresh-token handling, and how much authority the agent actually holds.
By the numbers:
- Restricted Gmail scopes trigger a third-party security assessment that must be redone at least every 12 months.
Context
Sending email on behalf of a user sounds like a simple app feature, but it is really a delegated identity problem. The core governance choice is whether the agent should act with narrow, user-granted authority or accumulate broader mailbox access that changes the compliance and trust model.
For Gmail, the distinction matters because the ability to send, draft, read, or manage mail maps to different OAuth scopes and different control burdens. The article argues that an agent should draft in the product and let the user press send, which keeps the authority boundary visible and reduces the scope required.
Key questions
Q: How should security teams choose Gmail scopes for an AI agent?
A: Start with the narrowest scope that matches the business task. If the agent only needs to send a user-approved message, use gmail.send and avoid scopes that read mail, manage drafts, or modify the mailbox. Broader scopes increase consent friction, verification burden, and the amount of authority the delegated identity can exercise.
Q: Why do broad Gmail scopes create more governance risk for agents?
A: Because they change the delegated identity from a sender into a mailbox-capable actor. Once the app can read, draft, or modify mail, the control problem expands from outbound delivery to message handling, data exposure, and review obligations. The issue is not only technical access, but the larger authority boundary the user has granted.
Q: What breaks when an email agent stores OAuth refresh tokens incorrectly?
A: The agent loses its ability to act when the user is absent, or it reconnects unpredictably after password changes, Testing-mode expiry, or repeated reconsent. In practice, that means failed sends, silent disconnects, and confused users. A robust design treats token refresh failure as a lifecycle state, not a rare exception.
Q: What is the difference between draft-first sending and fully automatic sending for AI agents?
A: Draft-first sending keeps the human as the final decision-maker and limits the agent to composition. Fully automatic sending lets the system act without review, which increases the need for stronger governance, tighter policy controls, and explicit user consent. For most outbound business email, draft-first is the safer and easier-to-audit model.
Technical breakdown
Why gmail.send is different from Gmail scopes that touch drafts or inbox access
Google treats Gmail scopes differently based on what data or actions they expose. The send-only scope lets an application deliver mail on behalf of a user without reading the mailbox or writing drafts, while scopes that can read messages, manage drafts, or modify mail are classified as restricted. That classification drives whether the app faces only verification or a more expensive security assessment. The practical effect is that feature design and scope design are inseparable: if the agent only needs to send a user-authored message, broader mailbox access is unnecessary governance overhead. See the NHI Authentication Guide.
Practical implication: Choose the narrowest scope that matches the actual workflow, because every extra mailbox capability expands both review burden and identity risk.
Why draft-first sending changes the identity boundary
A draft-first flow moves the model’s output into the product, where the user can review and decide, instead of letting the agent act directly inside the mailbox. That matters because the draft lives in your application until the human approves it, so the agent never needs to hold broad access to read inbox context or maintain state in Gmail drafts. In identity terms, the decision authority stays with the person while the system provides composition support. This is a narrower delegation model than mailbox automation, and it is easier to reason about from both consent and audit perspectives. See the AI Agent Authorisation Guide.
Practical implication: Keep approval in the product UI when the business task allows it, so the agent never needs broader Gmail authority than sending.
Refresh tokens, offline access, and why testing mode breaks production assumptions
An offline OAuth grant creates a refresh token that can mint new access tokens when the user is absent, but that token has its own lifecycle rules. Testing-mode projects issue refresh tokens that expire after seven days for scopes like gmail.send, and Google also invalidates tokens in cases such as password changes or repeated reconsent. That means the durable credential is not truly durable unless the app is in the right publishing state and the reconnect path is designed. The technical issue is not just token storage, but token continuity under real operating conditions.
Practical implication: Treat refresh-token expiry and invalid_grant as a normal lifecycle event, not an edge case, and design reconnect handling before launch.
Threat narrative
Attacker objective: The practical objective is to send mail from a real user’s Gmail identity while obtaining the smallest possible set of privileges needed to do it.
- Entry occurs when a user authorises the application through OAuth and grants a Gmail scope that determines what the agent can do on their behalf.
- Credential access follows through an offline refresh token, which lets the backend mint new access tokens after the user leaves the browser.
- Escalation happens if the application requests broader Gmail scopes than the task requires, turning a send-only workflow into mailbox-wide authority or draft access.
- Impact is the agent sending messages from the user's account, with the scope choice determining whether the system stayed narrowly delegated or became a broader mailbox risk.
Breaches seen in the wild
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scope choice is the control plane for delegated email identity. In this pattern, the security outcome is determined less by the email feature itself than by whether the agent is allowed to send only, draft only, or read and modify mailbox contents. gmail.send is materially different from scopes that expose existing mail or draft storage because it narrows what the delegated identity can do. The practitioner lesson is that permission design, not message formatting, defines the real trust boundary.
Draft-first email is a governance pattern, not a UX compromise. Keeping the agent in composition mode and requiring a human to press Send preserves accountability at the point of external communication. That design avoids pushing the model into a broader NHI-like authority profile inside the mailbox and makes approval auditable in the application layer. Task-scoped agent authorisation is the cleaner pattern whenever the message can be reviewed before delivery.
Refresh-token durability is the hidden lifecycle problem. OAuth systems often look stable at first connect, but token expiry, Testing-mode limits, password resets, and token churn all create failure states that are easy to miss in early development. The issue is not only credential storage; it is whether the delegated identity can survive normal user and platform change without silently breaking access. Practitioners should treat token lifecycle as part of the identity design, not a backend afterthought.
Per-user consent is safer than tenant-wide delegation for this use case. A rep-level Gmail connection limits blast radius to the person who approved it and matches the actual business need for outbound follow-up. Broad delegation may be convenient for platform operators, but it converts a user task into a shared mailbox authority problem that is harder to justify and harder to revoke cleanly. The governance principle is simple: keep the authority as close as possible to the user who owns the mailbox.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: NHI Authentication Guide
What this signals
Draft-first messaging is a useful boundary for delegated identity. When the agent prepares the message but the human completes the send, the system avoids granting mailbox-wide authority that is difficult to justify for routine follow-up. That design is especially important where user consent, auditability, and revocation all need to remain obvious to the person owning the account.
Ephemeral token trust debt: refresh tokens look durable, but they inherit lifecycle failures from publishing state, password changes, and reconsent behaviour. Teams that treat those tokens as permanent credentials will discover that delegated access can disappear without warning, especially in early-stage deployments and testing environments.
Third-party consent expands the governance surface beyond the immediate user, and 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. The same pattern applies when an agent relies on OAuth grants and downstream services to act in a user’s name.
For practitioners
- Use per-user OAuth instead of workspace-wide delegation Connect each mailbox through the user’s own consent flow so the agent authority matches the person who approved it, not an entire domain.
- Restrict the scope to gmail.send unless inbox access is unavoidable Avoid gmail.modify, gmail.compose, and gmail.readonly until the business case truly requires them, because each broader scope changes the verification burden and the data exposure surface.
- Keep the user in the send step Let the agent draft the message in your product, show it for review, and call Gmail only after an explicit user action confirms the content.
- Plan for refresh-token failure as a normal workflow event Handle invalid_grant, password changes, and token reissuance with a visible reconnect flow, because offline access is only durable if you design for lifecycle breakage.
Key takeaways
- The main risk in agentic email is not MIME formatting, but how much mailbox authority the delegated identity receives.
- Broad Gmail scopes turn a send-only use case into a larger governance problem with more verification, more exposure, and more lifecycle failure modes.
- The safest operational pattern is to draft inside the product, keep the human as the final sender, and treat refresh-token handling as part of identity governance.
Related NHI Mgmt Group resources: NHI Authentication Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on OAuth consent and token handling for delegated Gmail access. |
| NHI-07 — Long-Lived Secrets | Refresh tokens are the durable credentials that outlive access tokens in this workflow. | |
| Recommendation — Use NHI-04 controls to validate OAuth grant flows and prevent unsafe delegated authentication. Apply NHI-07 to rotate, store, and revoke refresh tokens before they become persistent access paths. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article is about an agent acting under user authority and the scope limits that constrain it. |
| Recommendation — Constrain agent privileges to task-scoped actions and require human approval before external sends. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Refresh tokens and OAuth credentials are authenticators that need lifecycle control. |
| Recommendation — Manage OAuth credentials under IA-5 so issuance, storage, rotation, and revocation are controlled. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about how much authority the agent should be granted. |
| Recommendation — Review delegated Gmail entitlements under PR.AA-05 and remove any scope not required for send-only use. | ||
Key terms
- Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
- Broad OAuth Scope: A broad OAuth scope is a permission grant that covers many actions or large portions of an account rather than a narrowly defined task. In agent and integration platforms, broad scopes increase the value of any stolen token and make the connected service more difficult to contain after compromise.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- Draft-First Workflow: A draft-first workflow lets the system prepare content while the human user reviews and authorises the final send. In agentic email, this pattern reduces mailbox authority, preserves accountability, and avoids unnecessary access to inbox data or draft folders.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org