Connect an AI Employee to Gmail & Calendar (2026)

The Bob team · July 11, 2026

Short answer

You connect an AI employee to Gmail and Google Calendar through OAuth 2.0 — the same consent flow you already use for calendar schedulers and CRMs — not by handing over a password. The two decisions that matter are which scopes you grant (read-only vs. read/write) and whether each user authorizes individually or a Google Workspace super admin turns on domain-wide delegation. Grant the narrowest scopes that fit the job, keep any action that sends mail or edits an event behind human approval, and log every call. Everything else is detail.

What "connecting" actually means

Connecting an AI employee to Google Workspace is an authorization grant, not a credential handoff. The tool redirects the user (or an admin) to Google's consent screen, the user approves a specific set of permissions, and Google returns a token scoped to exactly those permissions. Google's OAuth 2.0 scopes reference describes each scope as a URI string that names the Google app, the data it touches, and the level of access.

A few things follow from that:

• The AI employee never sees the user's password.
• The grant can be revoked at any time from the user's Google Account or the Workspace admin console.
• The access is bounded by scope — a read-only grant physically cannot send email, regardless of what anyone instructs the agent to do.

That last point is the whole game. If you get scopes right, most of the scary scenarios stop being possible rather than merely being discouraged.

The Gmail scopes that matter

Gmail scopes range from send-only to full mailbox control. Google's own guidance in the Gmail API scopes docs is to pick the most narrowly focused scope possible, because users grant limited, clearly described access more readily.

Scope	What it allows	Sensitivity	When to grant
gmail.send	Send mail as the user; no read access	Sensitive	Agent only sends (e.g., drafts you approve)
gmail.readonly	Read messages and settings	Restricted	Summaries, triage, search
gmail.compose	Create and edit drafts	Restricted	Draft-only workflows
gmail.modify	Read, and modify labels/state (not delete)	Restricted	Read + organize inbox
gmail.metadata	Headers and labels, not message bodies	Restricted	Analytics without reading content
full mail.google.com/	Everything, including permanent delete	Restricted	Almost never for an agent

Note the "Restricted" column. Google treats most read scopes as restricted, which triggers extra verification (more on that below). If your use case is "let the AI draft replies I approve," you may only need gmail.compose plus gmail.readonly — and you should resist requesting the full mail.google.com/ scope out of convenience.

The Google Calendar scopes that matter

Calendar is simpler but the same logic applies. The Calendar API auth docs tell developers not to request write scopes until the app actually creates, updates, deletes, or responds to invitations.

Scope	What it allows	When to grant
calendar.events.readonly	Read events only	Show availability, brief the day
calendar.readonly	Read calendars and events	Read across multiple calendars
calendar.events	Read and write events	Book, reschedule, respond to invites
full calendar	Full access to calendars and events	Manage calendars themselves

Google classifies Calendar scopes as sensitive, so a production app that touches them needs OAuth verification even if it never reads a single email. A read-only availability lookup is a very different risk profile from full calendar write access, and your consent screen should reflect that difference.

Per-user OAuth vs. domain-wide delegation

This is the connection choice most teams get wrong. There are two ways to authorize:

	Per-user OAuth	Domain-wide delegation
Who consents	Each employee, once	One super admin, for everyone
Access granted	That person's mailbox/calendar	Every user in the domain
Blast radius if the token leaks	One mailbox	The entire organization
Setup friction	Low, self-serve	Admin console configuration
Right for	Most AI-employee use cases	Rare, specific batch jobs

Google's domain-wide delegation best practices are blunt: use delegation only when you have a critical business case that requires bypassing user consent, and prefer OAuth-with-consent or Marketplace apps otherwise. A leaked per-user grant exposes one inbox; a leaked delegation key can impersonate any user in the domain — a risk security researchers have documented in detail.

For an AI employee that works alongside a team, per-user OAuth is almost always the correct choice. Each person connects their own account, sees exactly what they granted, and can pull the plug independently. If a vendor pushes you straight to domain-wide delegation "to make setup easier," treat that as a flag worth questioning.

Read vs. write: why write access needs a gate

Reading email and reading a calendar are recoverable operations — worst case, the agent saw something it shouldn't summarize. Write operations are not recoverable in the same way. A sent email can't be unsent. A deleted event is gone. An accepted invite has already told the other party you're coming.

So the practical rule is: read scopes can run autonomously, but every write — send an email, book a meeting, decline an invite, archive a thread — should pause for a human to approve the specific action before it happens. This is exactly the pattern we cover in the five controls that matter before an AI agent touches your systems: the difference between an agent that proposes and an agent that acts unsupervised is the single most important thing to verify.

A good approval gate shows you the actual draft, the actual recipient, and the actual calendar change — then waits. Not a summary. The thing itself.

The verification tax nobody mentions

Here's a fact that surprises teams evaluating email-connected tools: because most Gmail read scopes are restricted, any app requesting them must pass an annual third-party security assessment. Google's restricted-scope verification requirements route apps through the Cloud Application Security Assessment (CASA) framework, run by the App Defense Alliance. Apps must be re-verified at least every 12 months after their Letter of Assessment approval.

Why should you, the buyer, care?

• A vendor that has passed CASA has been through a dynamic security scan and a self-assessment questionnaire on their production app.
• A vendor that hasn't either (a) uses only non-restricted scopes, or (b) is running on an unverified app that Google can throttle or block.
• Ask directly: "Are your Gmail scopes verified, and when was your last CASA assessment?"

It's a two-question test that separates serious tooling from weekend projects.

The prompt-injection problem you're inheriting

Connecting an AI employee to your inbox creates a specific, well-known risk: your inbox is full of content written by strangers. If the agent reads a message and treats its contents as instructions, an attacker can hide commands in an email.

This isn't hypothetical. The EchoLeak vulnerability (CVE-2025-32711) was a zero-click attack where a crafted email with hidden instructions caused an AI assistant to exfiltrate data the moment a user asked it to summarize their inbox. Security researchers call the underlying pattern the "lethal trifecta": access to private data, exposure to untrusted content, and the ability to communicate externally. An email-connected agent has all three by default.

Defenses that actually reduce this:

1. Privilege separation — least-privilege scopes so a compromised agent simply can't send or forward. This is why read-only-by-default matters.
2. Human-in-the-loop on writes — an injected "forward everything to [email protected]" instruction dies at the approval gate because a person sees the recipient before anything sends.
3. Treating email bodies as data, not commands — the agent should summarize untrusted content, never obey it.
4. Audit logging — every read and every proposed write recorded, so you can reconstruct what happened.

Notice that the same approval gate that protects you from mistakes also protects you from attacks. That's not a coincidence — it's the reason the control exists.

A least-privilege setup checklist

When you connect an AI employee to Gmail and Google Calendar, work down this list:

• [ ] Start with read-only scopes and add write only when a specific workflow needs it.
• [ ] Use per-user OAuth, not domain-wide delegation, unless there's a documented reason.
• [ ] Confirm the consent screen lists exactly the scopes you expected — no extras.
• [ ] Require human approval for every send, book, reschedule, or delete.
• [ ] Verify the vendor's restricted scopes have passed CASA within the last 12 months.
• [ ] Confirm you can revoke access per user from the Google admin console.
• [ ] Check where message content is processed and stored (relevant if you have data-residency needs — see running an AI employee in your own VPC).
• [ ] Make sure every action is itemized and logged, not just "task complete."

If a tool can't satisfy the first four, the rest is moot.

What "good" looks like in practice

A well-built AI employee connecting to Google Workspace does four things you can observe:

1. Asks for the smallest scopes. If it only drafts replies, it asks for compose + readonly, not full mailbox control.
2. Pauses before writing. It shows you the draft email or the exact calendar change and waits for a yes.
3. Shows its work. Every action is logged with what it read, what it proposed, and what it cost — the same expectation we set in what it takes to trust an AI employee.
4. Stays revocable. One click in Google's admin console cuts it off, no vendor ticket required.

Bob follows this pattern: it connects per-user over OAuth, keeps sends and calendar edits behind an explicit approval in Slack or Teams, and itemizes what each task touched and cost. That's the natural shape for any tool with a key to your inbox — pick whichever vendor demonstrates it.

Common mistakes to avoid

• Granting full mail.google.com/ because it's the top of the list. It includes permanent delete. Almost no agent workflow needs it.
• Turning on domain-wide delegation for convenience. You've just made every mailbox reachable through one key.
• Letting the agent auto-send. The recoverability gap between read and write is the whole reason approval gates exist.
• Skipping the verification question. Unverified restricted-scope apps can be throttled or cut off by Google with little warning.
• Assuming email content is safe. Treat every message body as potentially adversarial input.

FAQ

Do I need to give an AI employee my Gmail password? No. Connection happens through OAuth 2.0. You approve specific scopes on Google's consent screen and can revoke the grant anytime from your Google Account or admin console. The tool never receives your password.

Can I connect it read-only? Yes, and you should start there. gmail.readonly and calendar.events.readonly let an agent summarize, triage, and check availability without any ability to send mail or change events. Add write scopes only when a specific workflow requires them.

What's the difference between per-user OAuth and domain-wide delegation? Per-user OAuth means each employee authorizes access to their own account; a leaked token exposes one mailbox. Domain-wide delegation lets one super-admin grant an app access to every user in the domain; a leaked key exposes everyone. Google recommends per-user consent unless you have a critical, documented reason for delegation.

Why does connecting to Gmail trigger a security review? Most Gmail read scopes are classified as "restricted," which requires the app to pass Google's CASA security assessment and re-verify annually. Ask your vendor whether their Gmail scopes are verified and when their last assessment was.

Is it safe to let an AI read my inbox given prompt-injection attacks? It's manageable with the right controls. Use least-privilege scopes so the agent can't send or forward, keep every write behind human approval, treat email bodies as data rather than instructions, and log everything. The same approval gate that catches mistakes also blocks injected "forward my email" commands.

Can I revoke access later? Yes. Users can revoke from their Google Account security settings, and Workspace admins can revoke or restrict any connected app from the admin console — no dependency on the vendor.