Blog · Industry

AI Governance for Google Workspace: What the Admin Console Cannot Show You

Eleye Abdi·16 July 2026·8 min read

Google Workspace is the AI environment that most enterprises have thought least carefully about. Microsoft 365 Copilot generates headlines and board conversations. Google's AI deployment is quieter and, in many regulated firms, significantly larger in practice.

Gemini in Gmail, Docs, Sheets, and Meet. Apps Script automations calling Gemini APIs. Third-party applications connected to Google Workspace through OAuth grants. Duet AI features embedded in Workspace tools that users are using without thinking of them as AI. The Google Workspace AI estate at most regulated firms is larger, more diverse, and less understood than the Microsoft AI estate, and it is substantially invisible to the Google Workspace admin console in the way that matters for regulatory evidence.

Google Workspace Admin SDK shows you what applications have OAuth grants to your Google Workspace tenant. It does not tell you which of those are AI agents, what risk they carry, or what cross-platform patterns they create. That translation, from OAuth grant to AI governance evidence, is what regulated firms need and what the admin console cannot provide.

The Google Workspace AI Landscape in Regulated Firms

The AI capabilities operating within a typical regulated financial services firm's Google Workspace environment fall into four categories:

Google's own AI features

Gemini in Gmail can draft emails, summarise threads, and generate responses. Gemini in Docs can write, summarise, and analyse documents. Google Meet provides AI meeting notes and transcription. These features are enabled at the Workspace admin level and operate with the permissions of the user invoking them, meaning their data access scope is determined by what each user has access to in Google Drive, Gmail, and Calendar.

For regulated firms, these features may be processing personal data, client communications, confidential documents, and sensitive business information at significant scale. Their governance status (whether they are within the firm's AI governance programme, whether their risk level has been assessed, whether they are included in Article 26 monitoring) is typically not established.

Third-party applications with Google Workspace OAuth grants

Any application that a user has connected to their Google account through OAuth creates a grant in the Google Workspace OAuth registry. Many of these applications are AI tools: AI writing assistants, AI summarisation tools, AI research tools, AI automation platforms. These grants are visible at workspace admin level but are not enumerated as AI agents by default. They appear as application connections, not as AI governance subjects.

Apps Script automations

Google Apps Script is a low-code development platform that allows users to build automations within Google Workspace. These automations can call external APIs (including AI APIs such as Gemini, OpenAI, and Anthropic) and can access Google Drive, Gmail, Calendar, Sheets, and other Workspace data. Apps Script automations built by employees (sometimes by individuals who do not consider themselves developers) are typically invisible to IT and governance functions.

Workspace-connected AI agent platforms

Platforms such as Make.com, Zapier, n8n, and similar integration tools can connect AI capabilities to Google Workspace data. These integrations operate through OAuth grants and may process significant volumes of organisational data through AI APIs. They are particularly common in business operations teams building AI-assisted workflows for marketing, sales operations, and customer service.

What the Google Workspace Admin Console Shows

The Google Workspace Admin Console provides several relevant administrative views:

  • Connected apps. Applications with OAuth grants to the Workspace tenant, showing the scope of permissions granted
  • Apps Script projects. Scripts deployed within the Workspace, showing which accounts have deployed automations
  • Security dashboard. Access activity, security events, and data export reports
  • Audit and investigation. Detailed logs of Workspace activity, exportable for compliance purposes

These views provide the raw material for AI governance: the OAuth grants are there, the Apps Script projects are there, the activity data is there. What the admin console does not do is translate this raw material into AI governance evidence. It does not identify which OAuth grants are AI agents, classify them by risk, detect cross-platform patterns, or generate signed evidence packs.

Building Article 26-Grade Evidence for Google Workspace AI

The governance evidence standard for Google Workspace AI deployments requires the same components as any other platform, and the additional challenge of identifying AI agents within a broad OAuth grant population that includes many non-AI applications.

AI agent identification

The first step is identifying which OAuth grants are AI agents, as distinct from conventional SaaS applications, reporting tools, or productivity integrations. This requires querying the Google Workspace Admin SDK and applying classification logic to identify grants associated with AI capabilities: known AI application identifiers, permission scope patterns consistent with AI data processing, and Apps Script projects that call AI APIs.

Risk classification

Each identified AI agent in the Google Workspace environment needs to be classified using the same five-dimensional framework as agents on other platforms: data access scope, external communication capability, human oversight status, regulatory touchpoints, and cross-platform pattern exposure. The Google Workspace context adds specific risk dimensions: access to Gmail data (client communications), access to Drive (confidential documents), and access to Calendar (meeting information).

Cross-platform pattern detection

Google Workspace AI agents need to be assessed in combination with agents on other platforms. A Google Apps Script automation that reads client data from Google Drive and calls an external AI API is one pattern. The same automation operating alongside a Microsoft Power Automate flow that sends external email creates a compound pattern (an agent reading data from Google and communicating externally via Microsoft) that neither platform's admin console detects as a combined event.

Signed evidence generation

Google Workspace AI agents should be included in the firm's regular signed evidence generation cycle, not managed separately in a Google-only evidence system. The regulatory evidence standard requires a unified view of the AI agent estate across all platforms, with cross-platform patterns identified and all findings covered by a single signed evidence pack.

How AETHER Pulse Provides Google Workspace AI Governance Evidence

AETHER Pulse connects to Google Workspace through the Google Workspace Admin SDK, enumerating OAuth grants, Apps Script projects, and other AI capabilities as part of its cross-platform discovery. It applies its five-dimensional classification framework to identify and risk-rate Google Workspace AI agents. Google Workspace findings are included in cross-platform toxic-combination detection alongside Microsoft 365, Salesforce, OpenAI, and other platform findings.

Google Workspace AI agents are included in AETHER Pulse's monthly signed evidence generation, appearing in the same evidence pack as agents on other platforms, with cross-platform patterns identified across the full estate. The result is Article 26-grade evidence of Google Workspace AI governance that the Google Workspace Admin Console cannot produce: a signed, reproducible, cross-platform governance artefact covering the full AI agent estate.

Further reading: What Is Shadow AI, and Why It's Now a Regulatory Problem, How to Build an AI Agent Inventory, and AI Governance Evidence for Microsoft Copilot.

Frequently Asked Questions

Does Gemini in Google Workspace require specific Article 26 assessment?

The Article 26 classification depends on how Gemini features are being used. Gemini used for general productivity tasks (drafting emails, summarising documents) is unlikely to meet the Annex III high-risk threshold for most regulated firms. Gemini used to assist in credit assessment, client communications, risk analysis, or other Annex III contexts warrants specific assessment. The deployer is responsible for making and evidencing this classification.

How do we handle Apps Script automations that were built by employees without IT involvement?

These are the most common source of shadow AI in Google Workspace environments. Discovery through the Admin SDK will identify deployed Apps Script projects. Each project that calls AI APIs should be classified, assessed for risk, and either brought into the governance programme through retrospective review or revoked. The discovery process identifies them. The governance process addresses them.

Does Google have its own AI governance tooling for Workspace?

Google provides administrative controls for Gemini through the Workspace Admin Console, including the ability to restrict Gemini features by organisational unit and to review AI activity in audit logs. These controls govern Gemini's behaviour within Google Workspace. They do not provide cross-platform governance evidence, cryptographically signed evidence packs, or regulatory readiness scoring against Article 26 and FCA obligations.

See AETHER Pulse Google Workspace Coverage →

Working on Article 26 readiness, deployer-side governance evidence, or AI agent risk at a regulated firm? We'd value 15 minutes of your perspective.

Start a conversation