Forum Discussion

gkl's avatar
gkl
New Member
1 month ago
Solved

Fabric Data Agent Access issue

I have created a fabric data agent using semantic model of a published report, It is working fine but I'm not able to share it with others I published the agent in M365 copilot and share with my te...
data protection
dataflow
General Comment
Interesting Links
Need Help
Show and Tell
Tips and Tricks
Tutorial Requests
  • v-sathmakuri's avatar
    v-sathmakuri
    1 month ago

    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!!

jubinsoni's avatar
jubinsoni
Icon for Memorable Member rankMemorable Member
26 days ago

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.