Fabric Core MCP Server正式发布：AI智能体管理Fabric资源的权限与风险

微软在巴塞罗那FADCON大会后正式推出了Fabric Core MCP Server，并将其列入2026年9月的Microsoft Fabric更新清单。这是一个由微软托管的远程端点，让兼容的AI智能体能够以经过身份认证、全程审计的方式访问工作区、项目、权限、搜索以及容量信息。表面上看，这只是又一个"让AI帮你管理资源"的便利工具，但真正值得深究的架构问题是：智能体到底在用谁的权限办事？

从自建胶水代码到托管端点

在托管端点出现之前，想让AI智能体操作Fabric资源，你得自己搭建整套工具链——本地Fabric MCP服务器、或者针对Fabric REST API编写的自定义脚本，再加上存放在某处的凭据，以及你自己对"智能体可以调用什么"的理解。

问题在于，每个团队搭建这套"胶水代码"的方式都不一样。于是最关键的两个问题——谁执行了操作、他们被允许做什么——完全取决于这套胶水代码写得有多严谨。这种碎片化的做法既增加了维护成本，也让审计和合规变得难以追溯。

Fabric Core MCP Server的出现，正是要把这套不确定的中间层标准化，交给微软托管。

端点架构与身份认证机制

Core服务器是一个由微软托管的远程端点，地址为 api.fabric.microsoft.com/v1/mcp/core。你的MCP主机通过可流式传输的HTTP（streamable HTTP）连接到它，再经由基于浏览器的OAuth流程使用Microsoft Entra ID登录。登录完成后，智能体便能发现可用的工具集。

这些工具包括目录搜索、工作区、项目、工作区角色、文件夹以及容量信息。这里有一个必须理解的核心机制：当你提出一个问题时，智能体会挑选合适的工具，服务器则以已认证身份的权限代表你调用Fabric REST API。

换句话说，连接这个服务器本身不会授予任何额外权限。如果你在某个工作区是管理员，那么智能体在那里也是管理员；如果你权限受限，智能体同样受限。更重要的是，Fabric会将受支持的操作记录到审计日志中，并挂在实际执行该操作的身份名下。这意味着每一个动作都能追溯到真实的人或服务身份。

Microsoft Entra ID（前身为 Azure Active Directory）是微软的云身份与访问管理服务，负责处理 OAuth 2.0 授权流程。在 MCP 场景下，它的作用是确保每一次工具调用都携带可验证的用户令牌，而非匿名或共享凭据。Streamable HTTP 是 MCP 协议规范中定义的一种传输方式，允许服务端以流式方式推送响应，相比传统的 HTTP 轮询或 WebSocket 更适合智能体与工具服务器之间的长时请求交互。两者结合，使得每次调用既有身份绑定，又能支持耗时较长的 Fabric API 操作而不超时断连。

明确的职责边界：Core只管资源

Fabric Core MCP Server的作用范围非常清晰——它负责管理资源，而非操作数据。

具体来说，它能创建工作区、添加lakehouse、给某人授予contributor角色这类操作。但它不是用来查询或修改lakehouse数据表内容的通用工具。想要操作数据，你需要专门的工作负载服务器（workload servers）：

• Data Warehouse MCP server：用于T-SQL操作
• EventHouse server：用于KQL查询

如果客户端支持，一个智能体可以同时使用多个服务器。这种分层设计让"管理资源"和"操作数据"的职责保持分离，也便于按需控制权限粒度。

MCP（Model Context Protocol）是由 Anthropic 提出、目前被多家 AI 厂商采纳的开放协议，定义了 AI 模型如何发现并调用外部工具。其核心思想是将"工具能力"从模型本身解耦：模型通过标准化接口查询服务器支持哪些工具，再按需调用，而无需硬编码具体的 API 细节。Fabric 采用"一个 Core 服务器 + 多个工作负载服务器"的分层架构，正是这种解耦设计的体现——资源管理与数据操作分属不同服务器，也意味着权限可以按层级单独收紧：允许智能体创建工作区，但不必同时开放 T-SQL 查询能力。

什么时候该用，什么时候别用

适合使用的场景很明确：当你希望智能体帮助探索和搭建Fabric环境、当你需要让每一个受支持的操作都绑定到审计日志中的真实身份、同时又不想自己构建和维护整套集成时，这个托管服务器就是正确选择。

但官方Learn文档也直言不讳地指出了令人不安的一面：自主运行或配置错误的客户端可能执行破坏性操作。像"阻止破坏性操作的标志位"这类安全防护在MCP协议中尚未标准化，并非每个客户端都支持。

这就引出了几条务实的安全建议：

• 不要把一个拥有租户管理员账户的智能体直接指向生产环境然后听天由命
• 使用最小权限身份（least-privilege identity）
• 保持客户端的审批设置开启
• 在变更执行前审查工具调用

还有一个容易被忽视的合规问题：客户端和模型可能会在Fabric的合规边界之外、按照它们自己的条款处理数据。如果这对你的组织是个问题，那瓶颈不在服务器，而在客户端。

"最小权限原则"（Principle of Least Privilege）是信息安全领域的基础原则，要求任何身份只被授予完成其任务所必需的最低权限。在 AI 智能体场景中，这一原则尤为重要：由于智能体可以自主链式调用多个工具，一个高权限身份一旦被错误指令触发，可能在人类察觉之前完成一系列不可逆操作（如批量删除工作区或重新分配角色）。因此，为智能体专门创建一个权限受限的服务主体（Service Principal），而非复用管理员账户，是在生产环境中使用任何 MCP 服务器的基本卫生习惯。

可用状态与接入要求

Fabric Core MCP Server目前已正式发布（Generally Available）。

要接入它，你需要满足以下条件：

• 一个支持streamable HTTP和Entra ID登录的MCP主机（官方推荐 VS Code + GitHub Copilot）
• 至少拥有一个工作区的访问权限

关于价格，Learn文档没有单独列出该服务器本身的费用。此外，面向本地开发还有一个本地版Fabric MCP服务器，但需要注意：本地服务器本身不会生成Fabric审计日志，只有底层的Fabric服务才可能记录其操作。这是本地版与托管版之间一个关键的差异。

由于智能体会继承工作区角色，在正式使用前，建议先理清Fabric工作区的角色权限模型——权限边界的理解，才是安全使用这个工具的真正前提。