Domain-Wide Delegation in Google Workspace™: Powerful, Dangerous, and Often Misunderstood

In a previous post, we looked at who owns the service account behind a Google Workspace™ integration — your project, or the vendor's. That's the identity question.

This is the next rung up the ladder: once a service account exists, what can it actually do inside your domain? The answer, almost always, is domain-wide delegation — and it is the single most powerful, least understood setting in Google Workspace administration.

What Domain-Wide Delegation Actually Does

A service account on its own can't touch your users' data. It's just an identity sitting in a Google Cloud project. Domain-wide delegation (DWD) is the bridge that changes that.

When you authorize a service account for DWD in the Google Admin™ Console, you grant it one specific, extraordinary power: the ability to impersonate any user in your domain for a defined set of scopes. The flow is mechanical and unattended:

1. The service account requests an access token, asserting it acts as [email protected].
2. Google checks that the account's client ID is authorized for the requested scopes.
3. Google returns a token that is that user, for those scopes.
4. The integration calls the API as the user — reading their mail, their files, their calendar — with no consent screen, no notification, and no click from the user.

That last point is what trips people up. Normal OAuth asks the user to approve. DWD doesn't. The admin approved it once, for the whole domain, and from then on the impersonation is silent.

Why Google Built It

DWD is not a loophole. It exists because an entire category of legitimate tooling can't function without it.

Backup tools have to read every mailbox, not just the admin who installed them. Migration tools have to write to thousands of accounts at once. Compliance and monitoring platforms have to inspect settings across the domain. eDiscovery has to reach data the investigating admin doesn't personally own. None of that works through per-user consent at scale.

So Google gave service accounts a way to act on behalf of users programmatically. The mechanism is sound. The risk is in how it's scoped.

Where the Risk Actually Lives

The danger of DWD is not the delegation itself. It's the combination of scope plus impersonation.

A single scope tells you almost nothing until you multiply it by every user in the domain. Consider one line in a DWD authorization:

https://www.googleapis.com/auth/gmail.readonly

Granted to one app, that scope means: this service account can read the full contents of every mailbox in your organization — including [email protected], [email protected], and [email protected] — without anyone being notified. Not metadata. Not subject lines. The actual email.

Now stack the common ones. drive (not drive.readonly) means read and write and delete across every Google Drive™ in the domain. gmail.settings.sharing means the app can add forwarding addresses and delegates to any mailbox. The scope string is short; the blast radius is the entire company.

This is why a DWD grant deserves more scrutiny than almost any other access decision an admin makes. A compromised user account exposes one person. A compromised DWD service account with broad scopes exposes everyone, quietly.

What Safe Domain-Wide Delegation Looks Like

Safe DWD is not "no DWD." It's disciplined DWD. Three principles:

Minimal scopes. Grant only the scopes the integration genuinely needs, and prefer the narrowest variant. If a tool only reads directory data, it does not need anything that touches Gmail™. If it audits settings, it does not need to read message bodies. .readonly over read-write, .settings.basic over full mail access.

Read-only by default. Write scopes (drive, gmail.modify, gmail.settings.sharing) should be the exception you can justify out loud — not the default you clicked through. A monitoring tool almost never needs them.

Revocable and reviewed. Every DWD grant lives in Admin Console → Security → API Controls → Domain-wide delegation as a client ID with a scope list. You can revoke any of them in seconds. The problem is almost never that you can't revoke — it's that no one is looking.

The Four Questions to Ask About Every DWD Grant

Before you authorize a service account for domain-wide delegation — or when you audit the ones already there — ask:

1. What scopes is it requesting, exactly? Read the full list, not the marketing description. Map each scope to a capability.
2. Why does it need each one? If the vendor can't explain why a backup tool needs write access to Gmail settings, that's your answer.
3. Is the data stored, or just analyzed? A tool that reads mailboxes and retains the content is a fundamentally different risk than one that inspects a setting and keeps nothing.
4. Can you revoke it, and would you notice if it changed? Confirm the client ID is yours to remove — and that someone owns the job of reviewing the list.

Most DWD risk dies at question 2.

How MonitorWorkspace Approaches This

We built MonitorWorkspace around the principle that a monitoring tool should never hold more power than its job requires.

By default, the platform requests configuration scopes, not content scopes — admin.directory.user.readonly to see your directory, gmail.settings.basic to read forwarding rules, delegates, and filters. It does not request gmail.readonly to monitor a mailbox's settings, because reading the settings doesn't require reading the mail. Content access (for features like admin-initiated email transfer) is separate, opt-in, and audit-logged every time it's used.

It also runs on the customer-owned service account model from the first post in this series: the DWD grant lives in your Google Cloud project, with your client ID, revocable by you at any time. We never hold the credential.

That's the through-line of this whole series. Delegation is necessary. Unreviewed, over-scoped delegation is how a single integration becomes a domain-wide liability.

In the next post, we look at the same problem from the user's side — the OAuth grants your org accumulated and forgot about.

See how MonitorWorkspace audits Workspace access →