How to Allow Corporate Google Workspace While Blocking Personal Gmail Uploads in Cato

Use Cato's Tenant Restriction policy to inject the X-GoogApps-Allowed-Domains header into traffic bound for Google, listing only your corporate domains. Personal Gmail accounts can then no longer sign in, while Workspace accounts on your domain work normally. Then add an Application Control rule to block upload activities on any Google tenant you have not approved. The header stops the login; the Application Control rule stops the data. You need both, and both require TLS Inspection and a CASB license.

Applies to

• Cato SASE Cloud, Cato Management Application (CMA), September 2026 navigation

• CASB license — required for the Tenant Restriction and Application Control policies

• TLS Inspection enabled — the header cannot be injected into traffic Cato cannot decrypt

• Google Workspace with one or more verified corporate domains

• Admin role with permission to edit Security policies

What you need before you start

• Your full list of corporate domains, including secondary and alias domains. A domain you forget here locks out the people who use it.

• TLS Inspection confirmed as working on Google traffic. Check the TLS Inspection field in Monitoring > Events — it must read 1.

• A decision on contractors and delegated mailboxes. Both are common breakage sources, covered in Notes.

How tenant restriction actually works

Google supports a proxy-injected HTTP header that tells its sign-in service which account domains are acceptable on this network. The header is X-GoogApps-Allowed-Domains, and its value is a comma-separated list of allowed domains. Google's documentation specifies the header must be applied to all traffic directed to *.google.com.

When a user tries to sign in with an account outside that list, Google serves a page naming the unauthorised account and listing the domains where the service is available. The user is not silently blocked — they are told why, which cuts your helpdesk load considerably.

Cato injects this header through its Tenant Restriction policy. Because the injection happens in the decrypted HTTP request, TLS Inspection is a hard prerequisite. Without it, Cato cannot see or modify the request, and the policy does nothing.

There is a second, independent layer: tenant awareness in the Application Control policy, which uses the Application Context predicate to allow or block specific actions per tenant and per user. That is what you use to control uploads rather than logins.

Step 1 — Confirm TLS Inspection covers Google traffic

1. Go to Monitoring > Events and filter to Google traffic.

2. Check the TLS Inspection field. It must show 1.

3. If it shows 0, find the bypass rule catching it. Also check that the operating system is not one of the defaults Cato bypasses — Android, Linux and unidentified OS.

Do not continue until this reads 1. Every step below depends on it.

Step 2 — Create the Tenant Restriction rule

1. Go to Security > App & Data Inline and select the Tenant Restriction tab.

2. Click New.

3. Enter a Name — for example Google - corporate domains only.

4. Set the Position in the rulebase.

5. Expand Source and choose the scope: Host, Network Interface, IP, or Any. Start with a pilot group rather than Any.

6. Select the Application: Google Suite.

7. Set the Header Name to X-GoogApps-Allowed-Domains.

8. Set the Header Value to your corporate domains, comma-separated:

yourcompany.com, yourcompany.co.in

9. Set the Action to Inject Headers.

10. Optionally configure Time if the rule should apply only during certain hours.

11. Click Save. The change sits in your unpublished revision until you publish it.

Note on the header name: Cato's documentation renders it as X-GooGApps-Allowed-Domains with an unusual capital G, while Google documents X-GoogApps-Allowed-Domains. HTTP header names are case-insensitive, so both work. Match Google's spelling for clarity.

Values beyond your own domains

Google accepts more than domain names in this header, and knowing the options saves a support ticket later:

If automated jobs in your environment authenticate to Google as service accounts, add gserviceaccounts.com or they will break.

Step 3 — Block uploads to unapproved tenants

The header stops personal sign-in. It does not govern what happens inside a session on an approved tenant, and it does not cover every Google surface. Add an Application Control rule for the upload behaviour.

1. Stay in Security > App & Data Inline, on the Application Control rules.

2. Create a rule named something like Block upload - non-corporate Google.

3. Source: the same pilot scope as Step 2.

4. Application: Gmail, Google Drive and the other Google applications in scope. In the App Catalog, search for Tenant to see which apps and actions support tenant-aware control.

5. Activities: select the upload and file-sharing activities. Leaving Activities empty matches every activity for that application, which is broader than you want here.

6. Use the Application Context predicate to scope the rule to tenants other than your own.

7. Action: Block.

8. Order it below an allow rule for your corporate tenant.

The pattern is one allow rule for the sanctioned tenant, one block rule for everything else, in that order.

Step 4 — Pilot, then widen

1. Leave both rules scoped to the pilot group for at least a week.

2. Watch Monitoring > Events for blocked sign-ins and blocked activities. Every one is either a policy success or a person who cannot do their job — read them individually at this stage.

3. Add any missing domains to the header value.

4. Widen Source to the full scope and publish.

Caution: Publishing this to the whole organisation without a pilot will lock out anyone whose account sits on a domain you did not list — including contractors on their own domains and staff using an alias domain. The failure is immediate and total for those users.

Verification

Test the block. From a device in scope, sign out of Google and attempt to sign in with a personal Gmail account. You should see Google's page naming the unauthorised account and listing the permitted domains. If you see a normal sign-in screen, the header is not reaching Google — check TLS Inspection on that session first.

Test the allow. Sign in with a corporate Workspace account on the same device. It should work with no prompt or difference in behaviour.

Test the upload rule. With the corporate account signed in, attempt an upload to a Google tenant outside your domain. Confirm the block and find the matching event in Monitoring > Events, checking the rule name and a TLS Inspection value of 1.

Check the event field. Any test that fails should be diagnosed by looking at the TLS Inspection field before anything else. A value of 0 explains most failures on its own.

Notes and common pitfalls

• Anonymous access is not blocked. Google states this header blocks sign-in to consumer services other than Google Search, but does not necessarily prohibit anonymous access. Content reachable without signing in stays reachable.

• Delegated mailboxes break. Users hit errors accessing delegated mailboxes from domains not included in the header. If you use delegation across domains, list every one of them.

• Service accounts break silently. Automated jobs authenticating to Google will fail unless gserviceaccounts.com is in the value.

• Secondary and alias domains are the most common outage. Audit them in the Google Admin console before you write the header value, not after.

• The header only covers *.google.com. Other Google-operated domains are outside its scope.

• Certificate-pinned desktop clients sit outside TLS Inspection, so the header never reaches them.

• Split-tunnelled Google traffic is never inspected and therefore never restricted.

• This is a network-layer control. A user on a personal device not routed through Cato is unaffected. The browser-layer equivalent — Chrome Enterprise policy pushed through your device management platform — covers managed devices regardless of network, but only in Chrome. The two are complements, not alternatives, and most organisations that get this right run both.

This is one of those controls that is quick to configure and easy to get wrong in ways that surface as a Monday morning outage. The domain audit and the contractor question take longer than the rule does. Where this sits inside a broader SaaS governance posture — sanctioned tenants, activity controls, DLP on what leaves — it is usually scoped as part of a CASB and cloud application control engagement rather than a standalone change, and teams already running Cato often phase it with their Cato deployment partner alongside their other inline policies.

FAQs

1) Will this block personal Gmail on personal devices?

Only if that device's traffic routes through Cato. Tenant restriction is a network-layer control applied to inspected traffic. A personal phone on mobile data is unaffected. If you need coverage independent of network, you need a device-layer control as well — Chrome Enterprise policy through your MDM — and even that covers only Chrome.

2) What does the user actually see when they are blocked?

Google serves a page that names the unauthorised account they tried to use, lists the domains where the service is available, and suggests contacting a network administrator. It is a clear message rather than a generic error, which is why this method generates fewer helpdesk tickets than a firewall block on Gmail.

3) Can I allow personal Gmail for some teams and not others?

Yes. The Tenant Restriction rule has a Source field, so scope the restrictive rule to the groups it applies to. You can also use the Time field to apply it only during working hours, though this tends to confuse users more than it helps.

4) Does this stop someone uploading company files to their personal Google Drive?

The header stops them signing into a personal account on your network, which removes the easy path. The Application Control rule in Step 3 blocks upload activities to unapproved tenants. For control based on what is inside the file rather than where it is going, you need a DLP content profile as a third layer — the same approach used for blocking proprietary data uploads to AI tools.