Fabric Data Agent Not Respecting Row-Level Security (RLS) - Returns All Data Instead of Filtered Results

Question

Fabric Data Agent Not Respecting Row-Level Security (RLS) - Returns All Data Instead of Filtered Results

Durjan Hussain 185

Hello team,

We're experiencing an issue where the Fabric Data Agent is not honoring Row-Level Security (RLS) configurations in our semantic model, despite Microsoft documentation stating it should respect all user permissions including RLS and CLS.

Environment:

Accessing Fabric Data Agent through Azure AI Foundry integrated into our custom portal
RLS is properly configured on the semantic model with UserClient table filtering
Power BI embedding in the same environment correctly respects RLS and shows filtered data
Users authenticate properly and have appropriate permissions

Issue Details: When users query the Fabric Data Agent, it returns ALL data from the semantic model instead of applying the RLS filters. The same users, when viewing Power BI reports embedded in our portal, only see their authorized data subset as expected.

Expected Behavior: According to the documentation at https://learn.microsoft.com/en-us/fabric/data-science/data-agent-sharing, the Fabric Data Agent should "honor all user permissions to the data, including Row-Level Security (RLS) and Column-Level Security (CLS)."

Actual Behavior:

Power BI embedding: ✅ Correctly applies RLS, shows only user's accessible data
Fabric Data Agent: ❌ Shows all data, ignores RLS configuration

Questions:

Are there specific configuration steps required to enable RLS for Fabric Data Agents that differ from Power BI RLS setup?
Is there a known issue with RLS enforcement when accessing Data Agents through Azure AI Foundry?
Are there additional authentication or context-passing requirements for Data Agents to recognize user identity for RLS filtering?
Is this a limitation of the current Fabric Data Agent implementation, or are we missing a configuration step?

What We've Tried:

Verified RLS rules are active and working in Power BI
Confirmed user authentication is working correctly
Tested with multiple users - all see complete dataset instead of filtered results
Reviewed semantic model permissions and relationships

Any guidance on resolving this RLS enforcement issue with Fabric Data Agents would be greatly appreciated.We're experiencing an issue where the Fabric Data Agent is not honoring Row-Level Security (RLS) configurations in our semantic model, despite Microsoft documentation stating it should respect all user permissions including RLS and CLS.

Environment:

Accessing Fabric Data Agent through Azure AI Foundry integrated into our custom portal
RLS is properly configured on the semantic model.
Power BI embedding in the same environment correctly respects RLS and shows filtered data
Users authenticate properly and have appropriate permissions

Issue Details: When users query the Fabric Data Agent, it returns ALL data from the semantic model instead of applying the RLS filters. The same users, when viewing Power BI reports embedded in our portal, only see their authorized data subset as expected.

Expected Behavior: According to the documentation at https://learn.microsoft.com/en-us/fabric/data-science/data-agent-sharing, the Fabric Data Agent should "honor all user permissions to the data, including Row-Level Security (RLS) and Column-Level Security (CLS)."

Actual Behavior:

Power BI embedding: ✅ Correctly applies RLS, shows only user's accessible data
Fabric Data Agent: ❌ Shows all data, ignores RLS configuration

Questions:

Are there specific configuration steps required to enable RLS for Fabric Data Agents that differ from Power BI RLS setup?
Is there a known issue with RLS enforcement when accessing Data Agents through Azure AI Foundry?
Are there additional authentication or context-passing requirements for Data Agents to recognize user identity for RLS filtering?
Is this a limitation of the current Fabric Data Agent implementation, or are we missing a configuration step?

What We've Tried:

Verified RLS rules are active and working in Power BI
Confirmed user authentication is working correctly
Tested with multiple users - all see complete dataset instead of filtered results
Reviewed semantic model permissions and relationships

Any guidance on resolving this RLS enforcement issue with Fabric Data Agents would be greatly appreciated.

Pavankumar Purilla 11,655 Reputation points Moderator

2025-09-16T12:14:42.3866667+00:00

Hi Durjan Hussain,

Based on your description, the issue appears to be related to identity context not being passed from Azure AI Foundry to the Fabric Data Agent, which prevents your configured Row-Level Security (RLS) rules from being applied. While Power BI embedding automatically passes the user’s Azure AD identity (allowing RLS to work correctly), queries through the Fabric Data Agent may run under the agent’s service identity if user context is not propagated, resulting in all data being returned.

Please ensure that:

Your semantic model is published and enabled for query, and the RLS roles are properly configured and active.

The Data Agent is configured to use Single Sign-On (SSO) or an appropriate identity mode so that end-user tokens are passed during queries.

Users have only the intended RLS-based access and not broader permissions directly on the underlying Lakehouse or Warehouse.

As a quick test, you can run a query (e.g., using USER_NAME()) through the Data Agent to check which identity is being seen. If it returns a generic service identity, it confirms the issue is with identity propagation.

There are currently known limitations where RLS may not be enforced when the Fabric Data Agent is accessed via Azure AI Foundry, and our product team is actively working on improving this behavior. If the issue persists after confirming the above configurations, we recommend raising a support case so the product group can investigate this further for your tenant.
For reference: Row-level security in Fabric data warehousing
Pavankumar Purilla 11,655 Reputation points Moderator

2025-09-17T02:42:34.08+00:00

Hi Durjan Hussain,
Did you get any chance to check the response. Thank you!

3 answers

Your answer

Pavankumar Purilla 11,655 Reputation points Moderator

2025-09-16T12:14:42.3866667+00:00

Hi Durjan Hussain,

Based on your description, the issue appears to be related to identity context not being passed from Azure AI Foundry to the Fabric Data Agent, which prevents your configured Row-Level Security (RLS) rules from being applied. While Power BI embedding automatically passes the user’s Azure AD identity (allowing RLS to work correctly), queries through the Fabric Data Agent may run under the agent’s service identity if user context is not propagated, resulting in all data being returned.

Please ensure that:

Your semantic model is published and enabled for query, and the RLS roles are properly configured and active.

The Data Agent is configured to use Single Sign-On (SSO) or an appropriate identity mode so that end-user tokens are passed during queries.

Users have only the intended RLS-based access and not broader permissions directly on the underlying Lakehouse or Warehouse.

As a quick test, you can run a query (e.g., using USER_NAME()) through the Data Agent to check which identity is being seen. If it returns a generic service identity, it confirms the issue is with identity propagation.

There are currently known limitations where RLS may not be enforced when the Fabric Data Agent is accessed via Azure AI Foundry, and our product team is actively working on improving this behavior. If the issue persists after confirming the above configurations, we recommend raising a support case so the product group can investigate this further for your tenant.
For reference: Row-level security in Fabric data warehousing
Pavankumar Purilla 11,655 Reputation points Moderator

2025-09-17T02:42:34.08+00:00

Hi Durjan Hussain,
Did you get any chance to check the response. Thank you!

Answer 1

Durjan Hussain 185

Hi @Sana Salam , @Pavankumar Purilla We were able to resolve the issue by using the link below and with help from the Microsoft team, especially: @Zidan M

https://learn.microsoft.com/en-us/fabric/data-warehouse/tutorial-row-level-security

The RLS wasn’t applied at the table level; it was only applied in the semantic model for Power BI embedding.

Thank you very much for your help. @Sana Salam and @Pavankumar Purilla

RLS_Working

0 comments

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

1 deleted comment

Comments have been turned off. Learn more

Answer 3

Sina Salam 31,056 Volunteer Moderator

Hello Durjan Hussain,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Fabric Data Agent Not Respecting Row-Level Security (RLS) - Returns All Data Instead of Filtered Results.

My best advice:

Capture token in browser devtools when the portal calls Foundry > decode (jwt.ms). Is there a preferred_username/upn claim? If no, it’s a service principal token > go to step - https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow
If it’s a SP token, implement OBO: switch frontend to user auth (MSAL.js) > pass user token to backend > perform AcquireTokenOnBehalfOf via MSAL > call Foundry with that token. See MSAL OBO docs here - https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/web-apps-apis/on-behalf-of-flow
If you can’t do OBO quickly, move RLS to Warehouse/SQL (DB-level enforcement) or implement server-side authorizing filters (short term). - https://learn.microsoft.com/en-us/fabric/data-warehouse/row-level-security
Enable / check audit logs and correlate for timestamp + token claims + Fabric audit entry to prove effective identity. Provide these to Microsoft support via your Azure Portal if the issue persists. - https://learn.microsoft.com/en-us/fabric/data-warehouse/configure-sql-audit-logs

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Durjan Hussain 185

Hi , @Pavankumar Purilla

The semantic model is published with proper RLS configuration
Users are assigned to the workspace with appropriate access
The issue is specifically with RLS not being enforced through Azure AI Foundry → Fabric Data Agent

@Sina Salam

Yes, we have tried the on-behalf-of flow and RLS still doesn't work. Please see the code snippet below.



[HttpPost("ask")]
  public async Task<IActionResult> Ask([FromBody] AIChatRequest aIChatRequest)
  {
    
      var authHeader = Request.Headers["Authorization"].FirstOrDefault();
      if (string.IsNullOrEmpty(authHeader) || !authHeader.StartsWith("Bearer "))
      {
          throw new UnauthorizedAccessException("No valid bearer token found in Authorization header");
      }
 
      var userAccessToken = authHeader.Substring("Bearer ".Length).Trim();
 
      (var answer, var threadId) = await _fabricAgentService.AskAsync(userAccessToken, aIChatRequest);
 
      return Ok(new { answer, threadId });
  }

------
public async Task<string> GetAccessTokenOnBehalfOfAsync(string userAccessToken)
     {
         var app = ConfidentialClientApplicationBuilder.Create(_azureAdSettings.ClientId)
             .WithClientSecret(_azureAdSettings.ClientSecret)
             .WithAuthority(new Uri($"https://login.microsoftonline.com/{_azureAdSettings.TenantId}"))
             .Build();
 
         // Create UserAssertion from the incoming AI token
         var userAssertion = new UserAssertion(userAccessToken);
 
         // Acquire token on behalf of the user for the target scope
         var result = await app.AcquireTokenOnBehalfOf(new[] { "https://ai.azure.com/.default" }, userAssertion)
             .ExecuteAsync();
 
         return result.AccessToken;
     }

Sina Salam 31,056 Volunteer Moderator

Hello Durjan Hussain,

Thank you for your feedback.

If indeed you have tried the on-behalf-of flow and RLS then something deeper (token audience/scopes, incoming token type, workspace/underlying-permissions, or a product preview limitation) is still wrong.

You need to understand that the Fabric + Foundry integration requires user context (delegated token) to apply semantic-model RLS. A service principal token (client credentials) will usually have service identity and will not be filtered by RLS the same way - https://learn.microsoft.com/en-us/fabric/data-science/data-agent-foundry

I believe you can diagnose before escalating, except you will wait for a perfect product from Microsoft.

So, these are concrete tests you can run now:

In devtools, copy the Authorization header and paste into jwt.ms. Confirm presence of upn / preferred_username and check aud. If upn is absent this is the immediate cause.

If you are using MSAL.js on frontend get token for backend:

   const result = await msalInstance.acquireTokenSilent({
        scopes: ["api://<BACKEND_CLIENT_ID>/access_as_user"]
      });
      // send result.accessToken as the Authorization: Bearer <token> to your backend

Your C# snippet for backend should look like the following:

   using System.IdentityModel.Tokens.Jwt;
      var jwt = new JwtSecurityTokenHandler().ReadJwtToken(userAccessToken);
      var aud = jwt.Audiences.FirstOrDefault(); // e.g., "api://<backend-client-id>"
      var upn = jwt.Claims.FirstOrDefault(c => c.Type=="preferred_username"||c.Type=="upn")?.Value;
      // If upn missing -> incoming token is a SP token or an ID token. Fix frontend to send an access token for the backend.

Then you can use AcquireTokenOnBehalfOf (derive scope) like below:

   var userAssertion = new UserAssertion(userAccessToken);
      string downstreamScope = $"{someFoundryAppIdOrAudience}/.default"; // derive or use https://ai.azure.com/.default if confirmed
      var result = await app.AcquireTokenOnBehalfOf(new[] {downstreamScope}, userAssertion).ExecuteAsync();

You can ask the agent: `Run SQL: SELECT CURRENT_USER AS current_user;` or Return the value of the measure `` CurrentUser = USERPRINCIPALNAME() `` from the semantic model. If it responds with a service principal / workspace identity > identity passthrough failed.

If this really happen in my production environment, the below is my checklist with the links:

Capture the Authorization header that your portal sends to Foundry. Decode — check upn/preferred_username and aud. (If upn/preferred_username missing → STOP and fix token acquisition on client.)
If incoming token is not an access token for your backend, change client to acquire an access token for your backend (msal.js acquireTokenSilent for api://<backend>/access_as_user).
In backend, derive downstream OBO scope from incoming token aud or use the Foundry resource app URI (use /.default) when calling AcquireTokenOnBehalfOf. Don’t hard-code if you’re unsure — derive.

Use this link to check the above: https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/web-apps-apis/on-behalf-of-flow

Validate Fabric side: run USERPRINCIPALNAME() / SELECT CURRENT_USER via the agent to confirm the identity Fabric sees.
Check Fabric/Foundry tenant settings & roles (Copilot tenant switch, Fabric data agent tenant settings, cross-geo, XMLA) and the minimum data-source permissions (Build vs Read) for the users. - https://learn.microsoft.com/en-us/fabric/data-science/data-agent-sharing
If identity still does not flow, gather the tokens + correlation IDs + audit logs and open Microsoft support — include all artifacts. (Product team may need to confirm preview behavior or tenant-specific config.) - https://community.fabric.microsoft.com/t5/Fabric-platform/Azure-AI-Foundry-with-Fabric-Data-Agent-using-Managed-Identity/m-p/4825205
As a short-term fallback, implement warehouse-level RLS or server-side filtering. - https://learn.microsoft.com/en-us/fabric/data-warehouse/row-level-security

Check the below, C# Web API controller example that uses MSAL.NET to implement the On-Behalf-Of (OBO) flow effectively with your scenario in consideration:

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Identity.Client;
using System.IdentityModel.Tokens.Jwt;
using System.Net.Http.Headers;
using System.Text.Json;
namespace YourApp.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class FabricAgentController : ControllerBase
    {
        private readonly IConfiguration _config;
        private readonly IHttpClientFactory _httpClientFactory;
        public FabricAgentController(IConfiguration config, IHttpClientFactory httpClientFactory)
        {
            _config = config;
            _httpClientFactory = httpClientFactory;
        }
        [Authorize] // Ensure only authenticated calls
        [HttpPost("ask")]
        public async Task<IActionResult> Ask([FromBody] AIChatRequest request)
        {
            // 1. Extract incoming bearer token from request
            var authHeader = Request.Headers["Authorization"].FirstOrDefault();
            if (string.IsNullOrEmpty(authHeader) || !authHeader.StartsWith("Bearer "))
            {
                return Unauthorized("Missing or invalid Authorization header.");
            }
            var incomingToken = authHeader.Substring("Bearer ".Length).Trim();
            // 2. Validate & inspect token claims (for debugging)
            var handler = new JwtSecurityTokenHandler();
            var jwt = handler.ReadJwtToken(incomingToken);
            var upn = jwt.Claims.FirstOrDefault(c => c.Type == "preferred_username" || c.Type == "upn")?.Value;
            var aud = jwt.Audiences.FirstOrDefault();
            var tid = jwt.Claims.FirstOrDefault(c => c.Type == "tid")?.Value;
            if (string.IsNullOrEmpty(upn))
            {
                return Unauthorized("Incoming token does not contain a user identity (UPN). Ensure frontend acquires an access token, not ID token.");
            }
            // 3. Acquire downstream token for Foundry using OBO
            string clientId = _config["AzureAd:ClientId"];       // Your backend app client ID
            string clientSecret = _config["AzureAd:ClientSecret"]; // Your backend app secret
            string tenantId = _config["AzureAd:TenantId"];         // Tenant ID
            var app = ConfidentialClientApplicationBuilder.Create(clientId)
                .WithClientSecret(clientSecret)
                .WithAuthority($"https://login.microsoftonline.com/{tenantId}")
                .Build();
            // Downstream scope (adjust if your Foundry resource is different)
            string[] downstreamScopes = new[] { "https://ai.azure.com/.default" };
            var userAssertion = new UserAssertion(incomingToken);
            AuthenticationResult result;
            try
            {
                result = await app.AcquireTokenOnBehalfOf(downstreamScopes, userAssertion)
                                  .ExecuteAsync();
            }
            catch (MsalUiRequiredException ex)
            {
                return Unauthorized($"OBO token acquisition failed. Details: {ex.Message}");
            }
            var foundryToken = result.AccessToken;
            // 4. Call Foundry with the acquired token
            var client = _httpClientFactory.CreateClient();
            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", foundryToken);
            // Example: POST to Fabric Data Agent endpoint
            string foundryEndpoint = _config["Foundry:Endpoint"]; 
            // e.g. "https://<your-foundry-project>.api.azureml.ms/agents/<agent-id>/ask"
            var payload = JsonSerializer.Serialize(new
            {
                question = request.Question,
                threadId = request.ThreadId
            });
            var response = await client.PostAsync(foundryEndpoint, new StringContent(payload, System.Text.Encoding.UTF8, "application/json"));
            var responseContent = await response.Content.ReadAsStringAsync();
            if (!response.IsSuccessStatusCode)
            {
                return StatusCode((int)response.StatusCode, $"Foundry call failed: {responseContent}");
            }
            return Ok(JsonSerializer.Deserialize<object>(responseContent));
        }
    }
    // Simple DTO for incoming request
    public class AIChatRequest
    {
        public string Question { get; set; }
        public string ThreadId { get; set; }
    }
}

Success

Durjan Hussain 185 Reputation points

2025-09-18T13:10:18.8633333+00:00

Hi @Sana Salam

We really appreciate your detailed response, but we have already tried all the options.

I believe the issue lies on the Data Agent side, where it is not respecting the RLS.

We know that using the Service Principal doesn’t work with the Fabric Data Agent.

We also know that AI Foundry is passing the user credentials to the Fabric Data Agent, otherwise the Data Agent would not have allowed data access.

Kind regards,

Durjan
Sina Salam 31,056 Reputation points Volunteer Moderator

2025-09-18T15:25:02.29+00:00
Hi Durjan Hussain,

It's fine if you could let us know what you find later, but are you really using Warehouse or semantic model as the Fabric data source for the agent?

I believe strongly something is missing somewhere however, if you can:

Implement or tighten DB‑tier RLS policies; test with USER_NAME() mapping (for Warehouse), and enable SQL audit logs; run validation tests and archive logs/screenshots for support.

We should get the whole clue to the final solution.

Have a good success.
Durjan Hussain 185 Reputation points

2025-09-18T16:13:30.9066667+00:00

Hi @Sina Salam , @Pavankumar Purilla

Please see the screenshots below. The user context has been successfully passed from the backend API to AI Foundry, and then to the Fabric Data Agent.

@Sina Salam we are using the semantic model.

As I said before the RLS works fine for the PowerBI embedding. It's a same data source for both PowerBI embedding and Fabric Data Agent.
Sina Salam 31,056 Reputation points Volunteer Moderator

2025-09-18T16:34:30.6066667+00:00

Hi Durjan Hussain,

Thank you for letting us know.

Since RLS (Row-Level Security) works for Power BI embedding, it should theoretically also work for the Fabric Data Agent if the same semantic model is used and the user context is correctly passed.

Observe the best thing you can do above to find final solution.