How to See Which AI Tools Have Access to Your Google Workspace

You can see every AI tool with OAuth access to your Google Workspace from the Admin console, under Security → Access and data control → API controls → App access control. It lists every third-party app authorized in your domain — including AI assistants, browser extensions, and meeting-notetaker bots — along with the Google data each one has been granted.

This guide walks through that path, what the console actually shows, where it runs out, and how to keep the list current once you have it.

Where do I find third-party app access in the Google Admin console?

1. Sign in to admin.google.com as a super admin or an admin with the Services privilege.
2. Go to Menu → Security → Access and data control → API controls.
3. Click Manage App Access (also labeled App access control in some console versions).

You land on a list split into Configured apps (apps your organization has explicitly set an access level for) and Accessed apps (every app currently in use, whether or not you have configured it). For each app you can see:

• The app's name, publisher, and OAuth client ID.
• Whether it carries Google's app-verification badge.
• The individual Google service scopes it requests — Drive, Gmail, Calendar, Admin Directory, and so on — expandable per app.
• How many users in your domain have authorized it.
• The access level you can set: Trusted, Limited, Specific Google data, or Blocked.

You can also export the full list as a CSV, and apply different access levels to different organizational units rather than the whole domain at once.

How do I tell which of these apps are AI tools?

Google's console does not tag anything as "AI" — it lists every OAuth-connected app the same way, whether it is a spreadsheet add-on or a large-language-model assistant. In practice, AI tools show up under names like an AI vendor directly (OpenAI, Anthropic, Perplexity), a meeting-notes bot (Otter.ai, Fireflies, Fathom), a writing assistant (Grammarly, Jasper), or a narrower add-on ("GPT for Sheets and Docs," "AI Email Writer") whose publisher name gives no hint of what it does. Recognizing them is a manual pattern-matching exercise: skim the app and publisher names, and check the requested scopes — an app asking for drive.readonly or gmail.readonly alongside a name you don't recognize is worth a closer look regardless of category.

How do I check which AI tools a specific person authorized?

The domain-wide view above tells you an app has users; it does not tell you *who*, or when they authorized it. For that:

1. Go to Menu → Directory → Users and open the person's account.
2. Open their Security tab.
3. Scroll to Connected applications.

That section lists every third-party app this specific user has authorized, the access level (the scopes it can use), and the authorization date. An admin with the User Security Management privilege can revoke any of these grants directly from that page. This is the only place the console shows *when* an app was authorized — but it means checking one person at a time, with no bulk export and no way to filter for "AI tools only."

What are the real limits of doing this by hand?

The domain-wide App access control screen aggregates counts but drops the per-user detail; the per-user Connected Applications screen has the detail but no bulk view. Neither one tells you:

• Whether the access is still being used, or was granted once and forgotten.
• What the app has actually done with the data it can reach — the console shows what it *can* access, not what it *has* accessed.
• How the picture has changed over time, since there is no historical timeline of grants added or scopes widened.
• Which of the listed apps are AI tools without you recognizing every vendor name yourself.

For a Workspace with a handful of connected apps, working through both screens by hand is realistic. Past a few dozen apps and a few hundred users, keeping the list current stops being a one-time task and becomes a recurring one — the same information, re-checked, indefinitely. And both screens require an admin role with the right privilege (Services for the domain-wide view, User Security Management for the per-user one) — a Workspace with several admins still needs one person checking both regularly, not a task that naturally falls to whoever happens to notice.

What can't the manual view tell you, and how does 8200.dev answer that?

The manual path answers *what can reach the data*. It doesn't answer *who used it, when, and whether it's still needed* — the questions that actually decide whether an app should keep its access. 8200.dev's Agent Guard inventories every AI agent and OAuth-connected app across your connected sources in one continuously updated view, scores each one by risk, and explains the finding in plain language instead of a scope string. Discovery is read-only: connecting Google Workspace uses a read-only Drive metadata scope, and the deeper OAuth-app inventory shown above is available once an organization turns on OAuth app auditing, which re-authorizes with the additional read-only Admin SDK scopes Google requires for that specific view — nothing here changes access on its own; any action stays a recommendation until the organization opts in to act on it.

See the full connector list for how this extends past Google Workspace to Microsoft 365, Slack, GitHub, and the AI vendors themselves.