FabCon Atlanta 2026: three announcements that make agents in Fabric real

Most of the agent talk around Microsoft Fabric over the last year has carried a "preview" label. At FabCon 2026 in Atlanta, three pieces moved closer to production: the Fabric local MCP server and Fabric data agents are now generally available, and OneLake security will follow in the coming weeks.

There were a lot of announcements in Arun Ulag's keynote post. These are the three I think matter most for teams that want to put AI on top of their Fabric data without building a science project. Together they cover how agents connect, what they can answer, and what stops them from seeing too much.

1. Fabric MCP: local is GA, remote is in preview

Model Context Protocol (MCP) is the open standard that lets AI assistants call tools and read data in a consistent way. Microsoft announced two milestones for Fabric MCP.

The Fabric local MCP server is now generally available. It is an open-source server that runs on your own machine and connects AI coding assistants, such as GitHub Copilot, directly to Fabric. According to the documentation, it gives an agent:

• Offline access to Fabric API specs, item schemas and best practices.
• OneLake file operations, such as listing, uploading and downloading files and discovering table schemas.
• Core Fabric operations, such as creating lakehouses, notebooks and other items.
• Data Factory workflows, including pipelines and dataflows.

The documentation also makes a point worth repeating: running the server locally does not mean your model processes data locally. Your MCP client and model provider still see what the agent sees.

Alongside it, Fabric remote MCP is in public preview. This is a cloud-hosted service that lets agents and automation tools perform authenticated actions in Fabric, with nothing to install. Preview means I would test it, not build on it.

2. Fabric data agents are generally available

Fabric data agents are Microsoft's configurable "ask your data" item. You point an agent at a set of sources, add instructions and example queries, and publish it so others can ask questions in plain English.

Under the hood, the agent picks the most relevant source and generates a query: SQL for lakehouses and warehouses, DAX for Power BI semantic models, and KQL for KQL databases. A few details from the documentation are important before you promise anything to the business:

• The agent only generates read queries. It does not create, update or delete data.
• It runs with the requesting user's credentials and permissions, and row-level and column-level security on semantic models still apply.
• You need a paid F2 or higher Fabric capacity, or Power BI Premium P1 or higher with Fabric enabled.
• An agent can use up to five data sources.
• Questions, instructions and example queries work best in English.
• An agent cannot query a source whose workspace capacity is in a different region than the agent's own capacity.

Microsoft also positions data agents as building blocks that can be used from Microsoft Foundry, Copilot Studio and Microsoft 365 Copilot. That is the interesting part for me. A well-scoped agent over a good semantic model can be reused in several places instead of being rebuilt in each tool.

3. OneLake security: the guardrail that makes the rest safe

The third piece is less flashy, and it is the one I would watch most closely. Microsoft says OneLake security will be generally available in the coming weeks. It lets data owners define roles, enforce row-level and column-level controls, and manage permissions through one model that follows the data.

Why does this belong in a post about agents? Because every agent above runs as a user. If your permissions are scattered across workspaces, SQL endpoints and semantic models, an agent will faithfully expose every gap. A single security model in OneLake is what lets you say yes to agents with a straight face.

In the same post, Microsoft also announced that Direct Lake on OneLake is generally available. Tables are read directly from OneLake with native security enforcement and no import refresh. For Power BI teams, that is the semantic model side of the same story: fewer copies, and security that travels with the data.

What this means for you

GA does not mean "turn it on for everyone tomorrow". It means support, stability and a reasonable basis for a real pilot. Here is how I would approach it:

1. Pick one well-modelled Power BI semantic model that people already trust. Data agents are only as good as the model underneath.
2. Build one data agent on it, with clear instructions and a short list of tables. Keep the first scope narrow.
3. Test it with users who have different permission levels, and confirm that RLS behaves as you expect.
4. Check where your capacities are. The cross-region limit can surprise you if your data and agents sit on different capacities.
5. Give your developers the local MCP server in VS Code and let them use it for API lookups and OneLake work in a dev workspace first.
6. Start mapping your current permissions now, so you are ready to move to OneLake security when it reaches GA.

The order matters. Security and modelling first, agents second. After two decades in data, I have seen many "self-service" waves fail because the foundation was not ready, not because the tool was weak.

Takeaway

FabCon 2026 is the point where agents in Fabric stop being a demo and become something you can plan around. Local MCP gives developers a supported way in, data agents give business users a supported way to ask questions, and OneLake security is the piece that keeps both honest.

Which of your semantic models would you trust enough to put a data agent on top of it today?

Sources

• FabCon and SQLCon 2026: Unifying databases and Fabric on a single data platform (Microsoft Azure blog)
• Fabric MCP Server (local) overview (Microsoft Learn)
• Fabric data agent concepts (Microsoft Learn)