How to Control Third-Party App Access to Gmail in Google Workspace

When an employee connects a third-party tool to their work Google account, the OAuth permission dialog appears, they click Allow, and the app receives whatever scopes it requested — which often includes reading, composing, and sending Gmail. Most people approve without reading the list. Across a 50-person team, the number of external tools holding active Gmail scopes — CRMs, scheduling tools, email assistants, productivity add-ons — can easily run to a dozen before anyone in IT notices.

Google Workspace gives admins the controls to decide which apps are trusted, which are limited to non-sensitive services, and which are blocked outright — before any user approves a request. This guide covers how to control third-party app access to Gmail in Google Workspace: where the API controls panel lives, how to read it, how to change an app's status, and how to audit what your users have already connected.

The Short Answer#

In the Google Admin console, navigate to Security > API controls > App access control. That page lists every third-party OAuth app your users have connected and lets you assign each one a status: Trusted, Limited, or Blocked.

A fourth implicit category covers apps that are not on your list at all — those are governed by the default access setting you choose at the top of the page. The default setting has the widest effect of anything on the screen because it applies to every future app your users might connect, not just the ones already listed.

Setting the default to 'Don't allow users to access any third-party apps' locks down new connections completely. Anything less restrictive requires building out explicit Trusted and Blocked lists. The steps and table below explain exactly how each status works and when to use each one.

Before You Start#

Three things need to be in place before the App access control screen is useful to you.

First, you need a Super Admin account, or a custom admin role that includes both the 'Manage API client access' and 'Security settings' privileges. Standard admin roles without those specific privileges cannot see the API controls section.

Second, API controls are a Google Workspace feature — they are not available on legacy G Suite Free accounts or on personal Gmail. Business Starter, Business Standard, Business Plus, and all Enterprise and Education editions include them.

Third, decide which Google services you consider sensitive before you touch any app status. The meaning of 'Limited' access depends entirely on how you configure the restricted services list. Go to Security > API controls > Manage Google Services and mark Gmail, Drive, Calendar, and any other services you want to protect. If that list is empty when you start assigning Limited status to apps, Limited and Trusted are functionally identical.

Steps: Reviewing and Managing App Access#

The steps below apply to any Google Workspace edition that includes API controls. Menu labels and exact navigation paths can shift across Admin console redesigns; if a label does not match, search Admin console help for 'App access control' to find the current path.

1. 1

   Open the Admin console

   Go to admin.google.com and sign in with a Super Admin account, or a custom admin role that includes the Security settings and Manage API client access privileges.

2. 2

   Navigate to Security > API controls

   In the left-hand navigation, click Security. If it is not visible, expand the full menu. Then click API controls. This section contains both App access control and the domain-wide delegation settings.

3. 3

   Set your restricted services list

   Before reviewing individual apps, click Manage Google Services. Mark Gmail, Google Drive, and any other services your organisation treats as sensitive. Apps marked Limited will be blocked from reaching only the services on this list — not all Google services.

4. 4

   Open App access control and review connected apps

   Click Manage Third-Party App Access. The table shows every OAuth app at least one user has connected, how many users have connected it, and its current trust status. Sort by the Users column to surface the most widely connected tools first.

5. 5

   Change an app's trust status

   Click the app name to open its detail panel. Use the Change access control to set the status to Trusted, Limited, or Blocked. Trusted grants everything the app requested. Limited blocks access to your restricted services. Blocked revokes all existing access and prevents future connections.

6. 6

   Add an app proactively by client ID

   To allowlist an app before any user has connected it, click Add app and enter the app's OAuth client ID. You can find a tool's client ID in its developer documentation or by inspecting the OAuth consent URL. This is the correct path for approving a tool before a company-wide rollout.

7. 7

   Set the default access policy

   At the top of the App access control page, find the Default access for third-party apps setting. The options range from allowing all apps to blocking all apps not explicitly listed. For most teams, the right position is to trust only apps you have explicitly reviewed and set the default to restricted — then approve tools as the need arises rather than after the fact.

What Trusted, Limited, and Blocked Actually Mean#

The three status values in App access control sound clear, but the details matter for both security and day-to-day workflow. The table below shows what each status does and the situations where each one makes sense.

One detail the table does not capture: when you block an app, Google revokes existing OAuth tokens for all users in your domain immediately. Users who had that app connected will see authentication errors the next time it tries to access their account. That is the intended behaviour — blocking an app is meant to end access — but it can generate support tickets if users are not warned in advance.

The Not reviewed row is also easy to underestimate. If your default access is set to 'Allow users to access any third-party app,' every new tool a user connects receives full access until you notice it and change the status. The default setting does more practical work than the individual status assignments, because it determines what happens before anyone reviews anything.

What to Do When the Controls Do Not Take Effect#

The most common reason API access controls appear to have no effect is that the restricted services list was not configured before app statuses were set. If Gmail is not marked as a restricted service, a Limited app can still request and receive Gmail scopes — the control exists but enforces nothing. Go back to Security > API controls > Manage Google Services and add Gmail and Drive before expecting Limited to protect them.

The second most common issue is domain-wide delegation. An app granted domain-wide delegation authority through a service account bypasses App access control entirely. Domain-wide delegation is managed separately under Security > API controls > Manage domain-wide delegation. If a tool holds a service account entry there, review and revoke it independently of the trust status you set in App access control.

• App still connecting after being Blocked: check whether the app uses a service account with domain-wide delegation — service accounts are not governed by App access control and must be revoked separately.
• Limited status has no visible effect: confirm that Gmail, Drive, or Calendar are listed under Manage Google Services as restricted. Without entries on that list, Limited is an empty label.
• App not visible in the connected-apps table: an app appears only after at least one user has completed the OAuth flow. To pre-approve an app before any user connects it, add it by client ID using the Add app button.
• Users can still install apps despite a restricted default: check whether any Organisational Units have their own API access overrides that are less restrictive than the top-level domain setting — OU-level settings take precedence for users in that OU.
• Trusted app is still being blocked: some configurations layer Content compliance rules or DLP policies on top of API access controls. Check Security > Content compliance if an explicitly Trusted app is failing.

If You Are Rolling Out an AI Email Tool#

Disclosure: we build AI Emaily, so read this section knowing we have a direct interest in how you configure this setting.

AI email tools — including AI Emaily — connect to Gmail via standard Google OAuth, requesting the scopes they need to read, categorise, and help draft replies. That means any AI email tool your team adopts will appear in the App access control table once a user completes the sign-in flow. On a domain where the default access is restricted, users may be blocked from connecting it until an admin reviews and approves the app.

The right approach is to request the tool's OAuth client ID from the vendor, review the scopes it requests and the vendor's data handling commitments, then add the client ID to App access control proactively using the Add app path before the rollout announcement. That way the first user to connect does not hit a block screen, and the IT team has a record of the review rather than a queue of access requests.

For AI Emaily specifically: the client ID is available on request, the scopes are limited to what is needed to read and compose mail, and there is no training on your mail with the model providers we route through. You can review the full data handling commitments at aiemaily.com before setting the trust level, and see what each plan includes at the AI Emaily pricing page before starting a 7-day free trial.