- Home
- AI agents
- Knowledge and retrieval
- Permission-aware retrieval
Build · Knowledge and retrieval
What is permission-aware retrieval for AI agents?
Permission-aware retrieval, also called security trimming, means an agent searching company content returns only passages the person it is working for may open. The index stores each document’s access list, the query carries that person’s identity, and the search service removes everything else before the model sees it.
In this guide: 83 pages
Key takeaways
- Trim before the model sees anything. A passage that reaches the context window has already been disclosed, whatever the answer says.
- The filter is only as good as the identity you pass. AWS writes that its ACL filtering does not constitute true authorization: your application must authenticate the user and pass a verified identity.
- Synced permissions go stale between syncs. Use a live check at the source where one exists, and fix oversharing in the source before an agent makes it easy to find.
- An agent that searches under its own identity returns what the agent can see. For user-facing answers, send the user’s identity with every query.
Where in the pipeline are permissions checked?
At three points. When content is indexed, the access list is copied alongside each chunk; when the agent queries, the service filters chunks against the user’s identity; and in some products the source system re-checks access live before results return. Sensitivity labels add a check on what the answer itself may contain.
Ingestion decides what can be enforced later. If the connector does not copy a document’s access list or label onto every chunk, query-time trimming has nothing to compare against; Azure AI Search warns that labels must be projected onto every chunk or chunk-level results are not filtered. Bedrock managed knowledge bases ingest allow and deny lists per document. Google Agent Search needs access control switched on when a data store is created and cannot add it later, and Cloud Storage and BigQuery records carry their readers in an acl_info field.
Query time is where most products trim, and the identity on the request is the weak point. Bedrock filters on the email address your application passes in userContext, so a mismatch between the address in your directory and the one in the source system fails silently and the user simply gets no results.
A live check closes the gap between syncs. For SharePoint, OneDrive, Google Drive, Confluence, Box, Zendesk and Salesforce, Bedrock managed knowledge bases re-check access with the source at query time, and the check fails closed. Without one, a removed permission lingers until the next sync: in Azure AI Search, SharePoint changes inherited from a parent scope need an explicit refresh, and the 2026-05-01-preview API added incremental pickup only for items with unique permissions.
Labels act after retrieval too. In Microsoft 365, content encrypted with a sensitivity label reaches Copilot or an agent only if the user holds both the EXTRACT and VIEW usage rights, new content inherits the highest-priority label among its sources, with documented exceptions such as container labels and encryption with user-defined permissions, and content under Double Key Encryption is never available to Copilot.
How does each platform implement permission trimming?
Each platform passes identity differently: Microsoft services take the user’s Entra token, Bedrock takes a verified email from your application, and Google Agent Search takes a Google or federated workforce identity. The table compares them as documented on 2 Nov 2026.
Permission trimming by platform. Statuses as the vendor pages showed on 2 Nov 2026.
| Platform | How identity reaches the search | What is trimmed | Status and limits |
|---|---|---|---|
| Azure AI Search, string filters | Your code adds user and group IDs to a filter on each query | Documents whose stored IDs do not match | Works with any API version; your code owns correctness |
| Azure AI Search, native enforcement | The user’s Entra token in the x-ms-query-source-authorization header | ADLS Gen2 ACLs, blob RBAC scopes, SharePoint ACLs and Purview sensitivity labels | Preview; label enforcement is single-tenant and needs RBAC; Autocomplete and Suggest do not work on label-enabled indexes |
| Foundry IQ knowledge bases | Queries run under the caller’s Entra identity | Synced ACLs and Purview labels | Knowledge bases GA 2 Jun 2026; some knowledge sources still preview |
| Microsoft 365 Copilot Retrieval API | The signed-in user’s delegated permissions | SharePoint, OneDrive and Copilot connector content the user cannot view | Included with a Copilot licence; 25 results, 200 requests per user per hour, one data source per call |
| Amazon Bedrock managed knowledge bases | A verified email in userContext, passed by your application | Allow and deny lists from ingestion, plus a live check on seven connectors | The live check fails closed; AWS says the filtering does not constitute true authorization |
| Google Agent Search | Google Identity, or Workforce Identity Federation with Entra ID, Okta or Ping | Documents whose readers exclude the user; up to 3,000 readers per document | Data source access control is preview; one identity provider per location |
OpenAI’s file search documents no document-level access control, so filtering on attributes is up to your application, which puts you in the string-filter pattern with its risk: a bug in the filter returns everything.
Whose identity should an agent search with?
The identity of the person the agent is working for, whenever the results go back to that person. An agent that searches under its own service identity sees everything the agent can reach, and every user then gets the agent’s view.
Delegated retrieval keeps the user’s boundary. Microsoft 365 Copilot surfaces only content the user can at least view, and the Retrieval API returns chunks trimmed to the user’s delegated rights. Foundry IQ and Azure AI Search native enforcement do the same with the user’s Entra token. Purview gives a second reason to pass user context: its data security policies for Foundry apply only to calls that carry an Entra user-context token or explicit user context, and app-only calls get audit without enforcement.
Unattended agents need a narrow corpus of their own. An agent that runs on a schedule with nobody behind it should search content scoped to its job, under its own identity with least privilege. A tenant-wide index searched under a service identity recreates the oversharing problem in a new place.
Agents that prepare content for someone else need one more rule. If an agent summarises documents for a manager’s dashboard, the trimming identity is the reader’s, and a cache shared across readers breaks it. The guide’s identity topic and its page on on-behalf-of versus autonomous access cover the token flows.
What breaks permission-aware retrieval in practice?
The common failures sit around the search service: permissions that were too broad before any agent existed, access lists that lag behind changes, the wrong identity on the query, and results reused across people.
- Oversharing at the source. Retrieval faithfully returns what the user can already open, so a site shared with the whole company is visible to every agent user. Fix it first: a Copilot licence unlocks SharePoint Advanced Management reports, Restricted Content Discovery and site access reviews across the tenant.
- Stale permissions. Synced access lists change only at the next sync, and AWS notes that membership changes in very large groups can take longer to arrive. Prefer live checks where they exist and put sync frequency in the design review.
- Identity mismatches. Email is the identifier Bedrock filters on, so a renamed or reassigned address returns nothing or, worse, another person’s documents. Keep identities consistent across systems and handle reassigned addresses before they reach the index.
- Caches and shared summaries. An answer cached for one user and served to the next leaks whatever the first user could see. Cache per user, or only for content with the same access list.
- Preview features in production. Azure’s native ACL and label enforcement are preview, and Bedrock agentic retrieval works only on managed knowledge bases and supports only the BLOCK guardrail action. Record which feature each agent relies on and recheck it at every release.
How do Microsoft, AWS and Google implement it?
Permission-aware retrieval on each cloud, with statuses as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Native trimming | Azure AI Search native enforcement (preview); Foundry IQ under the caller’s Entra identity | Bedrock managed knowledge bases with ACL filtering and live checks on seven connectors | Agent Search data source access control (preview) |
| Identity on the query | The user’s Entra token | A verified email in userContext | Google Identity or Workforce Identity Federation |
| Retrieve in place | Microsoft 365 Copilot Retrieval API over SharePoint, OneDrive and connectors | Amazon Quick, the successor to Amazon Q Business, with document-level ACLs for S3, Confluence Cloud, SharePoint and Google Drive | Gemini Enterprise connectors in federation mode query the source live |
| Sensitive content in answers | Purview labels at query time (preview) and label metadata in retrieve responses (2026-05-01-preview) | Bedrock Guardrails sensitive information filters on prompts and responses | Model Armor with Sensitive Data Protection templates on prompts and responses |
Amazon Q Business is closed to new customers, and AWS directs them to Amazon Quick. OpenAI file search has no document-level access control; filter on attributes in your own code.
Frequently asked questions
Is permission-aware retrieval the same as authorization?
Not on its own. AWS says plainly that its Bedrock filtering, which trusts the identity your application supplies, does not constitute true authorization. Native enforcement that checks the user’s own token, as in Azure AI Search, comes closer, but authentication in your application and the permissions in the source system still decide what is allowed.
Does Microsoft 365 Copilot respect SharePoint permissions?
Yes. It surfaces only content the user can at least view, and its semantic index honours that boundary. The catch is the permissions themselves: content shared too widely is returned faithfully, so review sharing before rollout.
What happens when someone loses access to a document?
It depends on the pattern. With a live source check, as Bedrock offers on seven connectors, the next query excludes the document. With synced access lists, it stays retrievable until the next sync picks up the change, which is why sync frequency belongs in the design.
Can we build permission-aware retrieval on a plain vector database?
Yes, with string filters: store user and group IDs on every chunk and filter on each query. You then own the sync of group membership, the filter code and its tests, so test it with users who should see nothing as well as users who should see everything.
More in Knowledge and retrieval
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Document-level access control in Azure AI Search
- Migrate agentic retrieval code (version history)
- What is Foundry IQ?
- What’s new in Microsoft Foundry, Build 2026
- Microsoft 365 Copilot Retrieval API overview
- Data, privacy and security for Microsoft 365 Copilot
- Microsoft Purview considerations for Microsoft 365 Copilot
- Microsoft Purview for Microsoft Foundry
- SharePoint Advanced Management features in Copilot licences
- ACL-aware retrieval in managed knowledge bases
- Managed and customer-managed knowledge bases
- Agentic retrieval in Amazon Bedrock Knowledge Bases
- Amazon Q Business availability change
- Bedrock Guardrails sensitive information filters
- Use data source access control
- Introduction to connectors and data stores
- Model Armor overview
- File search
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner