Fabric Data Agent Access issue

which role did you give to users on the semantic model?

they need read permission.

At the tenant level, are there any privileges about whether you need to submit an agent for organizational approval? It sounds to me like something in M365 copilot. Also, they would likely need an M365 copilot granting and it could be that it isn't org-wide.

Hi gkl​ ,

Thank you for reaching out to fabric community!!

Since Microsoft 365 Copilot is enabled across the organization, compare one working user with one failing user rather than changing workspace roles. Ensure the affected user has Read permission on both the Fabric Data Agent and the underlying semantic model and verify that Copilot access is enabled for the semantic model. If RLS is configured also confirm that the user belongs to the appropriate RLS role. Since your DL based Viewer user can access the agent while some Contributors cannot the issue is more likely related to effective permissions, group membership or RLS rather than the Pro vs PPU license. As a test give one failing user direct Read access to the Data Agent & semantic model and then test the agent again.

Thanks!!

verify that Copilot access is enabled for the semantic model?
can you brief this part
how to check it?
because the feed fabric data agent to copilot studio as tools and from the I published in M365, there also I face the same issue.
this is the exact error AI gives
"I tried to pull this from semantic model but data tool is returning an access error (HTTP 403- authorization denied)"

Hi gkl​ ,

The HTTP 403 authorization error points to a permissions issue. In Semantic model -> Settings -> Explore and AI access -> Copilot, confirm that the option allowing users with Read permission to use AI/Copilot is enabled. Also confirm that the affected users have Read permission on the underlying semantic model, rather than only Workspace Contributor or Data Agent access. Because the same issue occurs through Copilot Studio, verify whether the tool uses User authentication. If so, each user must have access to the underlying semantic model.

Thanks!!

Hi gkl​ ,

Could you check the suggestion provided above and let us know if you have any additional queries?

Thanks!!

Hi gkl​,

The detail you mentioned is the strongest clue in this thread: the user who works has only Viewer access through a distribution list, while users with higher workspace roles added individually fail. Workspace roles can't explain that, because Member and Contributor include everything Viewer has.

What it does point to is group membership. The Copilot / Azure OpenAI tenant settings (and the data agent settings) are often enabled only for specific security groups. If that group is, or contains, your DL, then everyone in it works and everyone outside it fails, regardless of their workspace role or license.

in the enabled group  -> agent answers   (your 4-5 users)
not in the group      -> agent visible via link, but no answers
workspace role        -> irrelevant to this particular failure

The quickest proof is to compare the group memberships of one working and one failing user. With Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "User.Read.All","GroupMember.Read.All"

$working = "[email protected]"
$failing = "[email protected]"

$w = Get-MgUserTransitiveMemberOf -UserId $working -All |
     ForEach-Object { $_.AdditionalProperties.displayName }
$f = Get-MgUserTransitiveMemberOf -UserId $failing -All |
     ForEach-Object { $_.AdditionalProperties.displayName }

# groups only the working user is in
Compare-Object $w $f | Where-Object SideIndicator -eq "<="

Then ask a Fabric admin to check which groups the AI-related tenant settings are scoped to. In the Admin portal that is Tenant settings > Copilot and Azure OpenAI Service. An admin can also list them all at once with the List Tenant Settings admin API, which returns enabledSecurityGroups for each setting:

GET https://api.fabric.microsoft.com/v1/admin/tenantsettings

If one of the groups from the comparison shows up there, add the 100-person team (ideally as a security group) to that setting.

On the second symptom, most people not finding the agent in M365 Copilot: that is a separate layer. Sharing the agent with a group, and, depending on your M365 admin settings, approving it for the organization in the Microsoft 365 admin center, controls who can discover it. Sharing the link only gets people to the agent; it doesn't grant them the tenant-level AI permissions behind it.

So my overall approach would be:

compare group memberships: working vs failing user
-> match the extra group against AI tenant setting scopes
-> add the team's security group to those settings
-> share / approve the agent for the same group in M365

That should explain why a Viewer in the DL works while individually added Contributors don't.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi gkl​ ,

Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address. 

Thanks!!