In the Google Admin console, open Security, then Access and data control, then API controls. The accessed apps list shows which third-party apps have touched your Google data, how many users each has, and what scopes they requested. From there you can mark each app trusted, limited, specific-scope or blocked.
Why engineering teams should care
Developers sign in with their work Google account to try new tools all the time. Each sign-in can grant an app scopes such as reading mail, files or calendar. The app is now a vendor with access to your data, and it arrived without a procurement step. That is the textbook shape of shadow IT.
This matters beyond office data. Google accounts often anchor access to other developer services, so a risky grant can sit next to something that matters.
Where to look
The path in Google's documentation is Security, Access and data control, API controls, and you need the Service Settings administrator privilege. Three views are useful:
- Manage App Access lists the apps you have configured, with type (Google-owned, internal or third-party), verification status, which org units have a policy and the access level.
- Accessed apps shows apps that have touched Google data, with user counts and the services each uses.
- Apps pending review shows access requests from users.
Open an app to see its OAuth client ID, user count and requested scopes. You can download the list as a CSV, which is the easiest way to start a review spreadsheet.
Access levels, in plain words
| Level | What the app can do |
|---|---|
| Trusted | Access to all Google services, including restricted ones |
| Specific Google data | Access only to the scopes you specify |
| Limited | Access only to unrestricted services |
| Blocked | No access to Google data |
You set a level per organizational unit, so an engineering unit can differ from the rest of the company.
A review routine that fits an afternoon
- Export the accessed apps list as CSV.
- Sort by user count. A single-user app is a different conversation from one with 200 users.
- Look at scopes before names. Broad scopes on a small unknown app are your first calls.
- Find an owner for each app you keep. If nobody claims it, move it to limited or blocked.
- Decide what happens to unconfigured apps. The settings let you choose whether users can sign in with Google to unconfigured third-party apps and whether they can request access.
- Put the next review in the calendar.
Know the delays
Google notes that changes can take up to 24 hours to apply, and app activity can take 24 to 48 hours to show in the lists. Do not conclude an app is gone because it is missing the same afternoon.
Restricting a whole service stops untrusted apps from using it and revokes their tokens. That is a strong control, so announce it first.
Quick check
Do I need to block everything unknown?
No. Limiting access to unrestricted services, or approving specific scopes, can keep useful tools working while removing the riskiest access.
Does this cover tools that do not use Google sign-in?
No. Only apps that use Google OAuth appear here. Other tools need other checks, such as repo searches and source host app reviews. See how to see which OAuth apps can reach your GitHub org.
Safeguard's asset discovery and compliance evidence features can hold the resulting approved list next to your software inventory. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
