A Fabric data agent can bypass your workspace roster—because Power BI Read permission is enough

Microsoft’s Fabric data-agent documentation draws a boundary that is easy to miss during an access review: a person can query a Power BI semantic model through a data agent with Read permission alone. They do not need Build permission, and they do not need access to the workspace that contains the model. Row-level and column-level security still apply, but the workspace member list is therefore not a complete inventory of who can ask the model questions.

The agent has two permission gates

Sharing the agent and sharing the data are separate operations. Microsoft says recipients need access to the Fabric data agent and to its underlying sources. For Power BI semantic models, the minimum effective source permission is Read. For other supported sources, the documented floor varies: lakehouses require item-level Read plus table access where enforced; warehouses require Read or SELECT on the relevant tables; KQL databases require the Reader role; and ontologies require access both to the ontology and to the source bound beneath it.

That distinction creates a practical troubleshooting rule. A user may be able to open the agent but still receive authorization errors or empty results when a question touches a source they cannot read. Conversely, a user absent from the workspace roster can still receive answers if the agent and semantic model were shared directly with them.

Audit the effective reader set

For operators, the useful unit of review is not “who is in the workspace?” It is the intersection of three sets: people who can use the published agent, people who have Read access to each connected model or source, and people who pass the source’s row- and column-level policies. That is the population capable of getting an answer.

This also argues against granting Build merely to make an agent work. Microsoft says Build or Write remains necessary for model changes and capabilities such as Prep for AI, but not for queries initiated through a Fabric data agent. Least-privilege deployments should therefore separate consumers, who need Read, from builders, who need broader rights.

Published and draft access are different

The agent itself has another useful boundary. Publishing creates a read-only version that can be shared while its draft continues to change independently. A recipient with the default sharing permission can query only the published version and cannot inspect its configuration. “View details” exposes both published and draft configurations without edit rights; “Edit and view details” permits changes to both.

The operational checklist is short: inventory direct Read grants on every connected semantic model, verify source-specific permissions beyond Power BI, test row- and column-level policy outcomes with representative users, and keep Build or workspace membership reserved for people who actually author. If an access review looks only at workspace roles, it is reviewing the wrong boundary.