Fabric Core MCP Server Now Generally Available: Permissions and Risks of AI Agents Managing Fabric Resources

Microsoft officially launched the Fabric Core MCP Server following the FADCON conference in Barcelona, adding it to the Microsoft Fabric updates roster for September 2026. This is a Microsoft-hosted remote endpoint that enables compatible AI agents to access workspaces, items, permissions, search, and capacity information in an authenticated, fully audited manner. On the surface, it looks like just another convenience tool that "lets AI help you manage resources" — but the architectural question worth examining is: whose permissions is the agent actually using?

From DIY Glue Code to a Managed Endpoint

Before the managed endpoint existed, enabling an AI agent to operate on Fabric resources meant building the entire toolchain yourself — a local Fabric MCP server, custom scripts targeting the Fabric REST API, credentials stored somewhere, and your own interpretation of what the agent was allowed to call.

The problem was that every team assembled this "glue code" differently. As a result, the two most critical questions — who performed an action and what they were permitted to do — depended entirely on how carefully that glue code was written. This fragmented approach increased maintenance overhead and made auditing and compliance difficult to trace.

Fabric Core MCP Server exists to standardize this uncertain middle layer and hand it off to Microsoft to host.

Endpoint Architecture and Authentication

The Core server is a Microsoft-hosted remote endpoint at api.fabric.microsoft.com/v1/mcp/core. Your MCP host connects to it via streamable HTTP, then authenticates using Microsoft Entra ID through a browser-based OAuth flow. Once authenticated, the agent discovers the available toolset.

Those tools cover catalog search, workspaces, items, workspace roles, folders, and capacity information. There is one core mechanic you must understand: when you ask a question, the agent selects the appropriate tools, and the server calls the Fabric REST APIs on your behalf using the permissions of your authenticated identity.

In other words, connecting to this server grants no additional permissions whatsoever. If you are an admin in a workspace, the agent is an admin there too; if your access is restricted, so is the agent's. Crucially, Fabric logs supported operations to the audit log under the identity that actually performed them. Every action is traceable back to a real person or service principal.

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud identity and access management service, responsible for handling the OAuth 2.0 authorization flow. In the MCP context, its role is to ensure every tool call carries a verifiable user token rather than an anonymous or shared credential. Streamable HTTP is a transport defined in the MCP protocol specification that allows the server to push responses in a streaming fashion — better suited for long-running interactions between agents and tool servers than traditional HTTP polling or WebSockets. Together, these two mechanisms ensure each call is both identity-bound and capable of sustaining time-consuming Fabric API operations without timing out.

A Clear Boundary: Core Manages Resources, Not Data

The scope of Fabric Core MCP Server is clearly defined — it handles resource management, not data manipulation.

Concretely, it can create workspaces, add a lakehouse, or grant someone a contributor role. It is not a general-purpose tool for querying or modifying data inside a lakehouse. For data operations, you need dedicated workload servers:

• Data Warehouse MCP server: for T-SQL operations
• EventHouse server: for KQL queries

If the client supports it, a single agent can use multiple servers simultaneously. This layered design keeps "resource management" and "data operations" as separate responsibilities, making it easier to control permission granularity on demand.

MCP (Model Context Protocol) is an open protocol originally proposed by Anthropic and now adopted by multiple AI vendors. It defines how AI models discover and invoke external tools. The core idea is to decouple "tool capabilities" from the model itself: models query a server via a standardized interface to discover what tools are available, then invoke them as needed — without hardcoding specific API details. Fabric's architecture of "one Core server plus multiple workload servers" is a direct expression of this decoupling — resource management and data operations live on separate servers, meaning permissions can be tightened independently at each layer: you can allow an agent to create workspaces without also granting it T-SQL query access.

When to Use It — and When Not To

The right use cases are clear: when you want an agent to help explore and build out a Fabric environment, when you need every supported operation tied to a real identity in the audit log, and when you don't want to build and maintain the integration yourself — that's when this managed server is the right choice.

But the official Learn documentation is also candid about a concerning reality: autonomously running or misconfigured clients can execute destructive operations. Safety guardrails like "flags to block destructive operations" are not standardized in the MCP protocol, and not every client supports them.

This leads to several pragmatic security recommendations:

• Don't point an agent running with a tenant admin account at a production environment and hope for the best
• Use a least-privilege identity
• Keep client approval settings enabled
• Review tool calls before changes are executed

There's also a compliance issue that's easy to overlook: the client and model may process data outside Fabric's compliance boundary, under their own terms. If that's a concern for your organization, the bottleneck isn't the server — it's the client.

The Principle of Least Privilege is a foundational security concept requiring that any identity be granted only the minimum permissions necessary to complete its task. This principle is especially important in AI agent scenarios: because agents can autonomously chain multiple tool calls, a high-privilege identity triggered by incorrect instructions could complete a series of irreversible operations — such as bulk-deleting workspaces or reassigning roles — before a human notices. Creating a dedicated, permission-limited service principal for the agent rather than reusing an admin account is basic hygiene for using any MCP server in production.

Availability and Access Requirements

Fabric Core MCP Server is now Generally Available.

To connect, you need:

• An MCP host that supports streamable HTTP and Entra ID login (Microsoft recommends VS Code + GitHub Copilot)
• Access to at least one workspace

On pricing, the Learn documentation does not list a separate cost for the server itself. There is also a local Fabric MCP server for local development, but note that the local server does not generate Fabric audit logs — only the underlying Fabric services may log its operations. This is a key difference between the local and hosted versions.

Since agents inherit workspace roles, it's worth taking time to understand Fabric's workspace role and permission model before deploying this in earnest. A clear understanding of permission boundaries is the real prerequisite for using this tool safely.