Azure OpenAI RAG Security: Why SharePoint Permissions Must Be Enforced at Query Time

Egiziago Cioffi is an IT and enterprise architect and the CEO of SynSphere Italia, a Microsoft partner based in Milan. He built an AI email assistant by creating an indexing job, configuring an Azure OpenAI retrieval pipeline, connecting it to SharePoint, and evaluating the responses produced by the system.

According to written responses Cioffi provided to VentureBeat, the Azure OpenAI email assistant automatically resolves approximately 60% of incoming customer emails. The system achieved strong evaluation scores, and its unit tests passed. However, those tests focused on response quality rather than access control.

Cioffi later tested the assistant with a low-privileged account using the same questions previously submitted by a highly privileged account. The results were different. The assistant returned SharePoint content that the lower-privileged user could not open directly in SharePoint.

The system logs exposed a problem that accuracy scores had missed: the retrieval pipeline was returning information based on the indexer’s permissions instead of the permissions of the person asking the question.

Cioffi’s experience highlights a broader security risk for enterprise AI systems. Strong answer quality does not prove that a retrieval-augmented generation, or RAG, application is enforcing user-level authorization.

Many Production RAG Systems Retrieve Data Using the Indexer’s Permissions

In a vulnerable RAG deployment, a service account with broad access indexes enterprise content. When a user asks a question, the AI assistant searches that index. Unless the retrieval layer checks the user’s identity and permissions at query time, the assistant may return information that the user could not access in the original system.

Azure AI Search now supports native document-level access control list, or ACL, trimming. The capability uses Entra-based identity tokens and synchronized permissions metadata to restrict search results according to the requesting user’s access rights.

SharePoint ACL support has also expanded in preview releases, including site group metadata through the spg: prefix in the 2026-05-01-preview API. However, Microsoft documentation indicates that only supported Entra principals can be reliably enforced at query time. Preview capabilities may also vary depending on the API, SDK, or agent deployment path being used.

For example, Azure OpenAI on Your Data can use Azure AI Search security filters to support document-level access. However, Microsoft documentation warns that document-level security is disabled when the required allowed-group field is not mapped correctly.

This creates a potentially dangerous default. A custom RAG pipeline that bypasses Azure AI Search may index content under a broadly privileged service account without applying user-specific entitlement checks. In that architecture, authorization depends entirely on whether the developer has implemented identity-aware retrieval.

Cioffi’s deployment followed a custom Azure OpenAI retrieval path. As a result, the native ACL trimming layer was not applied during search.

Successful AI Attacks Frequently End in Silent Data Exfiltration

Straiker conducted more than 1,700 exploit attempts against production AI agents and published its findings in the First STAR Labs Threat Report.

The report found that 91% of successful attacks against productivity agents resulted in undetected data exfiltration. This statistic describes what happened after an attack succeeded. It does not establish how many deployments had specific entitlement or permission-enforcement failures.

The research does, however, demonstrate the consequences of insufficient containment. In many cases, attackers did not need malware or network lateral movement. The agent itself returned the data available through its tools, context, or connected knowledge sources.

The report does not identify how many incidents were caused by authorization failures compared with prompt injection, tool abuse, excessive permissions, or other attack categories. These threats should therefore be evaluated separately, even though they can produce similar outcomes.

The UK AI Security Institute also documented 19 unauthorized agent actions during a cyber assessment conducted from July 25 to 28. The institute published its findings in an incident report on August 4^th.

That evaluation intentionally disabled the cyber classifier and enabled internet access. The results showed that AI agents can operate outside their intended scope in permissive environments where runtime controls are weak or missing.

The UK AI Security Institute findings describe a containment problem rather than the same entitlement failure seen in Cioffi’s deployment. The common issue is the lack of reliable runtime scope checking.

Why Standard AI Evaluations Miss Retrieval Permission Failures

Cioffi’s team evaluated whether the assistant generated accurate, relevant, and useful answers. Those are important measurements, but they do not answer a critical security question: whose permissions did the retrieval system use?

When an AI assistant retrieves source material, a conventional evaluation checks whether the answer is factually correct. It may not verify whether the user was authorized to view the documents supplied to the model.

Azure AI Search’s native document-level security is designed to perform that check at query time. The service validates the caller’s Entra token, extracts the relevant user and group claims, and returns only documents whose synchronized permissions metadata allows access.

For deployments using Azure AI Search, SharePoint indexers, and supported Entra-backed principals, this functionality can provide a native authorization layer. However, the control is not automatically present in every Azure OpenAI or RAG architecture.

Cioffi’s custom retrieval pipeline bypassed the native ACL trimming mechanism. Consequently, the assistant could retrieve content from the broader index even when the requesting user lacked direct SharePoint access.

From an attacker’s perspective, this is an access control violation. Netragard founder and CEO Adriel Desautels described the issue to VentureBeat as a breakdown in the authorization boundary:

“If an NHI credential typically has broad privileges and can read highly privileged data, it will be stored in the index. If an app does not enforce identity-aware retrieval, a ‘normal’ user with lower privileges can query the app and access restricted data. This collapses the authentication boundary down to the lowest privilege level with search capabilities.”

The problem appeared when Cioffi compared responses from high- and low-privileged accounts. The lower-privileged account received SharePoint content that it could not retrieve directly from SharePoint.

Desautels also identified a wider weakness in current AI security assessments. AI agents often use a single, long-lived non-human identity with enough privileges to perform many different tasks. Evaluations may not test whether logs, prompts, outputs, transcripts, memory, or injected content can expose or misuse those privileges.

As a result, an agent can receive a passing score for accuracy while still violating the organization’s authorization model.

Query-Time SharePoint Filters Reduced the Assistant’s Reach

Cioffi did not need to replace the entire identity platform to address the issue. Instead, he moved authorization into the retrieval path and added a query-time filter that checks the requesting user’s SharePoint permissions before content is sent to the language model.

Query-time filtering is important because it prevents unauthorized content from entering the model’s context window. Documents that the user cannot open in SharePoint are excluded before the assistant generates a response.

The filter reduced the amount of content available to the assistant. Cioffi told VentureBeat that the protected assistant continues to resolve approximately 60% of incoming emails automatically. He did not provide an unfiltered resolution rate for comparison.

The trade-off is expected. Some information that the assistant previously used to answer questions is now excluded because it falls outside the requesting user’s permissions. That reduction in answer coverage is the direct cost of enforcing access boundaries.

Whether query-time authorization is worth the narrower retrieval scope depends on several factors, including:

• The sensitivity of the indexed content.
• How widely permissions vary across the user population.
• Whether the application can safely handle unanswered questions.
• Whether users require access to information from multiple repositories.
• How accurately permissions metadata is synchronized.

Cioffi’s case demonstrates that custom Azure OpenAI pipelines can produce strong answer-quality results while failing to enforce document-level permissions. Query-time filters address that gap, although they may reduce the amount of information available to the model.

Identity Governance and Retrieval Authorization Solve Different Problems

Identity security has become a major focus for enterprise security providers. CrowdStrike announced the acquisition of SGNL for $740 million. Palo Alto Networks also announced and completed its acquisition of CyberArk for $25 billion.

Identity governance platforms help organizations manage service accounts, credentials, access policies, token lifetimes, and the lifecycle of non-human identities used by AI agents. These controls are essential, but they do not automatically determine which documents an agent may retrieve on behalf of a specific user.

That distinction is critical. A service account can be legitimate, properly managed, and appropriately secured while still having broader access than the person using the AI assistant.

In this scenario, the knowledge base may be correctly indexed and every credential may be valid. The security failure occurs when a low-privileged user submits a query and the assistant searches the entire index using the service account’s broader permissions.

Cioffi’s filters operate at the retrieval authorization layer. Azure AI Search’s native ACL trimming addresses the same layer for supported deployments. Neither control replaces identity governance.

A secure production AI architecture needs both:

• Identity governance: Protects service accounts, credentials, tokens, and non-human identities.
• Query-time authorization: Ensures that retrieved documents match the permissions of the requesting user.

One Security Test Every AI Team Can Run

Ask a simple question: Whose authority does the AI search system use when retrieving content?

If the deployment uses Azure AI Search with SharePoint indexers and Entra-backed principals, verify that query-time ACL trimming is enabled. Also confirm that the organization’s SharePoint groups and identity types are supported by the selected preview or production capability.

If the deployment uses a custom retrieval pipeline, do not assume that SharePoint permissions are automatically enforced. The application may require an explicit entitlement check before each query.

Start with two test accounts:

1. Use a high-privileged account to ask the assistant a question about restricted content.
2. Submit the same question using a low-privileged account.
3. Compare the assistant’s responses with the content each account can access directly in SharePoint.

If the low-privileged account receives information that it cannot open directly in SharePoint, the retrieval permission boundary is not being enforced at query time.

Desautels described this type of identity mismatch as a starting point for red-team testing. Attackers can exploit the gap between a user’s permissions and the assistant’s credentials, including by placing instructions inside content that the agent is expected to process as data.

Testing should therefore cover both data access and agent behavior. Security teams should evaluate whether an agent can retrieve unauthorized documents, follow instructions embedded in those documents, access sensitive logs, or perform actions using the privileges of its service identity.

The basic permission test requires only two accounts and approximately 30 minutes. It can reveal a serious authorization problem that response-quality evaluations will not detect.

Cioffi built an agent on a custom Azure OpenAI pipeline that bypassed the native ACL trimming layer. His team completed its evaluations and confirmed that the assistant generated useful responses. Only after comparing high- and low-privileged accounts did he discover that the system was not enforcing the user’s SharePoint permissions.

The lesson for enterprise AI teams is straightforward: do not evaluate only whether an assistant answers correctly. Test whether it answers with the information the requesting user is authorized to access.