How to Audit Google Workspace Domain-Wide Delegation

Every domain-wide delegation grant lets a service account or OAuth client act as any user in your Google Workspace, including super administrators, for the scopes listed, and most organisations cannot say who owns each one. This guide is a practical audit: list every client in the Admin console, trace each client ID back to its Google Cloud service account and project, judge whether the scopes are justified, check how the keys behind it are protected and remove what is not needed without breaking integrations. It is for Workspace super administrators, Google Cloud administrators and identity teams. The Google Workspace Domain-Wide Delegation Security Guide explains the mechanism and design choices; this page is the step-by-step review.

Key takeaways

Scopes limit data types, not users: Google Cloud documents that delegation lets a service account impersonate any user, including super admins, and that restricting OAuth scopes limits what data it can reach but not which users.
The grant lives in Workspace, the key lives in Cloud: you audit the Admin console list and the Google Cloud project that owns the service account together, or you miss half the risk.
Keys are the usual weak point: anyone holding a service account key can use it, and Google notes that logs do not reliably show who used it.
Deletion is immediate, propagation is not: Google states that applications relying on a deleted client stop working immediately, while other changes can take up to 24 hours.
Admin log events give you history: AUTHORIZE_API_CLIENT_ACCESS and REMOVE_API_CLIENT_ACCESS record who granted and removed delegation and for which scopes.

When you need this

Annual or quarterly access review: Google's own guidance is to review scopes periodically, remove unneeded ones and delete clients you no longer use.
After a service account key leak: a leaked key for a delegated service account is effectively a leaked credential for every mailbox, drive or calendar in the granted scopes. See the Google Cloud Service Account Keys Security Guide.
After a vendor or integration is retired: SaaS backup, archiving, signature and migration tools often use delegation and are rarely removed when the contract ends.
After an administrator leaves: super admins can add clients, and Cloud project owners can mint keys for the service accounts behind them.
Before enabling an AI assistant or agent with Workspace access: delegation is a common shortcut for agent builders, and broad Gmail or Drive scopes turn one key into organisation-wide data access.

Before you start

Roles: a super administrator for the Admin console (only super admins can manage domain-wide delegation) and a Google Cloud role able to view service accounts, keys and IAM policies across the organisation.
Multi-party approval: if it is enabled, Google states that authorising, editing scopes or deleting a client requires approval from another super admin. Line up the second approver before remediation.
Reports API access: to query admin audit events at scale, an account and OAuth client allowed to call the Admin SDK Reports API.
Integration owner list: start from your SaaS and vendor register so each client ID can be matched to a business owner.
A findings register: client ID, client name, scopes, service account email, Cloud project, owner, key status, last use, decision.

Step-by-step

1. Export the delegation list

In the Admin console go to Menu > Security > Access and data control > API controls > Manage Domain Wide Delegation (direct link admin.google.com/ac/owl/domainwidedelegation).
For each entry in the API clients list, click the client, then View details, and record the full client name, client ID and every scope. Google's help page does not describe an export, so capture the details into your register.
Note entries shown with the name "-". Google states that a deleted client's name shows as "-" in the list; clients with no recognisable name need extra tracing.

2. Pull grant history from the admin audit log

Query the Reports API for the two admin events that record delegation changes:

Event	Parameters	What it tells you
`AUTHORIZE_API_CLIENT_ACCESS`	`API_CLIENT_NAME`, `API_SCOPES`, `DOMAIN_NAME`	Who authorised which client for which scopes, and when
`REMOVE_API_CLIENT_ACCESS`	`API_CLIENT_NAME`, `DOMAIN_NAME`	Which clients were removed and by whom
`ENABLE_API_ACCESS`	`NEW_VALUE`, `OLD_VALUE`	Changes to the organisation's API access setting
`TOGGLE_OAUTH_ACCESS_TO_ALL_APIS`	`NEW_VALUE`	Changes to OAuth access for all APIs

The documented request form is https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/admin?eventName=AUTHORIZE_API_CLIENT_ACCESS. Match each current client to the event that created it to identify the administrator who granted it. Grants with no event in your retained history are older than your log retention and need an owner found another way.

3. Trace each client ID to its service account

A delegation entry is either a service account or an OAuth 2.0 client. For service accounts, the client ID in the Admin console is the service account's numeric unique ID, which the Google Cloud console shows on the service account details page as the OAuth 2 client ID.
Search your Google Cloud organisation for that ID to find the service account email and its project. If you cannot find it in any project you control, the service account belongs to a vendor: the grant trusts a key you cannot see or rotate.
For each service account you own, record who holds roles/iam.serviceAccountTokenCreator, Service Account Key Admin or Editor on it or its project. Google notes that impersonators can access everything the service account can, and that iam.serviceAccountKeys.create is included in the Service Account Key Admin and Editor roles.
List the service account's user-managed keys and their creation dates. Every key is a standing way to exercise the delegation.

4. Review scopes against need

Scope pattern	Risk	Questions to ask
Full Gmail (`https://mail.google.com/`)	Read, send and delete mail as any user	Does the tool need to send or delete, or only read? Can a read-only or narrower Gmail scope work?
Full Drive (`.../auth/drive`)	Read and change every user's files	Could it use a Shared Drive owned by the service account, or a narrower Drive scope?
Admin SDK Directory write scopes	Create users, reset passwords, change groups	Is this a provisioning tool? Is write needed, or only read?
Calendar full access	Read and edit every calendar	Is read-only enough?
Many unrelated scopes on one client	One key opens several data types	Should this be split into separate service accounts per function?

Google Cloud's guidance is to avoid delegation when a task can be done by the service account directly or through the OAuth consent flow, for example uploading files to a Shared Drive as the service account, and to restrict scopes when delegation cannot be avoided.

5. Check usage

Service account authentication: use Activity Analyzer for the most recent authentication events, or the Cloud Monitoring metrics iam.googleapis.com/service_account/authn_events_count and iam.googleapis.com/service_account/key/authn_events_count. Google notes these metrics are kept for six weeks and include failed calls.
Unused accounts: service account insights flag accounts not used in the past 90 days.
Workspace side: review Workspace audit logs for activity by the impersonated users that comes from the integration. See the Google Workspace Audit Log Detection Guide.

6. Decide and remediate

Delete: no owner, vendor contract ended, no use in 90 days, or a service account that no longer exists.
Reduce: edit the client and remove scopes not needed; you cannot change the client ID, only the scopes.
Re-platform: move to Shared Drive ownership, OAuth consent or a dedicated service account per function.
Protect the key: remove user-managed keys and use attached service accounts or workload identity federation where the workload runs. See How to inventory Google Cloud service account keys and replace them with federation.

Verify it worked

Metric	How to measure	Target
Delegation clients with a named owner	Register against the Admin console list	100%
Clients granting full Gmail or full Drive	Scope review	Only those with a documented need
Delegated service accounts with user-managed keys	Key listing per service account	Zero, or each with an exception
Unused clients	Service account insights and authentication metrics	Zero after review
Unreviewed grant changes	`AUTHORIZE_API_CLIENT_ACCESS` events without a change ticket	Zero

After edits, open View details on each changed client and confirm the remaining scopes. Allow up to 24 hours for propagation, then confirm the integration still works and that requests for removed scopes fail.

Rollback and common errors

Deleting a client in use: the integration stops immediately. Rollback is re-adding the same client ID with the previous scopes, which needs a super admin (and a second approver under multi-party approval). Keep the scope list from step 1 so you can restore it exactly.
Removing a scope the app still needs: authorisation calls for that scope will fail. Re-add the scope with Edit and Authorize, then check View details to confirm it is listed.
Authorise fails when adding back: Google lists causes as a client ID not registered with Google, or duplicate or unsupported scopes.
Auditing only Workspace: a well-scoped grant is still dangerous if many people can create keys for, or impersonate, the service account in Cloud.
Assuming scopes protect executives: they do not restrict which users can be impersonated, so a narrowly scoped Gmail grant still covers the CEO's mailbox.
Disabling the service account without telling Workspace owners: the grant stays listed and can be reused if the account is re-enabled. Remove the grant as well.

Hardening afterwards

Block keys by policy: apply the "Disable service account key creation" and "Disable service account key upload" organisation policy constraints, with narrow exceptions. Google notes these are enforced by default for organisations created on or after 3 May 2024.
Require multi-party approval: so no single super admin can add or widen delegation.
Alert on new grants: stream AUTHORIZE_API_CLIENT_ACCESS events to the SIEM and require a matching change ticket.
One function per service account: separate backup, archiving and provisioning so scopes stay small.
Bring vendors into third-party review: ask how the vendor protects the key behind any delegation you grant. See the Cross-Account and Cross-Tenant Access Guide.

Framework	Reference	Relevance
NIST CSF 2.0	PR.AA-05, DE.CM-03	Least-privilege access reviewed; monitoring of service activity
NIST SP 800-53 Rev 5	AC-2, AC-6, IA-5, AU-6	Account review, least privilege, key management, log review
CIS Controls v8.1	Controls 5, 6 and 15	Account and access management, service provider management
ISO/IEC 27001:2022 Annex A	A.5.18, A.5.19, A.8.2	Access rights, supplier relationships, privileged access
MITRE ATT&CK	T1114.002, T1530, T1078.004, T1098.001	Remote email collection, data from cloud storage, cloud accounts, additional cloud credentials

Practitioner checklist

Record every client ID, name and scope from Manage Domain Wide Delegation.
Pull AUTHORIZE_API_CLIENT_ACCESS and REMOVE_API_CLIENT_ACCESS history and match grants to administrators.
Trace each client ID to a service account and project, and flag vendor-owned clients.
List who can create keys for, or impersonate, each delegated service account.
Remove user-managed keys or replace them with attached accounts or federation.
Cut scopes to the minimum and delete unused or ownerless clients.
Enforce the key creation and upload constraints and multi-party approval.
Alert on new delegation grants and re-run this review on a schedule.

How to audit Google Workspace domain-wide delegation grants: find, scope down and remove