Fabric data agents can become Copilot Studio tools—but “maker” authentication changes who can see the data

Microsoft’s Fabric-to-Copilot Studio integration looks like a straightforward packaging step: publish a Fabric data agent, add it to a Copilot Studio agent through the Fabric IQ Data MCP tool, and expose the result in Teams or Microsoft 365 Copilot. The important deployment decision is buried later in the setup: whose identity does the tool use?

User mode preserves per-person access

In User authentication mode, the Fabric data agent runs with the credentials of the person chatting with the Copilot Studio agent. Microsoft says that person must be able to access both the data agent and its underlying sources. Someone without those permissions does not receive an answer from the tool.

That makes User mode the safer default when an organization expects its existing Fabric permissions to remain the effective authorization boundary. It also creates an operational requirement: every intended user needs the relevant access, and permission failures become part of the chat experience.

Maker mode is delegated access

In Maker mode, calls use the credentials of the person who configured the Copilot Studio agent. Microsoft explicitly says end users do not need their own access to the Fabric data agent or its sources; everyone using the agent sees data through the maker’s access.

That is not merely a convenience setting. It turns the maker’s account into a shared authorization path. Teams choosing it should treat the agent’s audience, the maker’s data grants and the tool’s question scope as one access-control design. A broadly privileged maker account paired with a broadly distributed agent can expose answers to people who could not query the source directly.

Microsoft’s setup does retain several useful controls. Only published Fabric data agents appear in OneLake catalog, the Fabric and Copilot Studio agents must be in the same tenant, and administrators can test individual prompts and run an evaluation set before publishing. Tool descriptions also affect routing: Copilot Studio’s orchestrator uses the description to decide when to call each data agent, so vague descriptions can become a reliability problem when several tools are attached.

The compliance boundary may move

Identity is only half of the review. Microsoft warns that responses consumed by Copilot Studio, Microsoft 365 Copilot, Foundry or an MCP client may leave Fabric’s compliance boundary or geographic region. Once outside Fabric, processing and storage follow the receiving service’s terms and data-handling policies.

Fabric administrators may also need to enable cross-region processing and storage settings, depending on capacity location. Microsoft says conversational history can be retained across sessions for as long as the user permits, up to 28 days unless it is cleared.

The practical checklist is short: choose User mode unless delegated maker access is intentional; minimize the maker’s grants if Maker mode is required; define the agent’s audience before publishing; test unauthorized-user cases, not only happy paths; and have compliance owners approve the destination service’s region, retention and handling rules. The integration makes governed data callable from a wider agent. It does not make that wider distribution automatically governed.