AI agents make Fabric security easier to misunderstand because the conversational interface hides the query path. A user asks one question; the agent selects a source, generates a query, and returns an answer. Whether that answer is allowed depends on the user's identity, workspace and item access, the connected source, OneLake role membership, RLS and CLS, SQL access mode, semantic-model permissions, shortcuts, engine support, and Purview controls.
Datrick assesses the result as effective access, not as a list of configured roles. AI can accelerate entitlement inventory, policy comparison, query generation, test-case expansion, drift detection, and evidence classification. Deterministic expected results and negative persona tests remain the authority for security decisions.
Can you answer exactly what a Fabric Data Agent can reveal to each real user? Test the complete identity-to-answer path before broad rollout.
Inventory every path to the data
Start with sensitive business domains and the identities that consume them. Inventory tenant settings, capacities, domains, workspaces, roles, items, shares, OneLake security opt-in, data roles, virtual members, Entra groups, service principals, workspace identities, item owners, SQL permissions, semantic-model roles, shortcuts, external engines, Direct Lake models, Spark workloads, Data Agents, Foundry or Copilot integrations, and temporary access methods.
Map the path each persona uses. The same lakehouse table can produce different controls through OneLake file access, Spark, SQL analytics endpoint, Direct Lake, a semantic model, or a Data Agent. Record the effective identity, policy authority, supported security features, bypass conditions, and expected denial behavior for each path.
Resolve the effective security model before enabling preview controls
| Access layer | Control question | Common exposure |
|---|---|---|
| Workspace and item | Is the identity Admin, Member, Contributor, Viewer, or directly shared; which item permissions and reshare paths apply? | Elevated workspace roles bypass fine-grained OneLake filtering. |
| OneLake role | Which table, folder, Read or ReadWrite grant, explicit member, group, security principal, or virtual permission group applies? | DefaultReader or a broader overlapping role preserves full access. |
| RLS and CLS | Which filter and column list apply; are both defined in a supported role composition; does most-permissive access override restriction? | Multiple roles produce broader access or unsupported combinations and query errors. |
| SQL endpoint identity | Does user identity mode enforce OneLake roles, or does delegated identity mode enforce SQL permissions through the item owner? | Teams believe OneLake policy applies while the endpoint uses delegated SQL security. |
| Semantic model | Does Direct Lake use SSO or a fixed identity; which model RLS, OLS, source permission, and fallback behavior apply? | A fixed identity or duplicated policy creates a different effective perimeter. |
| Shortcuts and engines | Is identity passthrough or delegated; which source and target permissions, authorized-engine controls, and network protections apply? | A delegated shortcut breaks source permission flow or an unsupported engine is blocked. |
| AI agent | Which requesting user, connected source, minimum permission, generated query, RLS/CLS, DLP, and output policy governs the answer? | Sharing the agent without aligned source permissions creates errors, empty results, or unintended disclosure. |
OneLake security is currently documented as preview for supported items and integrations, is enabled per item, and cannot be disabled after opt-in. Do not use a production lakehouse as the first experiment. Reproduce representative data and identities in a controlled item, capture the current access baseline, plan migration and rollback at the workload level, and define a stop decision before enabling the feature.
Design roles for least privilege and predictable composition
Prefer Entra groups with accountable owners over individual grants. Separate data-consumer identities from item builders and administrators. Remove unnecessary Admin, Member, and Contributor roles from users whose access should be filtered. Review virtual membership such as ReadAll because it can include a broader population than the role name suggests.
Build mutually understandable roles around stable business access patterns. Test overlapping grants because the most permissive path can win. Define RLS and CLS in supported combinations, use stable identity attributes, and document how missing or malformed attributes behave. Treat ReadWrite as a separate risk with explicit write-path tests.
Test Fabric Data Agent as the requesting user
Microsoft documents that Fabric Data Agent uses the requesting user's credentials, honors source permissions, RLS and CLS, and applies supported Purview governance controls. It is read-only, but read-only access can still expose sensitive rows, columns, aggregates, identifiers, relationships, or derived facts. Share the agent and its underlying sources deliberately; users without required source permissions can receive authorization errors or empty results.
Create prohibited-question tests, not only allowed questions. Ask directly for restricted columns, infer them through grouping or filters, request small-cell aggregates, use synonyms, combine sources, prompt for another region or tenant, and repeat through every supported integration. Verify both the returned answer and the source query or authorization outcome.
Build a cross-engine effective-access test suite
| Test dimension | Representative cases | Required evidence |
|---|---|---|
| Personas | Admin, developer, analyst, Viewer, direct share, regional user, external guest, service principal, workspace identity, and application user. | Object ID, group closure, workspace and item access, role memberships, expected data, and prohibited data. |
| Engines | OneLake API, file explorer, Spark, SQL endpoint, Direct Lake, semantic model, Data Agent, shortcut, and authorized external engine. | Effective identity, policy source, query, result, denial, and engine-specific limitation. |
| Policy composition | Table/folder grants, RLS, CLS, RLS plus CLS, overlapping roles, DefaultReader, ReadAll, and elevated workspace roles. | Expected rows and columns matched to actual results and policy resolution. |
| Identity mode | User identity, delegated item-owner identity, fixed semantic-model identity, passthrough shortcut, and delegated shortcut. | Token subject or executor, enforced security plane, owner dependency, and negative test. |
| Agent questions | Allowed detail, prohibited detail, inference, aggregation, synonym, cross-source join, ambiguity, prompt injection, and missing permission. | Selected source, generated query, authorization outcome, answer, citation or explanation, and leakage score. |
| Change and drift | Group add/remove, role edit, workspace promotion, source change, endpoint-mode switch, new column, shortcut change, and agent-source update. | Propagation time, regression result, alert, approval, and rollback or remediation. |
Use deterministic fixtures with unique canary values in restricted rows and columns. A denial alone is not enough: confirm that schema, metadata, counts, error text, logs, and generated narratives do not reveal prohibited facts. Re-run the suite after every role, identity-mode, source, model, agent, engine, or workspace change.
Govern policy change and access evidence
Every role, group, source, shortcut, endpoint mode, item owner, or workspace-role change can alter effective access. Require an owner, reason, ticket, impact analysis, approval, test result, deployment record, and rollback. Monitor elevated-role growth, direct grants, stale groups, DefaultReader membership, policy errors, blocked queries, agent authorization failures, unusual sensitive queries, and preview-product changes.
Produce an access decision record for each sensitive domain: authoritative security plane, permitted personas, prohibited data, supported engines, expected identity, test suite, current exceptions, product limitations, and accountable owner. This gives security, data, and AI teams one verifiable contract.
Run a three-to-five-week security assessment
- Select sensitive domains, representative items, engines, AI agents, personas, business owners, and regulatory or contractual requirements.
- Inventory workspace, item, OneLake, SQL, semantic-model, shortcut, external-engine, Data Agent, Purview, and network controls.
- Map the effective identity and security authority for each access path, then identify bypasses, conflicting roles, owner dependencies, and preview boundaries.
- Build deterministic allowed and prohibited datasets, expected rows and columns, canary values, persona fixtures, and cross-engine queries.
- Execute positive and negative effective-access tests through Spark, SQL, Direct Lake, semantic models, shortcuts, APIs, and Data Agents in scope.
- Prioritize exposure, remove unnecessary elevation, redesign roles and groups, align identity modes, and define a controlled OneLake security pilot where justified.
- Deliver the access graph, finding register, evidence pack, target model, remediation backlog, regression suite, monitoring requirements, and go/hold/stop recommendation.
Frequently asked questions
What is OneLake security in Microsoft Fabric?
OneLake security is a fine-grained access-control model for supported OneLake items. Roles can grant table or folder access and can include row-level and column-level restrictions. Supported Fabric engines evaluate the requesting identity and enforce the policies at query time. The capability and individual integrations have documented preview scopes and limitations that must be checked before production use.
Is OneLake security generally available?
Microsoft currently documents OneLake security roles, RLS, CLS, and several integrations as preview for supported item and engine combinations. It is enabled per item and Microsoft states that the preview cannot be turned off after enablement. Validate current support for the exact item, engine, region, identity, policy type, and workload before opting in.
Does Fabric Data Agent enforce OneLake security, RLS, and CLS?
Microsoft documents that Fabric Data Agent uses the requesting user's credentials, honors underlying source permissions, and applies supported RLS and CLS controls. Users also need the minimum permission on each connected source. Test each real persona, source, query path, and prohibited question because effective behavior depends on the source type and configured security model.
Do Microsoft Fabric workspace roles bypass OneLake RLS and CLS?
Microsoft documents that workspace Admin, Member, and Contributor roles have elevated access and aren't restricted by OneLake RLS or CLS in supported scenarios. Fine-grained filtering is intended for Viewer or read-only shared users. An assessment should remove unnecessary elevated roles and test effective access rather than infer it from role names alone.
How long does a OneLake security and AI agent access assessment take?
A focused assessment can often be completed in three to five weeks for a bounded set of lakehouses, engines, agents, roles, and personas. The work includes inventory, effective-access mapping, policy and identity-mode review, negative testing, remediation design, and a controlled pilot plan. Larger estates or migrations from multiple overlapping security models require more time.
Official implementation references
- Get started with OneLake security
- Create and manage OneLake security roles
- Column-level security in OneLake
- Spark support for OneLake RLS and CLS
- OneLake security for SQL analytics endpoints
- Fabric Data Agent sharing and permissions
Start with the sensitive domain that your first AI agent will query. Datrick can map effective access, execute negative tests, redesign the control model, and define a safe OneLake security pilot.