Forum Discussion
Share Fabric Data Agent
Hi Antoine1733,
Hi
You're right, there isn't a single official Microsoft document that outlines a comprehensive permission matrix for all Data Agent sharing scenarios (such as Lakehouse vs Semantic Model, direct sharing vs workspace access). The permissions are spread across several articles, which can make setup expectations unclear, especially since some preview features still use workspace-level checks internally.
For semantic model–based Data Agents, the typical permissions needed are:
- Access to the Data Agent
- Build permission on the semantic model
- Sometimes Viewer access on the workspace, depending on tenant or security configuration
For Lakehouse-based Data Agents:
- Read and Execute permissions on the Lakehouse
- Access to the Data Agent
- Workspace-level checks might apply in some preview or security scenarios
The most relevant official resources are:
- Share Fabric Data Agent documentation
- Fabric Data Agent concepts
- Semantic model permissions documentation
- Workspace roles documentation
Currently, the behavior depends on both documentation and the current implementation or preview limitations, so troubleshooting may require testing additional workspace permissions even if they're not explicitly documented.
Thank you.
Hi Antoine1733, interesting issue 🙂
From the error message, this doesn’t look like a simple Lakehouse permission problem to me.
What’s a bit confusing with Fabric Data Agents right now is that even when the agent is connected only to a Lakehouse, some operations still seem to go through internal Power BI / Fabric workspace security checks behind the scenes. That would explain why you’re seeing :
- PowerBINotAuthorizedException
- Error retrieving workspace network security settings
even though the user already has :
- Read + Execute on the Lakehouse
- Access to the Data Agent itself
According to the current documentation, workspace access shouldn’t be required when you share a data agent and grant access to the underlying Lakehouse. However, in some preview and network‑secured scenarios, Fabric still appears to evaluate workspace network settings behind the scenes, which is why testing Viewer access on the workspace is a useful diagnostic step rather than a strict requirement.
What I would personally try first :
- Temporarily add the target user as Viewer on the workspace
- Then retest the agent queries
- If it suddenly works, you’ve confirmed that the blocking permission is at workspace / network‑settings level rather than at Lakehouse level
I would also check whether the workspace has :
- Managed private endpoints
- Network security settings
- Tenant‑level restrictions
because these often trigger additional authorization checks in secured / preview scenarios.
So my feeling is that this is probably a current limitation or dependency in the preview implementation, where the Data Agent still relies on workspace‑level context for some security evaluations, even in a Lakehouse‑only setup. If org policy doesn’t allow permanent Viewer access, you can :
- Keep the direct Data Agent sharing
- Use Viewer only for troubleshooting
- Then remove it again and raise a ticket / idea with Microsoft so they can align behavior with the documentation.
Hope this helps you narrow down the root cause 🙂
If you can share whether adding Viewer solved it (or not), that would be very useful for others hitting the same issue.
Docs :
- https://learn.microsoft.com/en-us/fabric/data-science/data-agent-sharing
- https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent
- https://community.fabric.microsoft.com/t5/Data-Engineering/interact-with-a-Fabric-data-agent-with-minimum-permission/
- https://community.fabric.microsoft.com/t5/Fabric-Updates-Blogs/Update-to-required-permissions-for-Semantic-Models-in-Fabric/ba-p/
- https://learn.microsoft.com/en-sg/answers/questions/2261109/ai-agent-fails-to-retrieve-data-from-fabric-data-a