AI Agent Google Workspace and Microsoft 365: Grant Only What It Needs

To connect an AI agent to Google Workspace or Microsoft 365, give it its own identity, choose the narrowest permission type the suite offers, and have an administrator approve only the access the role needs. Google works mainly through OAuth scopes and admin controls over third-party apps. Microsoft works through Entra app registrations, Microsoft Graph permissions and admin consent. In both suites the real work happens before anyone clicks Allow: deciding what the role is, and what it is not allowed to touch.

Key takeaways

• Both suites can scope an agent narrowly, but they use different vocabulary. Google speaks in OAuth scopes and admin app controls. Microsoft speaks in app registrations, Graph permissions and admin consent.
• Choose between delegated access (the agent acts within one account's reach) and application access (the agent acts as itself across the organization) before choosing any scope. Delegated is the safer default.
• Treat read, draft and send as separate grants. Most first roles need only the first two.
• Give the agent its own account, and limit it to the specific folders, calendars, sites or mailboxes the role touches.
• Record what was granted and why, then review it on a schedule, because access tends to grow quietly.

How do the access models of Google Workspace and Microsoft 365 differ?

The two suites solve the same problem with different building blocks. Knowing the building blocks helps you ask the right questions of your administrator and of anyone who builds the integration.

Google Workspace is organized around OAuth 2.0. An application asks for scopes, which are named permissions such as reading mail, composing drafts, sending mail, reading calendar events or accessing files. A user, or an administrator on their behalf, consents to those scopes. The Admin console then adds a control layer: administrators can decide which third-party and internal apps may reach which Google services, and can block or restrict apps that request broad scopes. For background on how consent and scopes fit together, see [Google's OAuth 2.0 documentation](https://developers.google.com/identity/protocols/oauth2). Google also offers service accounts, and with domain-wide delegation a service account can act as users across the domain. That is powerful and should be treated as a high-risk grant.

Microsoft 365 is organized around Microsoft Entra ID and Microsoft Graph. An application is registered in Entra, and it requests Graph permissions that are either delegated or application type. Some permissions require administrator consent. Conditional access policies can add conditions such as device state or location. Exchange Online and SharePoint add their own narrowing tools: you can restrict an app-only identity to selected mailboxes or to selected sites rather than the whole tenant. Menus and exact permission names change over time, so confirm them against current Microsoft documentation when you configure.

A useful way to compare them:

• Unit of permission: Google uses scopes, Microsoft uses Graph permissions. Both are grouped by service (mail, calendar, files).
• Who approves: Google allows user consent unless an administrator restricts it. Microsoft allows user consent only for low-risk cases, and administrators control the rest.
• Where the dangerous shortcut lives: in Google, domain-wide delegation. In Microsoft, application permissions that cover every mailbox or site in the tenant.
• Where narrowing happens: in Google, mostly through narrow scopes, per-file Drive access and sharing. In Microsoft, through selected-resource permissions and Exchange or SharePoint policies.

Neither suite is safer by default. Each is as safe as the grant you make.

Should the agent use delegated or application access?

This is the most consequential choice, and it comes before scopes.

Delegated access means the agent acts through an account. It can only reach what that account can reach. If the account has no access to the finance folder, the agent has none either, whatever the software asks for. This is the easier model to reason about, because the account is a visible boundary that your administrator already knows how to manage.

Application access means the agent acts as itself, with no signed-in user. It suits background work, such as a nightly job that reads a shared mailbox. The cost is breadth: in Microsoft, application permissions typically apply across the tenant until you narrow them, and in Google, the equivalent pattern is a service account with delegation. Both need deliberate restriction.

A practical rule: start with delegated access through a dedicated agent account. Move to application access only when the role truly needs to run without any account, and when you can narrow it to named resources. The reasoning for a separate account is covered in why your company AI agent needs its own identity and accounts. In short, a dedicated account makes every action attributable, lets you revoke access without disturbing a person, and keeps the agent from inheriting an employee's broad permissions.

Avoid connecting the agent through a staff member's personal login. It inherits everything that person can see, it breaks when that person leaves, and the audit trail blurs agent actions with human ones.

What does the role actually need?

Permissions should follow the job, not the suite's menu. Write the role in plain sentences first, then translate each sentence into the smallest grant. The broader principle is explored in least privilege for AI agents, and the three-way split between reading, drafting and sending is covered in read, draft and send as different AI permissions.

Use this decision guide for each task the role performs:

• Needs to find information in documents: grant read access to the named folders, shared drives or sites only. Do not grant access to the whole drive or tenant.
• Needs to read incoming messages: grant read access to one mailbox, ideally a shared or dedicated one, not every mailbox.
• Needs to prepare replies: grant draft creation without sending. A person reviews and sends.
• Needs to send messages: grant send access only after the drafting stage has proven reliable, and keep an approval step for external recipients.
• Needs to read the calendar: grant free and busy or read access first. Add event creation only if the role schedules meetings.
• Needs to create or edit files: grant write access to one designated folder or site. Prefer a per-file or per-location grant over broad edit rights.
• Needs to delete or share externally: default to no. If a real need appears, route it through human approval.

Two extra checks belong in this guide. First, ask whether the agent reads content written by outsiders, such as inbound email or shared documents. That content can contain instructions aimed at the agent, so the permission boundary matters more, not less. The [OWASP guidance on prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) is a good reference. Second, apply the general principle from the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html): enforce access on the server side, deny by default, and check permissions on every request rather than trusting the agent's own judgment.

What is a sensible step-by-step plan for connecting the agent?

This sequence works for either suite. It is deliberately slow at the start and quick at the end.

• Write the role in one paragraph: what the agent does, for whom, and what it must never do.
• List the exact resources involved: which mailbox, which calendar, which folders or sites.
• Create a dedicated agent account with a clear name, a named human owner and no admin rights.
• Share only the listed resources with that account, using the suite's normal sharing controls.
• Register the integration (an OAuth client in Google, an app registration in Entra) with the smallest scopes or permissions that match the guide above.
• Have an administrator review and approve the consent. Do not let the requester approve their own request.
• Test in a sandbox or a copy of the data first. Confirm the agent can do what it should and fails cleanly on what it should not.
• Turn on logging for every read, draft and send, so you can later answer who did what and when.
• Set an expiry or review date for the grant, and name who reviews it.
• Plan for failure: decide what the agent does when a token expires or consent is withdrawn. The behavior is described in what an AI agent should do when a connection expires.

The test step is where hidden over-permissioning shows up. Ask the agent to open something outside its remit. If it succeeds, the grant is too wide, and the fix belongs in the suite, not in the agent's instructions. Instructions are guidance. Permissions are enforcement.

What does this look like in practice? An illustrative scenario

The following is an illustrative scenario, not a description of a real engagement.

A small consulting firm wants an agent that prepares draft replies to inquiries arriving at a shared inbox and proposes meeting times. The role statement says: read the inquiries mailbox, draft replies, check availability for two named partners, never send anything without a person approving it.

On Google Workspace, the firm creates a dedicated agent user and shares the inquiries mailbox access with it. The integration requests read and draft-compose scopes for mail and read access for calendar free and busy information. It does not request send. The partners share their calendars with the agent account at the level that shows availability only. An administrator approves the app in the Admin console and restricts it to the agent account's organizational unit.

On Microsoft 365, the firm creates the same dedicated user and registers an app with delegated permissions for mail read and write (needed to create drafts) and calendar read. Because the mail write permission is broader than drafting alone, the administrator confirms the agent account only has access to the shared inquiries mailbox, and adds a policy to prevent sending from it until the approval step is ready. Calendar access is limited to the two partners.

In both cases the result is the same: the agent can see one inbox and two availability views, it can leave drafts, and a person presses send. Months later, if the firm wants the agent to send routine confirmations, that is a new, explicit grant with its own review, not a quiet expansion.

How does Be Human handle Workspace and Microsoft 365 connections?

Be Human designs, implements and operates this connection as part of managed AI infrastructure. A first engagement defines one useful role, the tools and memory it needs, the approval boundaries and an observable success criterion, then maps each task to the narrowest grant in your suite. The agent gets its own identity, access is scoped to named resources, and your administrator keeps the approval and revocation controls. Managed operations then include permission review, integration maintenance, monitoring and handling of expired or revoked connections, so the access stays as small as the role. Where a standard protocol such as the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) is useful for exposing tools to the agent, the permission boundary still lives in your suite, under your control.

Frequently asked questions

Can one agent work across both Google Workspace and Microsoft 365? Yes, but it needs a separate identity and a separate grant in each suite. Treat them as two integrations that share a role description, and review each one on its own schedule. Do not reuse one suite's access decisions for the other, because the permission names and narrowing tools differ.

Should we use a service account or app-only access instead of a user account? Only when the role truly has to run without any account, and only after you can narrow it to named resources. A service account with domain-wide delegation in Google, or an application permission across the tenant in Microsoft, can reach far more than the role needs. For most first roles, a dedicated delegated account is easier to understand, audit and revoke.

What happens if an administrator revokes consent or a token expires? The agent should stop the affected action, say clearly what failed, and ask for reconnection rather than retrying blindly or working around the block. Plan this behavior before launch, including who is notified and how unfinished work is resumed. Revocation is a normal control, not an incident, and the agent should treat it that way.

Does the agent need MCP to connect to these suites? No. MCP is one way to describe and expose tools to an agent, and it can be useful for consistency across tools. The actual access limits are set by the OAuth scopes, Graph permissions, sharing settings and admin policies in Google Workspace or Microsoft 365, whatever method the agent uses to call them.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.