Google Agentspace Compliance Starts with the Current Product Record

TL;DR

• Google Cloud's current documentation calls the platform Gemini Enterprise.
• Reconcile the contract, edition, project, region, connectors, agents and the enabled capability set.
• Map Google controls to customer-owned purpose, access, change, deletion, evidence duties.
• Add inline policy only on customer-controlled HTTP AI routes that can pass through a proxy.

Product identity is at the top of the file

Google announced Gemini Enterprise on October 10, 2025 as a workplace AI platform with a chat interface, enterprise data connections, agents, a central governance framework. One day earlier, the official release notes stated that Google Agentspace was now part of Gemini Enterprise and that the new name would apply to the console, default application, resources, documentation. Google's current product overview divides documentation across the Business, Standard, Plus, Pay-as-you-go, Frontline editions.

That naming is the first compliance control. Teams that procured a product as Google Agentspace or still use that name internally should avoid assuming that every historical label maps one-for-one to a current edition. The same caution applies to an inherited architecture document. Preserve the order form name, current console service, project ID, edition, region, enabled components, documentation URL, review date in one record. The keyword "Google Agentspace compliance" may still bring a reviewer to the file. The control evidence should use the current product and resource names shown in the tenant.

A sticky note reading "Agentspace?" beside "Gemini Enterprise Standard" on the contract cover is a small concrete warning that product identity is unresolved.

Compliance starts with a bounded use case

The current overview describes an intranet search and assistant platform with agentic functions that can connect to enterprise sources such as Confluence, Jira, Microsoft SharePoint, ServiceNow. It can run permissions-aware search and generate answers. It can also host custom agents. Those functions create different processing purposes and risk profiles.

Write one purpose statement per deployed use case. Searching policy documents is one purpose. Summarizing employee files is another. An agent that updates a system of record is a third, different from drafting a report. For each use case, record the user population, source systems, data classes, retrieval scope, model function, permitted actions, human approval point, output destination, owner. Include prohibited uses and escalation rules.

This article is about the customer-owned operating record. The Google Agentspace security review follows source access and model egress. Correlation and reconstruction appear in the Google Agentspace audit logs analysis. Classification across indexing and prompts, plus actions, has its own treatment in Google Agentspace DLP. The compliance file references those controls without collapsing them into one vague approval.

Contract and processing terms define the responsibility split

Google's Cloud Data Processing Addendum describes Google as processor and the customer as controller or processor, depending on the arrangement. It defines optional customer controls including the Admin Console, encryption, logging and monitoring, IAM, scanning, firewalls. It also states that audited-service scope is identified separately for the relevant certification or report.

Procurement should therefore store the signed agreement, DPA version, service-specific terms, subprocessor review, transfer mechanism, applicable certification scope, deletion commitments. Link each contractual statement to a technical owner. If the agreement says the customer can delete data, the operating record should name the administrator who performs that action and the test proving the relevant resource disappeared. If a report covers an audited service, preserve evidence that the deployed Gemini Enterprise components fall within that scope.

I would block production approval when the procurement packet says "Google Cloud" but omits the exact service and edition, plus the enabled capability set. A cloud-wide assurance statement is an invitation for an auditor to ask which resource was actually reviewed.

Region selection is a per-capability decision

Google's Gemini Enterprise data-residency documentation for Standard and Plus separates at-rest data residency from AI or ML processing. It lists US and EU multi-regions. It also lists allowlisted in-country locations, then documents capability limitations by location. The page warns that some functions available globally have different residency or processing behavior in regional deployments. A Business, Pay-as-you-go or Frontline deployment requires edition-specific confirmation rather than an assumption that the same matrix applies.

The compliance record should name the resource location and the reason it was selected. Attach the approved data-residency requirement, then list every enabled model and capability against Google's current limitations page. Record exceptions where a capability routes work to a global endpoint or lacks regional processing. Also record exceptions that require an administrator to acknowledge a warning. Recheck the matrix before enabling a new model.

Avoid writing "EU hosted" as a complete control statement. Store at least four fields: at-rest location, ML-processing location, feature or model name, exception status. Regional availability changes. The evidence needs a retrieval date and an owner responsible for reassessment. This is configuration governance, separate from the content-classification questions covered in the DLP article.

IAM and connector ownership are separate rows

Google's IAM roles and permissions page documents predefined roles, including the Gemini Enterprise Admin role, and explains that principals may be users and groups, as well as service accounts. It also cautions that broad Google Cloud basic roles reach resources beyond Gemini Enterprise. That is a concrete access baseline for the compliance team.

Inventory project-level access, Gemini Enterprise permissions, service agents, connector credentials, agent identities, license administrators, any custom roles. Assign an owner to each credential class. Review basic Owner and Editor grants, along with Viewer grants, because their scope exceeds this product. Store the approved membership, business reason, grant date, reviewer, removal trigger.

Connector access is a separate row. A connector credential can index a large source while an employee receives a permission-aware answer later. Record the source owner, credential type, synchronization scope, entitlement mapping, failure handling, recertification date. The same treatment is required for agent identities and their actions. AI governance operating models help assign legal, privacy, security, data-owner, platform responsibilities without giving all five to one cloud administrator.

Change control is required for agents and models, including their connectors

A material-change trigger should reopen the compliance decision for a new connector or model. The same trigger is required when an agent gains an action, its user population expands, public grounding is enabled, regional routing moves, or a new sensitive-data class enters scope. The request should include the purpose, affected resources, expected data flow, permissions, test cases, rollback plan, approving owners.

Keep an agent inventory with owner, purpose, connectors, actions, model route, user population, data classes, approval date, last test. Add a status for proposed, test, production, suspended, retired. Retirement must remove credentials and connector access. It must preserve required evidence and delete data according to the approved schedule.

The quarterly review should compare the inventory with live resources. Select one connector and one custom agent. Also select one administrative role. Verify ownership and purpose, then inspect a permitted workflow and a prohibited workflow. Record the transaction identifiers and remediation tickets. The review is evidence that controls operate. A design document prepared at launch is evidence of intent.

Evidence is tied to one transaction and one control owner

A compliance reviewer should be able to select a synthetic request and identify the user or agent, source references, project, region, model function, requested action, policy outcome, timestamp, evidence owner. Four records may each contribute a piece: provider logs, source-system records, application events, independent request-policy records. Keep their roles distinct.

The operating file should also answer control-level questions. Connector approval is assigned to a named owner, and a second owner reviews regional exceptions. An accountable team and a response target are required for deletion and IAM recertification. Suspension after a failed agent test needs the same. Attach the evidence location for every assignment. A spreadsheet with twenty controls and no named people is an inventory of hopes.

Use a stable correlation identifier across systems where architecture permits it. Store references to sensitive content instead of copying full prompts into every evidence system. The reviewer needs enough context to reconstruct the authorization and data path while preserving the audit store as a controlled record rather than a second corpus of enterprise data.

DeepInspect

DeepInspect intercepts HTTP AI traffic between authenticated users/agents and LLMs. It enforces identity-based policies on that traffic and produces audit trails.

For a Gemini Enterprise-related architecture, that boundary is limited to customer-controlled model routes configured to pass through the stateless proxy. DeepInspect can evaluate application-supplied identity, route, prompt classification, policy before the request reaches the LLM, then produce a per-decision audit record. Google-managed UI traffic, source permissions, connector indexing, IAM, data residency, provider-internal operations are separate control domains.

Book a technical deep dive at deepinspect.ai.