Secure Google Workspace access for AI agents

Through Google Workspace, agents can search and draft mail, read and create Drive files, manage calendar events, read and send Chat messages, and look up people in your directory — every call runs through your policies and is logged for audit. A single catalog resource covers all five surfaces, and each user acts only as themselves: the tools inherit that user's own Workspace permissions.

Prerequisites

• A Google Cloud project you control, parented to your Cloud organization. Billing is not required, but org parentage is if you want the Internal consent audience.
• An accepted Developer Preview enrollment for that project. Google gates the Workspace MCP endpoints behind its Developer Preview Program, and every tool call fails until enrollment is accepted — apply early, because acceptance can take time (see Enroll in the Developer Preview).
• A Google Workspace account for every user who will use these tools. Consumer Gmail accounts can connect, but the Chat and directory tools only return data for Workspace accounts.
• A Google Workspace super admin able to configure the OAuth consent screen, trust the OAuth client in the Admin console, and, if you publish the app externally, take it through Google's verification process.
• Both the product API and its MCP service enabled in the project (see Create the project and enable the APIs). Enabling the Gmail API alone is not enough — Google ships each MCP surface as a separate service.

Setup

1. Navigate to Resources and click Add Resource
2. Select Google Workspace from the catalog
3. Enter the Client ID and Client Secret of your own Google OAuth client (see Bring your own app) and click Add

The resource is added with all tools and scopes pre-configured, and an Admin setup required dialog appears with a Setup guide button linking back to this page. Each user then connects their own Google account through OAuth the first time they use a Google Workspace tool. Navigate to Connections to manage linked accounts.

Credential modes

Google Workspace supports one mode today:

• Bring your own app — use a Google OAuth client owned by your organization, in a Google Cloud project you control.

Use SecureAuth's app is not offered for Google Workspace. Google's Workspace scopes are classed as sensitive and restricted, so a shared multi-tenant app would have to pass Google's restricted-scope verification and would still surface a SecureAuth-branded consent screen to your users. Owning the client keeps consent, scope review, and revocation inside your own tenant. Google also does not support dynamic client registration on its authorization server, so every install starts from a client you register yourself.

See Credential modes for the full comparison.

Bring your own app

The flow has three phases: collect the redirect URI from SecureAuth, create and configure the OAuth client in Google Cloud, then return to SecureAuth with the credentials.

SecureAuth side — get the redirect URI. In the Agent Authority console, go to Resources > Add Resource > Google Workspace and copy the redirect URI shown on the page. Keep the page open — you return to it at the end of this flow to paste the Client ID and Client Secret.

Google Cloud side — enable the APIs and create the client. Sign in to console.cloud.google.com, then work through the six steps below. They all target one Cloud project, created under your Cloud organization.

1. Enroll in the Developer Preview

Google delivers the Workspace MCP servers through its Developer Preview Program, and the endpoints are gated on it. Until your project's enrollment is accepted, every tool call fails with The caller does not have permission, no matter which scopes you publish, whether the client is trusted, or how valid the token is.

Open developers.google.com/workspace/preview, sign in with an account on your Workspace domain, and enroll the project that will own the OAuth client. Wait for the status to read accepted — Submitted is not enough. Enrollment gates all five products, so do this before anything else. Enrollment is tied to a specific project, so if you do not have one yet, create it first (step 2) and come back.

2. Create the project and enable the APIs

Create the project under your Cloud organization, then point the gcloud CLI at it. Org parentage is what makes the Internal consent audience available in step 3:

gcloud organizations list
gcloud projects create PROJECT_ID --name="PROJECT_NAME" --organization=ORG_ID
gcloud config set project PROJECT_ID
gcloud projects describe PROJECT_ID

gcloud organizations list gives you the ORG_ID to pass to projects create. The describe call at the end confirms the project is ACTIVE and that its parent is the organization, not your personal account.

Each Workspace surface then needs two services enabled: the product API and its MCP service. Enable all ten under APIs & Services > Library, or in one command:

gcloud services enable \
  gmail.googleapis.com gmailmcp.googleapis.com \
  drive.googleapis.com drivemcp.googleapis.com \
  calendar-json.googleapis.com calendarmcp.googleapis.com \
  chat.googleapis.com chatmcp.googleapis.com \
  people.googleapis.com \
  --project=PROJECT_ID

The People MCP surface is served by people.googleapis.com itself, so it has no separate MCP service. Confirm all ten landed:

gcloud services list --enabled --project=PROJECT_ID | grep -iE "gmail|drive|calendar|chat|people"

3. Configure consent and publish scopes

Consent settings live under Google Auth Platform, split across three screens:

• Branding — set an app name your users will recognize on the consent screen, plus a user support email. Check that the project picker shows the project from step 2.
• Audience — Internal if every user is in your Workspace organization. Internal apps skip Google's verification review entirely, which is the fastest path and the recommended one. Choose External only if you need to connect accounts outside your organization. While an app is in Testing, only listed test users can connect, so publish it when you are ready for the whole organization.
• Data Access — click Add or remove scopes and add all 28 scopes listed under Required scopes. If a scope is not in the list, paste it into Manually add scopes. Click Add to table, then Update, then Save.

Every scope the resource requests must be present on Data Access, or consent fails with invalid_scope. Several of these scopes are marked Sensitive or Restricted by Google. For an Internal app you can add them and continue. For an External app, Google requires verification before the app leaves testing, and the restricted Gmail and Drive scopes trigger a security assessment — budget weeks, not days.

4. Create the OAuth client

Under Google Auth Platform > Clients, click Create client:

• Application type — Web application
• Name — your preferred name, for example Agent Authority
• Authorized redirect URIs — click Add URI and paste the redirect URI you copied from the Agent Authority console

Click Create. Google shows the Client ID and Client secret once — copy both now.

5. Trust the app in the Admin console

Workspace classes these scopes as sensitive and restricted, so admin policy blocks them regardless of what an individual user consents to, until the OAuth client is trusted. One trust covers all five products, because they share one client.

In the Google Admin console, go to Security > Access and data control > API controls > App access control. Click Add app > OAuth App Name or Client ID, enter the Client ID from step 4, select the app, and set access to Trusted.

If the setting shows a per-OU Overridden status, confirm the connecting user's org unit is covered, or set Trusted at the org root. Admin changes take a few minutes to propagate: make one change, wait, then test once.

6. Configure the Chat app

The Chat tools need a Chat app configured in the same project. Under APIs & Services > Google Chat API > Configuration, set an app name and avatar, and leave interactive features disabled — the gateway calls the Chat API directly and does not receive Chat events. Without this configuration the four Chat tools return errors while the other 33 tools work normally.

SecureAuth side — enter your credentials. Return to the Agent Authority console page you left open. Paste the Client ID and Client Secret, leave Token Endpoint Authentication on Auto-detect, then click Add. The Google Workspace resource is now configured for your organization, and users can begin connecting their accounts through Connections.

Re-authorize after changes. Editing the resource, changing the published scopes, or trusting the client later does not upgrade a token that has already been issued. Revoke the connection in Connections and reconnect to mint a fresh one.

Available tools

All 37 tools below ship with the catalog entry, so they appear in tool lists and policy pickers as soon as the resource is installed. Each tool is routed to the Google MCP server that serves it, and the live tool definitions are refreshed from those servers when the first user connects.

Gmail

Gmail has no send tool. Agents can draft mail, and a person sends it from Gmail.

Drive

Calendar

Chat

People

Required scopes

These are the 28 scopes the gateway sends in the authorize request, and the same list you add to the OAuth consent screen. All except the three identity scopes take the https://www.googleapis.com/auth/ prefix.

Identity — openid, email, profile

Gmail — gmail.modify, gmail.readonly, gmail.compose, gmail.labels

Drive — drive, drive.readonly, drive.file

Calendar — calendar, calendar.readonly, calendar.events, calendar.events.readonly, calendar.events.freebusy, calendar.freebusy, calendar.calendarlist, calendar.calendarlist.readonly

Chat — chat.spaces.readonly, chat.messages.readonly, chat.messages.create, chat.memberships.readonly, chat.users.readstate.readonly

People — contacts.readonly, contacts.other.readonly, directory.readonly, userinfo.profile, userinfo.email

The set is deliberately narrower than what Google offers. It excludes https://mail.google.com/ (permanent deletion), the Gmail settings scopes (mail forwarding and delegation), gmail.send, the Chat space and membership write scopes, and contact write access — none of which any shipped tool needs. It also excludes gmail.metadata: a token carrying that scope is forced into metadata-only mode by the Gmail API even when fuller read scopes are granted, which breaks message search and message bodies.

Scopes are requested at connect time, so a user's consent screen lists exactly the access above. Narrowing further is possible by removing tools, but a scope removed while its tool ships means that tool fails at call time.

Policy examples

Rules are evaluated top to bottom and the first match wins. Allow rules on their own restrict nothing — your org starts with a seeded Allow all rule, so any tool your allows don't cover still falls through to it. A restrictive recipe needs a catch-all deny scoped to this resource, ordered below the allows. New rules are inserted at the top of the list, so create them in reverse order or drag them into place. See Policies.

• Read-only access. Allow search_*, get_*, list_*, and read_*, then deny * below them.
• Block anything that leaves the org. Deny send_message and create_draft above any allow rules.
• Block destructive operations. Deny delete_event, apply_sensitive_thread_label, and apply_sensitive_message_label.
• Mail triage without calendar changes. Allow search_threads, get_thread, get_message, and *_label*, then deny *_event, then deny *.
• Drive reads but no writes. Allow search_files, list_recent_files, get_file_*, and read_file_content, then deny create_file, copy_file, and download_file_content.
• Allow full access for a specific agent. Scope an allow rule for * to that agent on this MCP server.

Tool patterns are case-sensitive and match exactly unless they contain *, so the lowercase snake*case patterns above (get*_, not Get_) are what match Google Workspace tool names.

Next steps

• Create a policy — start from the read-only pattern in Policy examples above.
• Credential modes — understand what bringing your own app means for consent and revocation.