Microsoft Fabric Data Agent Security: What Actually Protects Your Data?

Co-Authors – Praful Potphode& Natarajan Manivasagan

Most Microsoft Fabric Data Agent demos begin the same way. Connect a semantic model, Lakehouse, or Warehouse. Add some instructions. Ask a natural-language question. Get an answer.

That is the exciting part! But the moment we move from a demo to a real enterprise implementation, the questions change.

1. Whose identity is actually querying the data?
2. Does sharing the Data Agent also share the underlying data?
3. Can the agent bypass RLS or CLS?
4. Does Object-Level Security still protect metadata?
5. What happens if the same data is reachable through multiple query paths?

These were some of the areas we wanted to understand while working through our Fabric Data Agent POC.

The most important principle that came out of it was surprisingly simple:

The Fabric Data Agent should not be your security layer. Your data platform should be.

Press enter or click to view image in full size

Fig. Data Agent & Its Security

That one principle makes the rest of the architecture much easier to reason about.

A Data Agent Does Not Get Unlimited Access to Fabric

When someone uses a Fabric Data Agent directly in Fabric, the interaction normally runs in the context of the authenticated Microsoft Entra ID user.

Fabric manages the underlying Azure OpenAI service. Users don’t need to supply an OpenAI API key, and the Data Agent doesn’t suddenly receive unrestricted access to every table in the workspace.

When the agent needs data, it generates the appropriate SQL, DAX, or KQL and queries the underlying source using the permissions available to the calling identity.

Press enter or click to view image in full size

Fig. Security Path

The important part is the middle. The agent generates the query.

The data platform decides whether that query can return the requested data.

That is exactly where enterprise security should live.

Sharing a Data Agent Does Not Mean Sharing the Data

This is one of the first things worth understanding. There are effectively two authorization checks:

Press enter or click to view image in full size

Fig. Two Authorization Checks

In that situation, Fabric doesn’t magically elevate that user’s access just because the Data Agent has been shared with them. Users still need the applicable permissions on the underlying source. Queries that touch data they cannot access can fail authorization or return no data depending on the source and its security model.

That separation is extremely important for enterprise deployments.

It allows us to distribute a common analytical assistant while still preserving different data entitlements for Finance, Sales, Operations or regional teams.

Semantic Models Have an Interesting Permission Model

Power BI semantic models are especially interesting.

For Data Agent interaction, Microsoft documents that a consumer can query the semantic model with Read permission.

They don’t need:

Workspace Member
Workspace Contributor
Build permission
Write permission

simply to ask questions through the Data Agent.
Build or Write permissions remain relevant when someone needs to modify the model or use capabilities that change its AI configuration, such as Prep for AI.

From a least-privilege perspective, this is a very useful improvement.

Instead of granting broad workspace or semantic-model permissions simply because somebody needs conversational analytics, we can grant the narrower access required for consumption.

What Happens to RLS and CLS?

This is probably the security question I hear most often around conversational analytics.

“If the AI generates the query, can it somehow bypass RLS?”

For supported Data Agent interactions, Microsoft explicitly documents that existing user permissions continue to apply, including Row-Level Security and Column-Level Security.

Press enter or click to view image in full size

Fig. RLS — One Agent Three Users

All three users can potentially use the same published Data Agent. But the semantic model can return different populations because the security context belongs to the user.

The agent doesn’t need instructions such as:

If User = John, only show Europe.

In fact, that would be the wrong way to implement security. The model should enforce the rule. The Data Agent should operate inside it.

What About OLS?

We also tested Object-Level Security (OLS) rather than assuming how Data Agent would behave.

For our model, we applied OLS to Customer[Company Name] the Power BI semantic model and tested the Data Agent using the restricted identity.

We then asked:

Show Total Sales by Company Name.

Press enter or click to view image in full size

Fig. Data Agent does not expose the OLS-protected Company Name field.

The Data Agent responded that the model does not contain a Company Name field and suggested Customer Name instead.

Press enter or click to view image in full size

Fig. Run Steps show the semantic model was analyzed, but the protected field was unavailable to the agent.

That was the key result.

Company Name still physically exists in the semantic model, but for the OLS-restricted user the Data Agent behaved as though the field did not exist. This indicates that, in our tested semantic-model path, OLS protected not only the data but also the object's metadata.

Our test confirmed OLS enforcement for the tested Fabric Data Agent → Power BI semantic model path, including metadata hiding.

This remains query-path specific. If the same data is also exposed through a Lakehouse, Warehouse, or another source, that route needs its own security controls.

Press enter or click to view image in full size

Fig. OLS security

There is still an important qualification.

That OLS rule protects the semantic-model path. If the same underlying data is separately exposed through a Lakehouse, Warehouse, SQL endpoint, or another source, that route requires its own security controls.

Security Is Specific to the Query Path

This is one of the broader lessons from our POC.

Imagine the same business data can be reached through:

Power BI Semantic Model
        │
        └── RLS / CLS / OLS

Lakehouse
        │
        └── OneLake / item security

Warehouse
        │
        └── SQL / OneLake permissions

Securing one route doesn’t automatically prove that all other routes are equally secure.

For example, the semantic model could correctly restrict a user’s data through RLS or OLS while the same user has broader access to the underlying Lakehouse.

If both are available to the Data Agent, the overall architecture may still be over-permissioned.

So the enterprise question isn’t simply:

Does my semantic model have RLS?

It is:

Is every query path available to this Data Agent secured for this identity?

That is the more useful security question.

Press enter or click to view image in full size

Fig. Security Is Specific to the Query Path

AI Instructions Are Not Security Policies

Consider an instruction like:

Never display employee salary information.

That may be useful behavioral guidance. But it is not an authorization boundary.
A user could phrase the question differently. The orchestration could change. A future runtime could interpret an instruction differently. The instruction could accidentally be edited or removed. The secure implementation is:

Press enter or click to view image in full size

Fig. AI Instructions Are Not Security Policies

The distinction is simple:

Instructions determine how the agent should behave. Permissions determine what the agent is allowed to see.

Never reverse those responsibilities.

Reduce the Agent’s Data Surface

Security isn’t only about identity. It is also about how much data we expose to the agent in the first place.

When configuring a Data Agent, creators select relevant sources, tables, and schema context.

For an enterprise Finance Data Agent, exposing:

Dim Date
Dim Account
Dim Cost Center
Fact Actuals
Fact Forecast

is usually better than exposing hundreds of unrelated HR, customer, and operational tables.

That helps in two ways. First, it reduces unnecessary exposure.

Second, it improves query generation because the agent has fewer irrelevant paths to reason through. But schema selection still isn’t authorization.

Press enter or click to view image in full size

FIg. Three Boundaries

Data Agent Querying Is Read-Oriented — But There Is an Important Nuance

The normal Data Agent source-query path is designed for analytical retrieval.

Its SQL, DAX, and KQL tools retrieve and analyze data rather than modify the underlying source.

So a prompt such as:

Delete all customers with zero revenue.

doesn’t turn the Data Agent into a transactional database administrator.

That lowers the risk significantly compared with giving an autonomous agent unrestricted write-capable database tools.

But there is an important nuance.

Code Interpreter Changes the Execution Surface

Fabric Data Agent can optionally use Code Interpreter, currently a Preview capability.

This allows the agent to generate and execute Python in a Microsoft-managed sandbox for tasks such as:

Statistics
Advanced calculations
Data transformation
Visualization
Analytical processing

That does not suddenly make the underlying source write-enabled. A better way to think about it is:

Underlying Source
       │
       │ Governed read
       ▼
Fabric Data Agent
       │
       ▼
Sandboxed Python
       │
       ▼
Calculated / visualized result

Press enter or click to view image in full size

Fig. Code Interpreter Surface

So:

Source querying remains governed and read-oriented, while Code Interpreter adds an additional analytical execution environment.

That additional execution surface should be reviewed deliberately, especially when Preview capabilities are being considered for sensitive production workloads.

What We Took Away From the Security POC

The cleanest security model for us became:

IDENTITY
Microsoft Entra ID
        ↓
AUTHORIZATION
Fabric item + source permissions
        ↓
DATA SECURITY
RLS / CLS / OLS / OneLake / SQL
        ↓
QUERY-PATH SECURITY
Validate each available source
        ↓
AI SCOPE
Selected schema
        ↓
FABRIC DATA AGENT

The Data Agent sits on top of the security architecture. It should not replace it.

That is the difference between building an impressive AI demo and building an enterprise analytical agent.

Security Is Only the First Layer

Once we were satisfied with the basic security model, another set of questions appeared.

Who can modify the agent?
Which runtime should production use?
How do we test changes?
What happens with Code Interpreter?
How should service principals be handled?
Where is conversation history stored?
What happens when the agent is used from Copilot Studio, Foundry, MCP, or a custom application?
Those are no longer just security questions.

They are governance questions. And that is where Part 2 begins.

Press enter or click to view image in full size

Fig. Security Architecture

Next: Part 2 — Microsoft Fabric Data Agent Governance: From POC to Production

Part 2 will focus on how a production Data Agent should be changed, tested, released, consumed, and governed — including identity models, lifecycle management, evaluation, privacy, data residency, networking, and external consumption.

The central idea remains the same:

Do not make the AI responsible for protecting the data. Make the data platform responsible for protecting the data, and make the AI operate inside those boundaries.