{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/permission-trim-ai-retrieval-customer-data/", "item": { "id": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/", "slug": "permission-trim-ai-retrieval-customer-data", "url": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data.md", "json": "https://update.dsesecurity.com/api/v1/posts/permission-trim-ai-retrieval-customer-data/" }, "title": "Permission-trim AI retrieval before it touches customer data", "summary": "An AI answer is only as authorized as the retrieval path behind it. Preserve source permissions, evaluate the current user at query time, deny uncertain matches, and test revocation before an assistant searches customer records.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/", "type": "Person" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-17T13:30:00+00:00", "modified_at": "2026-08-17T19:22:08+00:00", "reviewed_on": "2026-08-17", "reading_minutes": 4, "word_count": 694, "potentially_affected": "Retrieval-augmented AI assistants; search indexes; customer documents and records; source-system ACLs; Microsoft Entra users and groups; service identities; caches; vector stores; citations; and authorization logs.", "dse_recommendation": "Map every indexed source to its permission model, carry permission metadata through ingestion, enforce the current caller at every retrieval, deny incomplete authorization context, and test permission changes, cache behavior, and revocation end to end.", "primary_source": { "name": "Microsoft Learn: Document-Level Access Control in Azure AI Search", "url": "https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts: search relevance and authorization are different decisions

\n

Microsoft’s document-level access-control guidance for Azure AI Search describes several ways to exclude documents a caller is not permitted to receive. A generally available security-filter pattern stores user or group identifiers in a filterable field and adds the current caller’s identity to the query. Microsoft also documents native ACL or RBAC enforcement, Microsoft Purview sensitivity-label enforcement, and SharePoint permission ingestion for supported scenarios, with important portions identified as preview features.

\n

The security-filter pattern is application enforced. The source ACLs must be represented accurately in the index, the application must authenticate the caller, and every relevant query must apply the correct filter. A relevant vector or keyword match is not an authorization result. Likewise, granting an application permission to query an index does not mean every application user may receive every document in that index.

\n

Microsoft’s native permission patterns still have prerequisites and scope limits. The documented ACL and RBAC options depend on supported data sources, API versions, permission metadata, tokens, and index configuration. Preview behavior should not be presented as a universal capability or silently assumed to remain unchanged. NIST’s Generative AI Profile separately emphasizes governing data, privacy, access, monitoring, and testing across the AI lifecycle. Together, the sources support an engineering principle: the authorization boundary belongs in deterministic application and data controls, not in a prompt asking the model to respect permissions.

\n\n

DSE recommendation: make every retrieval prove the caller can see the result

\n

Design the assistant so it can search everything the current user is allowed to see, while having no path to material the user cannot see. That requires the same authorization context to survive ingestion, retrieval, caching, citation, and follow-up questions.

\n
    \n
  1. Declare the source of authority. For each ticket, contract, quote, file, mailbox, or customer record, identify the system that owns access, supported principal types, inheritance rules, sensitivity labels, external users, denial rules, and the event that changes access.
    2. \n
  2. Carry permissions with the content. Index stable object and group identifiers rather than display names. Preserve the source object ID, tenant, ACL version or change marker, classification, and last permission synchronization time. Reject content whose ownership or authorization metadata cannot be resolved.
    3. \n
  3. Evaluate the live caller. Authenticate the user for the conversation and obtain the user’s current groups or claims through an approved identity path. Apply the permission condition to every retrieval, including semantic search, vector search, related-record expansion, citations, exports, and tool calls. Do not rely on text in conversation memory to identify the user.
    4. \n
  4. Use two identities deliberately. The indexing identity may need broad read access to ingest governed sources. The runtime identity should have only the search and application rights needed to return permission-trimmed results. Record which identity performed each step so a service account is not mistaken for the requesting person.
    5. \n
  5. Control caches and conversation state. Bind cached results to tenant, user or authorization scope, source version, and expiry. Recheck access before replaying a prior citation or answering “what changed in that contract?” A document removed from search results must not remain available through an old conversation summary.
    6. \n
  6. Test negative cases. Create users with no access, partial access, recently removed access, nested-group access, and similarly named customers. Test direct questions, vague follow-ups, bulk comparisons, exports, and attempts to convince the model that permission was granted. Inspect the retrieved document IDs, not only the final prose.
    7. \n
\n

Factual boundary: Azure AI Search documents specific implementation patterns; it does not make every AI retrieval system permission aware automatically. Some native permission features are preview capabilities. Recheck the selected service, API version, data source, and identity model before deployment. A correctly trimmed index also cannot repair excessive permissions in the source system.

\n

Measure denied retrievals, missing ACL metadata, permission-sync age, cache invalidation time, cross-tenant tests, and revoked-user test results. The desired outcome is not an assistant that promises discretion. It is a retrieval path that cannot supply unauthorized evidence to the model in the first place.

\n\n

Official references

\n", "content_text": "Source facts: search relevance and authorization are different decisions\nMicrosoft’s document-level access-control guidance for Azure AI Search describes several ways to exclude documents a caller is not permitted to receive. A generally available security-filter pattern stores user or group identifiers in a filterable field and adds the current caller’s identity to the query. Microsoft also documents native ACL or RBAC enforcement, Microsoft Purview sensitivity-label enforcement, and SharePoint permission ingestion for supported scenarios, with important portions identified as preview features.\nThe security-filter pattern is application enforced. The source ACLs must be represented accurately in the index, the application must authenticate the caller, and every relevant query must apply the correct filter. A relevant vector or keyword match is not an authorization result. Likewise, granting an application permission to query an index does not mean every application user may receive every document in that index.\nMicrosoft’s native permission patterns still have prerequisites and scope limits. The documented ACL and RBAC options depend on supported data sources, API versions, permission metadata, tokens, and index configuration. Preview behavior should not be presented as a universal capability or silently assumed to remain unchanged. NIST’s Generative AI Profile separately emphasizes governing data, privacy, access, monitoring, and testing across the AI lifecycle. Together, the sources support an engineering principle: the authorization boundary belongs in deterministic application and data controls, not in a prompt asking the model to respect permissions.\n\nDSE recommendation: make every retrieval prove the caller can see the result\nDesign the assistant so it can search everything the current user is allowed to see, while having no path to material the user cannot see. That requires the same authorization context to survive ingestion, retrieval, caching, citation, and follow-up questions.\n\nDeclare the source of authority. For each ticket, contract, quote, file, mailbox, or customer record, identify the system that owns access, supported principal types, inheritance rules, sensitivity labels, external users, denial rules, and the event that changes access.\nCarry permissions with the content. Index stable object and group identifiers rather than display names. Preserve the source object ID, tenant, ACL version or change marker, classification, and last permission synchronization time. Reject content whose ownership or authorization metadata cannot be resolved.\nEvaluate the live caller. Authenticate the user for the conversation and obtain the user’s current groups or claims through an approved identity path. Apply the permission condition to every retrieval, including semantic search, vector search, related-record expansion, citations, exports, and tool calls. Do not rely on text in conversation memory to identify the user.\nUse two identities deliberately. The indexing identity may need broad read access to ingest governed sources. The runtime identity should have only the search and application rights needed to return permission-trimmed results. Record which identity performed each step so a service account is not mistaken for the requesting person.\nControl caches and conversation state. Bind cached results to tenant, user or authorization scope, source version, and expiry. Recheck access before replaying a prior citation or answering “what changed in that contract?” A document removed from search results must not remain available through an old conversation summary.\nTest negative cases. Create users with no access, partial access, recently removed access, nested-group access, and similarly named customers. Test direct questions, vague follow-ups, bulk comparisons, exports, and attempts to convince the model that permission was granted. Inspect the retrieved document IDs, not only the final prose.\n\nFactual boundary: Azure AI Search documents specific implementation patterns; it does not make every AI retrieval system permission aware automatically. Some native permission features are preview capabilities. Recheck the selected service, API version, data source, and identity model before deployment. A correctly trimmed index also cannot repair excessive permissions in the source system.\nMeasure denied retrievals, missing ACL metadata, permission-sync age, cache invalidation time, cross-tenant tests, and revoked-user test results. The desired outcome is not an assistant that promises discretion. It is a retrieval path that cannot supply unauthorized evidence to the model in the first place.\n\nOfficial references\n\nMicrosoft Learn, Document-Level Access Control in Azure AI Search.\nNIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1.\nMicrosoft Security, New tools and guidance: Announcing Zero Trust for AI, March 19, 2026.", "content_markdown": "## Source facts: search relevance and authorization are different decisions\n\nMicrosoft’s [document-level access-control guidance for Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview) describes several ways to exclude documents a caller is not permitted to receive. A generally available security-filter pattern stores user or group identifiers in a filterable field and adds the current caller’s identity to the query. Microsoft also documents native ACL or RBAC enforcement, Microsoft Purview sensitivity-label enforcement, and SharePoint permission ingestion for supported scenarios, with important portions identified as preview features.\n\nThe security-filter pattern is application enforced. The source ACLs must be represented accurately in the index, the application must authenticate the caller, and every relevant query must apply the correct filter. A relevant vector or keyword match is not an authorization result. Likewise, granting an application permission to query an index does not mean every application user may receive every document in that index.\n\nMicrosoft’s native permission patterns still have prerequisites and scope limits. The documented ACL and RBAC options depend on supported data sources, API versions, permission metadata, tokens, and index configuration. Preview behavior should not be presented as a universal capability or silently assumed to remain unchanged. NIST’s Generative AI Profile separately emphasizes governing data, privacy, access, monitoring, and testing across the AI lifecycle. Together, the sources support an engineering principle: the authorization boundary belongs in deterministic application and data controls, not in a prompt asking the model to respect permissions.\n\n## DSE recommendation: make every retrieval prove the caller can see the result\n\nDesign the assistant so it can search everything the current user is allowed to see, while having no path to material the user cannot see. That requires the same authorization context to survive ingestion, retrieval, caching, citation, and follow-up questions.\n\n- Declare the source of authority. For each ticket, contract, quote, file, mailbox, or customer record, identify the system that owns access, supported principal types, inheritance rules, sensitivity labels, external users, denial rules, and the event that changes access.\n\n- Carry permissions with the content. Index stable object and group identifiers rather than display names. Preserve the source object ID, tenant, ACL version or change marker, classification, and last permission synchronization time. Reject content whose ownership or authorization metadata cannot be resolved.\n\n- Evaluate the live caller. Authenticate the user for the conversation and obtain the user’s current groups or claims through an approved identity path. Apply the permission condition to every retrieval, including semantic search, vector search, related-record expansion, citations, exports, and tool calls. Do not rely on text in conversation memory to identify the user.\n\n- Use two identities deliberately. The indexing identity may need broad read access to ingest governed sources. The runtime identity should have only the search and application rights needed to return permission-trimmed results. Record which identity performed each step so a service account is not mistaken for the requesting person.\n\n- Control caches and conversation state. Bind cached results to tenant, user or authorization scope, source version, and expiry. Recheck access before replaying a prior citation or answering “what changed in that contract?” A document removed from search results must not remain available through an old conversation summary.\n\n- Test negative cases. Create users with no access, partial access, recently removed access, nested-group access, and similarly named customers. Test direct questions, vague follow-ups, bulk comparisons, exports, and attempts to convince the model that permission was granted. Inspect the retrieved document IDs, not only the final prose.\n\nFactual boundary: Azure AI Search documents specific implementation patterns; it does not make every AI retrieval system permission aware automatically. Some native permission features are preview capabilities. Recheck the selected service, API version, data source, and identity model before deployment. A correctly trimmed index also cannot repair excessive permissions in the source system.\n\nMeasure denied retrievals, missing ACL metadata, permission-sync age, cache invalidation time, cross-tenant tests, and revoked-user test results. The desired outcome is not an assistant that promises discretion. It is a retrieval path that cannot supply unauthorized evidence to the model in the first place.\n\n## Official references\n\n- Microsoft Learn, [Document-Level Access Control in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview).\n\n- NIST, [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), NIST AI 600-1.\n\n- Microsoft Security, [New tools and guidance: Announcing Zero Trust for AI](https://www.microsoft.com/en-us/security/blog/2026/03/19/new-tools-and-guidance-announcing-zero-trust-for-ai/), March 19, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/", "url": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-17" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Permission-trim AI retrieval before it touches customer data", "item": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/#article", "identifier": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/", "url": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/", "headline": "Permission-trim AI retrieval before it touches customer data", "description": "An AI answer is only as authorized as the retrieval path behind it. Preserve source permissions, evaluate the current user at query time, deny…", "abstract": "An AI answer is only as authorized as the retrieval path behind it. Preserve source permissions, evaluate the current user at query time, deny uncertain matches, and test revocation before an assistant searches customer records.", "articleBody": "Source facts: search relevance and authorization are different decisions\nMicrosoft’s document-level access-control guidance for Azure AI Search describes several ways to exclude documents a caller is not permitted to receive. A generally available security-filter pattern stores user or group identifiers in a filterable field and adds the current caller’s identity to the query. Microsoft also documents native ACL or RBAC enforcement, Microsoft Purview sensitivity-label enforcement, and SharePoint permission ingestion for supported scenarios, with important portions identified as preview features.\nThe security-filter pattern is application enforced. The source ACLs must be represented accurately in the index, the application must authenticate the caller, and every relevant query must apply the correct filter. A relevant vector or keyword match is not an authorization result. Likewise, granting an application permission to query an index does not mean every application user may receive every document in that index.\nMicrosoft’s native permission patterns still have prerequisites and scope limits. The documented ACL and RBAC options depend on supported data sources, API versions, permission metadata, tokens, and index configuration. Preview behavior should not be presented as a universal capability or silently assumed to remain unchanged. NIST’s Generative AI Profile separately emphasizes governing data, privacy, access, monitoring, and testing across the AI lifecycle. Together, the sources support an engineering principle: the authorization boundary belongs in deterministic application and data controls, not in a prompt asking the model to respect permissions.\n\nDSE recommendation: make every retrieval prove the caller can see the result\nDesign the assistant so it can search everything the current user is allowed to see, while having no path to material the user cannot see. That requires the same authorization context to survive ingestion, retrieval, caching, citation, and follow-up questions.\n\nDeclare the source of authority. For each ticket, contract, quote, file, mailbox, or customer record, identify the system that owns access, supported principal types, inheritance rules, sensitivity labels, external users, denial rules, and the event that changes access.\nCarry permissions with the content. Index stable object and group identifiers rather than display names. Preserve the source object ID, tenant, ACL version or change marker, classification, and last permission synchronization time. Reject content whose ownership or authorization metadata cannot be resolved.\nEvaluate the live caller. Authenticate the user for the conversation and obtain the user’s current groups or claims through an approved identity path. Apply the permission condition to every retrieval, including semantic search, vector search, related-record expansion, citations, exports, and tool calls. Do not rely on text in conversation memory to identify the user.\nUse two identities deliberately. The indexing identity may need broad read access to ingest governed sources. The runtime identity should have only the search and application rights needed to return permission-trimmed results. Record which identity performed each step so a service account is not mistaken for the requesting person.\nControl caches and conversation state. Bind cached results to tenant, user or authorization scope, source version, and expiry. Recheck access before replaying a prior citation or answering “what changed in that contract?” A document removed from search results must not remain available through an old conversation summary.\nTest negative cases. Create users with no access, partial access, recently removed access, nested-group access, and similarly named customers. Test direct questions, vague follow-ups, bulk comparisons, exports, and attempts to convince the model that permission was granted. Inspect the retrieved document IDs, not only the final prose.\n\nFactual boundary: Azure AI Search documents specific implementation patterns; it does not make every AI retrieval system permission aware automatically. Some native permission features are preview capabilities. Recheck the selected service, API version, data source, and identity model before deployment. A correctly trimmed index also cannot repair excessive permissions in the source system.\nMeasure denied retrievals, missing ACL metadata, permission-sync age, cache invalidation time, cross-tenant tests, and revoked-user test results. The desired outcome is not an assistant that promises discretion. It is a retrieval path that cannot supply unauthorized evidence to the model in the first place.\n\nOfficial references\n\nMicrosoft Learn, Document-Level Access Control in Azure AI Search.\nNIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1.\nMicrosoft Security, New tools and guidance: Announcing Zero Trust for AI, March 19, 2026.", "datePublished": "2026-08-17T13:30:00+00:00", "dateModified": "2026-08-17T19:22:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Person", "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Permission-trim AI retrieval before it touches customer data" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Guide", "Important priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 694, "timeRequired": "PT4M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Microsoft Learn: Document-Level Access Control in Azure AI Search", "url": "https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview" } } ] } }