Apps that request Google's restricted scopes for consumer data must go through scope verification, and apps that access restricted data from or through their own server must undergo an annual security assessment by a Google-approved third party. For a buyer, that is useful evidence, but several exceptions mean it will not always apply.
What a scope is, and why restricted ones matter
An OAuth scope is the permission an app asks for when you click "Allow". Google groups scopes by sensitivity. Its documentation says restricted scopes provide wide access to Google user data, which is why they carry extra requirements. Think of reading all of a mailbox or all files in a drive, compared with reading a single calendar event.
When your staff connect a third-party app to Google Workspace, they are granting one or more of these scopes. If you want to find which apps hold grants today, see how to find third-party apps with access to Google Workspace data.
What Google's documentation requires
From Google's app verification documentation:
- Apps requesting sensitive or restricted scopes to access consumer data need additional verification and possibly a security assessment.
- Developers must review their scopes, request the minimum necessary access, and declare scopes accurately in the Cloud Console.
- An app that accesses restricted data from or through a third-party server must complete an annual security assessment by a Google-approved third party.
The exceptions
The documentation lists situations where the verification requirements do not apply:
| Exception | What it means in practice |
|---|---|
| Personal use | The app is used by its own developer |
| Development, testing and staging | Not in production use |
| Service owned data only | The app does not touch user data |
| Internal use within an organization | A company's own internal app |
| Domain wide installation | Installed by a Workspace administrator for the whole domain |
The last two matter to you. If an admin installs an app domain wide, the verification path described above may not be what protects you, so your own review carries more weight. That is a reading of the exceptions list, so confirm the details for your own setup in Google's documentation.
How to use this in vendor review
- Ask which scopes the app requests. Get the exact list, not a description.
- Check that each scope matches a feature. A calendar tool that asks for full mailbox access needs an explanation.
- Ask whether the app is verified. Verification is evidence of process, not a recommendation.
- For restricted scopes, ask for the assessment. Ask who performed it and when. A vendor that went through the process should be able to say.
- Set the Workspace controls. Google Workspace lets admins mark apps trusted, limited or blocked. Our post on Google Workspace API controls covers the options.
What the assessment does not prove
An annual assessment is a snapshot at one point in time. It does not state that the vendor will handle your data in line with your own policies, that subprocessors are acceptable to you, or that the app's other features outside Google data are secure. It also does not tell you whether the app has been compromised since.
A verified brand and a passed assessment lower the odds of a careless vendor. They are one input, next to your own review of data flows, support and exit terms.
Safeguard is built for the software you develop: asset discovery, dependency scanning, reachability analysis and compliance evidence. If you are building your own Google integration, the same minimum scope discipline applies, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Does every Google connected app get a security assessment?
No. The documentation describes exceptions, including personal use, testing, internal use and domain wide installation. The annual assessment applies to apps accessing restricted data from or through a third-party server.
Is a verified app safe to approve?
Verification is evidence that the developer met Google's requirements. You still need to check scopes, data flows and vendor terms for your own use.
Sources
Last reviewed: 19 October 2026.
