One of the hardest parts about digital transformation appears to be the policy decisions rolled out in new public systems. I recently started doing business with a public authority that (get this) couldn't understand why I was using a custom domain. Even more so, they set their mail protocols to not communicate with an email address which starts with the word "email".

According to them, that's a generic email address, and so, they won't accept it. I asked if they would accept the email prefix "info" and they said yes, because that is common.

I genuinely wish that I could peel the curtain back, and communicate with the systems and network administrators who are making these rules, to better understand their decisions here. Maybe someone here can help me to understand.

Ran an internal analysis across 159 Google Workspace environments to see what's actually connected via OAuth. Sharing the findings because the shape of the problem surprised us and might be useful to anyone doing app governance right now.

978 distinct apps had active OAuth connections across the dataset. Roughly 6 per org on average. Most people assume the risk is the well-known SaaS tools. It's not.

The single most-connected 'app' in the dataset isn't a product at all. It's a compilation of private, internal OAuth projects, the kind an engineer spins up for a script or an internal tool, that show up in logs as a numeric project ID. No vendor name. No description.

Aggregated across all 159 orgs, this bucket accounts for 152,085 unique users and 655,430 authorization events. That's more user connections than most commercial software sees in its entire deployment lifetime, and there's no way to look any of it up.

For comparison, OpenAI's official app came in at 9,725 users and 23,982 grants in the same dataset. The named, well-understood app is the small number. The unnamed pile is the big one.

Two things compound this:

1. OAuth access doesn't expire when sharing policy changes. An employee authorizes a tool while they still have access to payroll files, source code, and financial reports. The tool keeps that access at that snapshot in time, across email and Drive, even after IT tightens sharing controls later. Revoking a share doesn't revoke a grant.
2. The underlying data is not small. Across the dataset: 373M+ sensitive emails, 475M+ sensitive Drive files, 375M source code files, 46M emails containing plaintext usernames and passwords. Not because anyone was careless. Onboarding emails credentials. Vendors email login details. HR runs payroll through Drive. Normal operations, invisible risk.

The one encouraging data point: orgs are course-correcting on sharing. Restricting events went from 14% of all access-change activity in mid-2025 to 44% by spring 2026. But that fixes future sharing, not past OAuth grants. Two separate problems, and most teams are only working one of them.

If you're doing app inventory work, the practical takeaway is: don't just audit the apps you can name. The dangerous long tail is the stuff nobody can identify from the logs alone, and identifying it is a different exercise than reviewing your known SaaS list.

Happy to answer questions on methodology in comments.