--- title: "Anomity Integrates with Google Workspace | Anomity Blog" description: "Anomity now reads the OAuth grants employees gave AI apps in Google Workspace, and classifies and risk-scores each one in a single AI Applications inventory." url: "https://anomity.ai/blog/anomity-google-workspace-integration/" source: html --- Anomity Integrates with Google Workspace Contents - Why Google Workspace, and why now - Cloud discovery: the third collector - What the connector reads - How each app is scored - What this release is, and is not - How it authenticates - How Anomity and Google Workspace fit together - Frequently asked questions 0% 6 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Integrates with Google Workspace ![Anomity robot illustrating Anomity Integrates with Google Workspace] Company # Anomity Integrates with Google Workspace Anomity Research Anomity Research · Jul 6, 2026 · 6 min read Share: Copied TL;DR - Anomity now connects to Google Workspace . The connector reads every third-party OAuth grant employees have given across the domain, groups them by app, and lands them in a new AI Applications inventory with vendor, scopes, who granted them and a risk score. - It is the launch of cloud discovery , Anomity's third collector. The Endpoint and Browser Sensors see what runs on a device; cloud discovery pulls the access employees granted in the cloud, the kind of AI risk that never touches a laptop, such as an AI assistant authorized to read Gmail. - Each app is classified (AI or not, which vendor) and scored from the scopes it holds: full mailbox access, Gmail send, Drive and directory access weigh heaviest, and an unrecognized vendor or scope is treated as a signal, not as harmless. - Setup uses a service account with domain-wide delegation on two Directory API scopes, authorized in your own Admin console. Anomity lists users and their tokens; it never reads mail, files or calendar content. - This release is visibility: inventory, classification and a risk score, refreshed every six hours and on demand. A grant that is revoked in Workspace drops out of the inventory on the next sync. - Workspace knows which apps hold tokens. Anomity tells you which of them are AI, how much they can reach, and how that compares with what the fleet is running. Anomity now integrates with **Google Workspace**. Connect a Workspace domain and Anomity reads every third-party OAuth grant your employees have given, works out which of those apps are AI, scores each one by what it can reach, and lists them in a new **AI Applications** inventory in the Anomity console. The connector is available today from Settings, under Integrations, and it ships alongside a [GitHub connector](https://anomity.ai/blog/anomity-github-integration/) built on the same framework. This is also the launch of **cloud discovery**, the third collector in Anomity next to the Endpoint Sensor and the Browser Sensor. This post explains why it exists, what the Workspace connector reads, how it scores what it finds, and how it authenticates. ## Why Google Workspace, and why now Anomity's sensors are good at what runs on a device: the coding agent a developer installed, the MCP servers wired into it, the AI web service someone signed in to from the browser. A growing share of AI access never runs on a device at all. An employee clicks through a consent screen, an AI assistant is authorized to read their Gmail, and from that moment the vendor's servers read the mailbox from the vendor's cloud. Nothing new runs on the laptop, nothing crosses the corporate network, and the only record of the decision is an OAuth token in Workspace. That consent screen is where a lot of shadow AI starts. Meeting note-takers, writing assistants, AI app builders that want Drive, and agents that want the calendar all arrive the same way, one employee at a time. We covered the mechanics in [AI and OAuth: the risk report](https://anomity.ai/blog/ai-oauth-risk-report/), and identity signals are one of the detection layers in our [guide to shadow AI detection](https://anomity.ai/blog/shadow-ai-detection-techniques-best-practices/). Workspace already holds the answer to which apps have access. What it does not do is tell you which of them are AI, rank them by blast radius, and put them next to everything else your security team knows about AI on the fleet. ## Cloud discovery: the third collector The sensors **push** what they see from each device. Cloud discovery connectors **pull** from the provider: an administrator configures a connector once with a credential the customer controls, and Anomity syncs it every six hours and on demand. Every connector writes to the same AI Applications inventory, so an AI vendor holding Workspace scopes and the same vendor's GitHub App appear side by side, with one risk model across both. The framework is source-agnostic by design. Google Workspace and GitHub are the first two sources, and every cloud discovery source Anomity adds lands in the same inventory, from [Microsoft Entra](https://anomity.ai/blog/anomity-microsoft-entra-integration/) and [Atlassian](https://anomity.ai/blog/anomity-atlassian-integration/) to [Claude Enterprise](https://anomity.ai/blog/anomity-claude-enterprise-integration/) and [Okta](https://anomity.ai/blog/anomity-okta-for-ai-agents-integration/). ## What the connector reads Everything comes from the Workspace Directory API, and every call the connector makes is a list. From Google Workspace What Anomity records **The user directory** Every user in the domain, so that each person's grants can be read. Users are listed, not profiled. **Each user's OAuth tokens** The third-party apps that user has authorized: the OAuth client, the app's display name, the scopes granted, and whether it is a native (installed) app. **One row per app** Grants are grouped by OAuth client, so an app authorized by 40 people is one row with 40 grantors, the union of the scopes they granted, and a user count. **Classification** Whether the app is AI, which vendor it belongs to, its category, whether the vendor is one Anomity recognizes as reputable, and coarse capability tags such as mail, files, calendar or identity. **Risk** A score from 0 to 100, a level (low, medium, high or critical), and the human-readable reasons behind it. ## How each app is scored Every Google scope maps to a weight and a label. Full mailbox access and directory administration sit at the top, followed by Google Cloud platform access, Gmail send and modify, Drive, Docs and Sheets, contacts and Chat. Calendar and read-only variants weigh less, and basic profile and email weigh almost nothing. An app's score starts from the most sensitive scope it holds, gains a small bump for each additional sensitive scope, and gains a penalty when Anomity does not recognize the vendor. A scope Anomity has never seen is not scored as zero, because an unknown grant is itself worth a look. Vendor recognition works from a catalog of AI vendors, with a keyword fallback for the long tail of apps whose names say what they are. Recognized as reputable means exactly that: it removes the unknown-vendor penalty, and it does not mean your organization sanctioned the app. The reasons behind each score are shown on the row, so 'critical' always comes with 'Full mailbox access' or 'Workspace directory admin (write)' attached rather than a bare number. ## What this release is, and is not We kept the first release to visibility, and we would rather name its edges: - Inventory, classification and a risk score. The inventory can be filtered by source, risk level and AI apps only, and ranked by risk. - No findings or alerts yet. Evaluating discovered apps against policy and notifying when a new AI app appears are follow-ups on the same data, kept out so this release could be reviewed as visibility alone. - Current grants, not history. The connector reads the tokens that exist today. A revoked grant disappears from the inventory on the next sync. Last-used enrichment from Workspace audit reports needs one more scope, and we will ask for it only when that feature ships. - No content. Anomity never reads mail, files or calendar events. It sees that an app can, and which users let it. ## How it authenticates The connector uses a Google Cloud service account with **domain-wide delegation**, the standard onboarding for tools that inventory OAuth apps across a domain. The grant lives in your own Admin console, scoped to exactly two scopes, where you can review it or remove it at any time. - In Google Cloud, create a service account and a JSON key, and note the service account's numeric client ID. - In the Google Admin console, open Security, then Access and data control, then API controls, then Domain-wide delegation. Add the client ID with the two Directory API scopes the connector lists: user read-only and user security. - In Anomity, open Settings, then Integrations, and add a Google Workspace connector. Paste the service account JSON and the email of a Workspace administrator for the connector to act as. - Click Test , which validates the credential by listing a single user, then Sync to pull the grants. One point of honesty about scopes. The user read-only scope is read-only. The user security scope is the one Google uses for reading a user's third-party tokens, and the same scope also allows revoking them; Google does not offer a narrower option. Anomity only lists tokens in this release and never deletes one, but we will not call the grant read-only when it is not. To cut Anomity off, remove the delegation entry or delete the key. The service account key is encrypted at rest and is never returned by any Anomity API, including to the administrators who saved it. Viewing the inventory takes an analyst role, changing a connector takes an admin role, and every create, update, delete and manual sync is written to Anomity's audit trail with the person who did it. ## How Anomity and Google Workspace fit together Google Workspace is where access is granted, and where it is ultimately blocked. Anomity does not replace that, or the CASB, DLP, EDR and GRC tools around it. It adds the AI lens: which of the apps holding Workspace tokens are AI, how much each can reach, and how many people let it in. Cloud discovery sits next to the Endpoint Sensor, which inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes on every managed device and decides allow, deny or log at the agent hook before a tool call runs, and the Browser Sensor, which covers AI web services and the accounts used in them. Put together, the question changes from 'which AI tools are installed' to 'which AI has access to company data, wherever it runs'. The same inventory takes in GitHub Apps from the [GitHub connector](https://anomity.ai/blog/anomity-github-integration/), and later sources such as [Zapier AI automations](https://anomity.ai/blog/anomity-zapier-integration/) extend it further. Anomity collects metadata only and is SOC 2 Type II attested. To see the AI apps holding access to your own Workspace domain, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What does the Anomity Google Workspace integration do? It connects one Google Workspace domain to Anomity's cloud discovery. The connector lists the users in the domain, reads the third-party OAuth tokens each one has granted, and groups them by OAuth client into one row per app. Each row carries the app's name, vendor, category, the scopes it holds, which users granted it, and a risk score. The rows appear in the AI Applications inventory in the Anomity console, alongside apps discovered from GitHub and every other cloud discovery source. What is cloud discovery? It is the third of Anomity's three collectors. The Endpoint Sensor reads AI agents, MCP servers, extensions, skills, secrets and local runtimes on managed devices, and the Browser Sensor sees AI web services and the accounts used in them. Cloud discovery covers what neither can: access employees granted to AI applications in the cloud. Where the sensors push what they see, cloud discovery connectors pull from the provider on a schedule. Can Anomity read our email or documents through this connector? No. The two scopes the connector asks for cover the Workspace user directory and users' third-party tokens. They do not grant access to Gmail, Drive, Calendar or any other content, so Anomity sees which apps hold access and with which scopes, not what those apps read. Is the connector read-only? Anomity only lists users and tokens. We do not describe the grant itself as read-only, though, because it is not: the Directory API scope Google uses for reading a user's third-party tokens is the same scope that allows revoking them, and Google offers no narrower one. Anomity never deletes a token in this release, and the delegation lives in your own Admin console, where you can review or remove it at any time. How is the risk score calculated? Each scope an app holds maps to a weight and a human-readable label. The score starts from the app's most sensitive scope, adds a small amount when the app holds several sensitive scopes, and adds a penalty when the vendor is not one Anomity recognizes. It is then banded into low, medium, high or critical. A scope Anomity does not recognize still counts, because an unknown grant is itself a signal. The labels behind the score, such as 'Full mailbox access', are shown on the row so the reason is visible. Does the integration raise findings or alerts? Not in this release. It ships the inventory, the classification and the risk score, so a security team can see the whole population of AI apps holding Workspace access and rank it. Turning a risky grant into a policy finding, and notifying when a new AI app appears, are the next steps on the same data. How often does the inventory refresh? Every six hours, and whenever an administrator clicks Sync on the connector. Each sync replaces what it saw last time, so an app whose grants were revoked in Workspace drops out of the inventory on the next run rather than lingering. Does Anomity replace Google's own app access controls? No. Google Workspace is where access is granted and where it is blocked. Anomity complements it the way it complements CASB, DLP, EDR and GRC tools: it classifies which third-party apps are AI, ranks them by what they can reach, and puts them next to what its sensors see running on managed devices. ## Related posts [Company ### Anomity Integrates with GitHub Anomity now reads the GitHub Apps installed on your org, Copilot seats and org webhooks, and risk-scores the AI tools holding access to your code. Anomity Research · Jul 6, 2026 · 6 min](https://anomity.ai/blog/anomity-github-integration/) [Company ### Anomity Integrates with Microsoft Entra ID Anomity now reads Entra Agent ID agents, their blueprints and the apps employees consented to in Microsoft 365, and flags agents nobody is accountable for. Anomity Research · Sep 10, 2026 · 7 min](https://anomity.ai/blog/anomity-microsoft-entra-integration/) [Company ### Anomity Integrates with Google Chat Anomity now posts AI agent findings and digests to Google Chat spaces as cards, linked to your org by a one-time claim code rather than an email domain. Anomity Research · Sep 11, 2026 · 5 min](https://anomity.ai/blog/anomity-google-chat-integration/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Integrates with Google Workspace", "description": "Anomity now reads the OAuth grants employees gave AI apps in Google Workspace, and classifies and risk-scores each one in a single AI Applications inventory.", "datePublished": "2026-07-06", "dateModified": "2026-07-06", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/anomity-google-workspace-integration/", "relatedLink": [ "https://anomity.ai/blog/anomity-github-integration/", "https://anomity.ai/blog/anomity-microsoft-entra-integration/", "https://anomity.ai/blog/anomity-google-chat-integration/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-google-workspace-integration.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1260, "timeRequired": "PT6M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-google-workspace-integration/", "keywords": "Google Workspace OAuth app discovery for AI, Google Workspace, Integrations, Cloud Discovery, OAuth, Shadow AI, AI Applications, Third-Party Apps" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What does the Anomity Google Workspace integration do?", "acceptedAnswer": { "@type": "Answer", "text": "It connects one Google Workspace domain to Anomity's cloud discovery. The connector lists the users in the domain, reads the third-party OAuth tokens each one has granted, and groups them by OAuth client into one row per app. Each row carries the app's name, vendor, category, the scopes it holds, which users granted it, and a risk score. The rows appear in the AI Applications inventory in the Anomity console, alongside apps discovered from GitHub and every other cloud discovery source." } }, { "@type": "Question", "name": "What is cloud discovery?", "acceptedAnswer": { "@type": "Answer", "text": "It is the third of Anomity's three collectors. The Endpoint Sensor reads AI agents, MCP servers, extensions, skills, secrets and local runtimes on managed devices, and the Browser Sensor sees AI web services and the accounts used in them. Cloud discovery covers what neither can: access employees granted to AI applications in the cloud. Where the sensors push what they see, cloud discovery connectors pull from the provider on a schedule." } }, { "@type": "Question", "name": "Can Anomity read our email or documents through this connector?", "acceptedAnswer": { "@type": "Answer", "text": "No. The two scopes the connector asks for cover the Workspace user directory and users' third-party tokens. They do not grant access to Gmail, Drive, Calendar or any other content, so Anomity sees which apps hold access and with which scopes, not what those apps read." } }, { "@type": "Question", "name": "Is the connector read-only?", "acceptedAnswer": { "@type": "Answer", "text": "Anomity only lists users and tokens. We do not describe the grant itself as read-only, though, because it is not: the Directory API scope Google uses for reading a user's third-party tokens is the same scope that allows revoking them, and Google offers no narrower one. Anomity never deletes a token in this release, and the delegation lives in your own Admin console, where you can review or remove it at any time." } }, { "@type": "Question", "name": "How is the risk score calculated?", "acceptedAnswer": { "@type": "Answer", "text": "Each scope an app holds maps to a weight and a human-readable label. The score starts from the app's most sensitive scope, adds a small amount when the app holds several sensitive scopes, and adds a penalty when the vendor is not one Anomity recognizes. It is then banded into low, medium, high or critical. A scope Anomity does not recognize still counts, because an unknown grant is itself a signal. The labels behind the score, such as 'Full mailbox access', are shown on the row so the reason is visible." } }, { "@type": "Question", "name": "Does the integration raise findings or alerts?", "acceptedAnswer": { "@type": "Answer", "text": "Not in this release. It ships the inventory, the classification and the risk score, so a security team can see the whole population of AI apps holding Workspace access and rank it. Turning a risky grant into a policy finding, and notifying when a new AI app appears, are the next steps on the same data." } }, { "@type": "Question", "name": "How often does the inventory refresh?", "acceptedAnswer": { "@type": "Answer", "text": "Every six hours, and whenever an administrator clicks Sync on the connector. Each sync replaces what it saw last time, so an app whose grants were revoked in Workspace drops out of the inventory on the next run rather than lingering." } }, { "@type": "Question", "name": "Does Anomity replace Google's own app access controls?", "acceptedAnswer": { "@type": "Answer", "text": "No. Google Workspace is where access is granted and where it is blocked. Anomity complements it the way it complements CASB, DLP, EDR and GRC tools: it classifies which third-party apps are AI, ranks them by what they can reach, and puts them next to what its sensors see running on managed devices." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Anomity Integrates with Google Workspace", "item": "https://anomity.ai/blog/anomity-google-workspace-integration/" } ] } ```