Google CloudProfessional Agentic Architect2026-091.2 Connecting enterprise data to Gemini Enterprise
Preserve source access controls in retrieval
Completed by the knowledge check
Learning objective
Preserve enterprise access controls when retrieving proprietary data. This lesson focuses on authorization-filtered retrieval, not source ingestion or identity-provider setup.
Core idea
Apply access control before content reaches the model:
authenticated user -> permitted document set -> retrieval -> model contextThe search result must be both relevant and authorized. Filtering an answer after generation is too late because unauthorized text has already entered the model context and may influence or leak through the response.
How it works
Preserving access starts at ingestion. Carry each document’s reader or group permissions into the searchable representation, along with a stable source identity. Keep the source system as the authority and synchronize permission changes and deletions as well as content changes.
Configure the search data store for access control when you create it. Google Cloud’s data source access control documentation states that the access-controlled setting cannot be turned on or off for an existing data store. It supports Google Identity and configured third-party identity providers, with source-specific setup.
At request time:
- Authenticate the end user through the configured identity provider.
- Bind the verified identity to the search request using the platform’s supported mechanism. Do not accept a model-generated user or group ID.
- Resolve the user’s effective source permissions, including relevant groups.
- Restrict candidate documents before ranking and return only permitted results.
- Send only those results and safe metadata to the model.
- Preserve source attribution so the response can be audited.
The agent workload also needs permission to call the search service. That workload authorization is separate from the end user’s right to see a document. A broadly privileged service account must not cause every user to inherit its data visibility.
Design for permission freshness. A document can become unauthorized without its content changing. Connector lag, group-membership caching, and stale index ACLs therefore need explicit objectives and monitoring. For high-risk sources, fail closed when identity or permission evaluation is unavailable.
Test with an authorization matrix, not only positive search queries. Include two users who issue the same query but have different document rights, a user whose group membership was removed, a deleted document, and blended search across stores. Inspect citations and snippets as well as final answer text.
Key distinctions and trade-offs
Relevance filter versus access filter: A metadata filter such as region or document type improves applicability. An access filter enforces who may receive the content. A convenient metadata filter is not a substitute for source ACLs.
Platform IAM versus document permissions: IAM controls who can administer or invoke cloud resources. Document-level access controls determine which indexed items an end user may retrieve. Both layers are necessary.
Security trimming versus post-generation redaction: Security trimming removes unauthorized candidates before retrieval output enters the prompt. Redaction modifies data after it has been selected or generated and cannot undo model exposure.
Strict access filtering can reduce result coverage for users with limited rights. That is correct behavior, not a retrieval defect. Prefer clarification, abstention, or an access-request path over widening permissions for a better answer.
Architecture / decision scenario
A legal assistant searches contracts stored in Drive. Matter A is open to the legal department; Matter B is restricted to a deal team. The connector indexes documents with source ACLs and synchronizes group membership.
Two lawyers ask the same question about termination clauses. Agent Search trims the candidate set for each verified identity before semantic ranking. The first lawyer receives only Matter A evidence. A deal-team member can also receive Matter B evidence. The application logs document identifiers, not unrestricted contract text.
If the identity provider is unavailable, the assistant does not fall back to the agent service account’s visibility. It returns a bounded access error.
Common exam traps
- Applying permissions after generation or only hiding citations.
- Assuming the agent workload’s IAM permissions represent the end user’s document rights.
- Turning on access control after creating an ordinary data store without rebuilding it as required.
- Passing a claimed user or group in prompt text as authenticated identity.
- Synchronizing content but not ACL changes, group changes, and deletions.
- Treating fewer results for a restricted user as a reason to relax security.
What to remember
- Filter to authorized documents before ranking output enters model context.
- Preserve source ACLs and synchronize their changes throughout indexing.
- Keep workload authorization separate from end-user document access.
- Fail closed when required identity or permission checks are unavailable.
- Test negative and cross-user cases across snippets, citations, and answers.
Knowledge check
An ordinary Agent Search data store now needs document-level access control. The team plans to enable the access-controlled setting on that existing store. What should it do?
The agent service account can search all contracts, but an employee may read only one matter. Where should the employee’s boundary take effect?
A user’s group membership is revoked while the document body stays unchanged. Content-only synchronization leaves search access intact. What must synchronization also cover?
References
- Google Cloud, Set up data source access control
- Google Cloud, Configure access controls for custom data sources
- Google Cloud, Identity and Access Management overview
- Google Cloud, Filter custom search