Gemini Enterprise Security Guide: Identity and Agents

Gemini Enterprise puts one search box and a set of agents in front of everything an organisation connects to it, so any gap in source permissions, identity mapping or agent access becomes a way to find and move data at scale. Google describes it as an intranet search, AI assistant and agentic platform with prebuilt connectors for applications such as Confluence, Jira, SharePoint and ServiceNow, an Agent Gallery and custom agents; its admin role ID, roles/discoveryengine.agentspaceAdmin, still carries the earlier Agentspace name. This guide covers the platform administered in Google Cloud (Standard, Plus, Pay-as-you-go and Frontline editions), not Gemini inside Workspace apps, which the Gemini for Google Workspace Security Guide covers. It is for Google Cloud administrators, identity teams and security engineers who own the rollout. Product details are from Google Cloud documentation checked 27 October 2026; features change often, so confirm settings against the current pages.

Key takeaways

Search is only as safe as the identity mapping. Permission-aware results depend on the identity provider, the google.subject mapping and group sync being right before data stores are created, and some choices cannot be changed later without recreating data stores.
The admin role is broad. Gemini Enterprise Admin (roles/discoveryengine.agentspaceAdmin) includes all Discovery Engine Editor permissions plus agent and engine IAM policy changes and logging permissions; treat it as privileged access.
Agents have their own identities. Google's agent identity gives agents SPIFFE-based principals with 24-hour, automatically renewed certificates and no exportable keys, but IAM bindings outlive deleted agents and must be removed by hand.
Prompt and response logging is opt-in and sensitive. Usage audit logs can record prompts and grounded responses in Cloud Logging; decide who may read them before you switch them on.
Put the perimeter in first. VPC Service Controls cannot be enforced on a project with existing data stores, and actions to third-party apps are blocked by default inside a perimeter until allowed by organisation policy.

How identity and access work in Gemini Enterprise

Three identity layers decide what a user sees and what an agent can do: the user's identity and groups, IAM roles on the Gemini Enterprise resources, and the source system's own access control lists.

Choice	Google Identity (recommended by Google for new setups)	Third-party IdP via Workforce Identity Federation
Supported sources	All first-party Google sources; third-party sources by federation; third-party ingestion except Microsoft 365 sources	Setups connecting only to third-party sources; required for Microsoft 365 ingestion (with Entra ID)
IdP requirement	Third-party IdP, if used for sign-in to Google, must support OIDC or SAML 2.0	OIDC or SAML 2.0 IdP such as Entra ID, Okta or AD FS
Key settings	Unique user attribute, usually email; aliases for users with multiple addresses	Workforce pool at the `global` location; `google.subject` mapped to lowercase email; `attribute.as_user_identifier_*` for extra identifiers; SCIM for large group counts
Change cost	Switching provider means deleting and recreating ingestion data stores and resets chat history; changing a user's `google.subject`, even letter case, creates a new user who loses history, notebooks, agents, licences and IAM roles

Source ACLs: for Google Workspace connectors, access follows the source ACLs and Google Group membership. For Microsoft sources ingested into Gemini Enterprise, Entra ID groups control access, which requires Workforce Identity Federation with Entra ID. Each document supports up to 3,000 readers, with each user or group counted as one.
Access control is fixed per data store: Google states the access control setting cannot be turned on or off for an existing data store. Decide before the first ingestion.
Federation versus ingestion: federated connectors, such as the Data Cloud connectors for BigQuery, Spanner, Cloud SQL and AlloyDB, query data in place; ingestion copies content into an index that must carry the source ACLs faithfully. Ingestion is where stale or flattened permissions cause oversharing. See the Permission-Aware RAG Guide.
Context-Aware Access: IP-based access levels can block requests Gemini Enterprise makes from Google's servers; Google's documented workaround adds the Gemini Enterprise OAuth client ID as an OR condition. Review that exception, because it widens the policy.

Admin roles and privileged access

Role	Role ID	What it can do	Treat as
Gemini Enterprise Admin	`roles/discoveryengine.agentspaceAdmin`	All Discovery Engine Editor permissions plus `discoveryengine.agents.setIamPolicy`, `discoveryengine.engines.setIamPolicy`, assistant settings, logging, monitoring and trace permissions; required to turn on usage audit logging and Model Armor	Privileged: small named group, just-in-time where possible
Discovery Engine Editor	`roles/discoveryengine.editor`	Read and write on all Discovery Engine resources, including `discoveryengine.agents.create`, `.update` and `.manage`, but not agent IAM policy changes	Builder role for agent developers in non-production projects
Gemini Enterprise User	See Google's role reference	Use of the app by licensed employees	Standard user access, assigned with the licence
Basic roles (Owner, Editor, Viewer)	`roles/owner`, `roles/editor`, `roles/viewer`	Access across Google Cloud, not just Gemini Enterprise	Do not use for Gemini Enterprise administration
Workforce pool administrators	IAM workforce pool roles	Change how every user's identity maps; Google notes these roles carry powerful permissions	Tier 0 identity administration

Separate build from publish: because setIamPolicy on agents sits only in the Admin role, a developer with Editor can build an agent but cannot share it. Keep it that way, and have publication reviewed.
Custom roles: Google supports custom roles where predefined roles do not fit. Use them for read-only reviewers who need to inspect agents and data stores without editing them.
Watch for role escalation: alert on any grant of the Admin role, of Owner on the hosting project, or of workforce pool administration (ATT&CK T1098.003 Additional Cloud Roles describes the attacker version). See the Google Cloud IAM and Service Accounts Guide.

Integrations, API tokens and service accounts

Agent identities: Google's agent identity gives each supported agent a SPIFFE ID such as spiffe://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/..., used in IAM as a principal:// identifier. Gemini Enterprise is a supported service, with principals under the discoveryengine resource path. An X.509 certificate valid for 24 hours is provisioned and renewed automatically, access tokens are bound to it, and calls to Google Cloud APIs use mTLS.
How they differ from service accounts: Google states that agent identities are not shared across workloads by default, cannot be impersonated, and cannot have long-lived keys generated for them. This removes the service account key problem for agents that use them. See the Google Cloud Service Account Keys Security Guide.
Lifecycle traps: the principal is derived from the hosting resource ID, so redeploying creates a new principal that needs fresh grants, and deleting an agent leaves its IAM bindings in place (inactive) until you remove them. Add binding clean-up to decommissioning.
End-user credentials for actions: where agents act in third-party apps for a user, Google describes an auth manager that encrypts end-user credentials and a gateway that decrypts them, so the agent does not see the raw credential. CMEK can protect connector configurations and end-user credentials for Data Cloud connectors.
Service agents: cross-project Model Armor templates need the Model Armor User role granted to the app's Discovery Engine service account. Record such grants; they are easy to forget during reviews.
Write actions: when connector actions are enabled, agents can change data in the source system (for Data Cloud connectors, subject to the user's IAM permissions) or send email and create tickets. Treat each enabled action as a new delegated permission.

For how Google's agent identity compares with Microsoft and AWS, see Cloud Agent Identity Services Compared (Entra, AgentCore, Google).

Logging and detection

Log	Where	What it shows	Notes
Admin Activity audit logs	Cloud Logging, `protoPayload.serviceName="discoveryengine.googleapis.com"`	ADMIN_WRITE methods such as `DataStoreService.CreateDataStore`, `EngineService.UpdateEngine`	Configuration changes; alert on these
Data Access audit logs	Same service name	ADMIN_READ (`EngineService.GetEngine`), DATA_READ (`SearchService.Search`), DATA_WRITE (`AssistantService.StreamAssist`)	Enable deliberately; volume can be high
Usage audit logs	`_Default` bucket, log `discoveryengine.googleapis.com%2Fgemini_enterprise_user_activity` and `gen_ai.*` logs	Per-method fields for Assist, StreamAssist, Search, CreateAgent; `agent_info` including `spiffe_id`; prompts as `query.text` if enabled	Prompt and response text is elided unless "Enable logging of prompt inputs and response outputs" is on; enabling needs the Admin role, viewing needs `roles/logging.viewer`
Model Armor logs	Data Access logs for the Model Armor API	`SanitizeUserPrompt` and `SanitizeModelResponse` verdicts without content	Correlate with usage logs to see which user hit which filter
Security Token Service logs	Data Access logs (Admin Read) for the STS API	Federated sign-ins and attribute mapping	Google suggests these to verify Workforce Identity Federation

Protect the logs themselves: prompts and grounded responses are sensitive data. Use log views, IAM conditions or a separate bucket with sinks, and field-level access control where available, so that reading every employee's prompts is a privileged act.
Detections worth building: new data store or connector created outside change windows; agent IAM policy changes; one user's search volume or breadth far above baseline (ATT&CK T1213 Data from Information Repositories); repeated Model Armor blocks for one user or agent; new actions enabled on connectors that reach email or external systems (T1567 Exfiltration Over Web Service).

Metrics: percentage of data stores created with access control on; number of principals holding the Admin role; orphaned IAM bindings for deleted agents; share of agents using agent identity rather than service account keys; Model Armor block rate by template; mean time to review a newly published agent.

Hardening baseline

Decide identity first: pick Google Identity or Workforce Identity Federation, fix the google.subject mapping in lowercase email, configure group claims and SCIM where groups are large. Test with pilot users whose access you know before creating production data stores.
Build the perimeter before data: place the hosting project in a VPC Service Controls perimeter with discoveryengine.googleapis.com restricted, run it in dry run mode first, and add access levels because apps are publicly reachable by default. Rollback is changing the perimeter back to dry run, not removing it.
Restrict connectors by organisation policy: use the "Restrict allowed data sources for data connectors" and "Restrict egress domains for data connectors" constraints so new action-capable data stores need explicit approval.
Create data stores with access control on: verify a sample of documents returns only to permitted users before widening the pilot.
Enable Model Armor: separate userPromptTemplate and responseTemplate, prompt injection and jailbreak detection on prompts, Sensitive Data Protection and malicious URL detection on responses, inspect-and-block enforcement and the default FAIL_CLOSED mode. Start in inspect-only to tune false positives, then block. Note that Google states Model Armor does not screen custom ADK, A2A or Dialogflow agents and blocks rather than masks sensitive data.
Apply CMEK where your policy requires customer-managed keys, and confirm data residency in the us or eu multi-regions where supported.
Turn on audit and usage logging with restricted viewers, and decide whether prompt text logging is lawful and necessary for your organisation before enabling it.
Govern agents: developers build with Editor in a non-production project; admins publish after review; every agent has an owner; decommissioning removes IAM bindings.

Common misconfigurations

Oversharing inherited from the source: "anyone in the organisation with the link" files in Drive or broad SharePoint sites become discoverable by search. Gemini Enterprise honours the ACL; it does not fix it. Clean up sharing before connecting.
Data stores created before the identity decision: a later IdP change or a google.subject case fix forces data store rebuilds and loses user history.
Perimeter added after go-live: VPC Service Controls cannot be enforced on a project with existing data stores, so the perimeter is skipped or data stores are rebuilt in a hurry.
Admin role used for building: developers with the Admin role can both build and share agents and read logs, removing the review step.
Model Armor assumed to cover every agent: custom ADK and A2A agents are outside its screening, so they need their own input and output controls.
Prompt logs readable by anyone with Logs Viewer: turning on prompt and response logging without restricting the bucket exposes sensitive conversations. Google also advises against enabling Cloud Logging inside Model Armor templates for the same reason.
Write actions without confirmation: a connector that lets an agent create calendar events, send mail or file tickets can be driven by injected content. In the Gemini calendar prompt injection, an invite with hidden instructions made Gemini write private meeting summaries into a new event an attacker could read; the lesson applies to any action-capable connector.

Framework mapping

Area	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Identity provider, mapping and licences	IA-4 Identifier Management, AC-2 Account Management	PR.AA-01
Admin roles and agent publication	AC-6 Least Privilege, AC-3 Access Enforcement	PR.AA-05
Agent identities and credentials	IA-9 Service Identification and Authentication, IA-5 Authenticator Management	PR.AA-01
Perimeter and connector egress	SC-7 Boundary Protection, AC-4 Information Flow Enforcement	PR.AA-05
CMEK	SC-12 Cryptographic Key Establishment and Management	-
Audit and usage logging	AU-2 Event Logging, AU-12 Audit Record Generation, SI-4 System Monitoring	DE.CM-03

Practitioner checklist

Choose the identity provider and fix the google.subject mapping before creating any data store.
Clean up oversharing in connected sources before ingestion.
Restrict the Gemini Enterprise Admin role to a small named group and alert on new grants.
Separate agent building (Editor, non-production) from publishing (Admin, after review).
Use agent identities instead of service account keys, and remove IAM bindings when agents are deleted or redeployed.
Enforce VPC Service Controls and connector organisation policy constraints before go-live.
Enable Model Armor with separate prompt and response templates, and add controls for custom agents it does not screen.
Turn on audit and usage logs with restricted access to prompt and response content.
Require user confirmation for connector write actions to email, calendars and external systems.

Gemini Enterprise Security Guide: Identity, Connectors, Agents and Logging