Giving AI Agents Secure Access to OneLake: Table Read API, Delegated Shortcuts and Policies

In Short: A Governed Read Path for Agents

The OneLake Table Read API, announced at FabCon Europe 2026 and now in public preview, gives AI agents and applications a direct way to read rows from Delta Lake and Apache Iceberg tables in OneLake. No SQL endpoint, no Spark session. The rows come back as Apache Arrow streams, and OneLake security is enforced for whoever is calling: table access, row-level security and column-level security.

That fills a real gap. Until now, an agent that needed raw rows from a lakehouse usually went through a SQL endpoint or a service account with broad access. Now the agent can read under its own identity, and the storage layer does the filtering. Pair it with delegated shortcuts and outbound access protection, and you have the building blocks for letting agents into OneLake without handing them the keys.

How the OneLake Table Read API Works

Microsoft's Learn documentation describes a two-step pattern:

• Start a read session: send an authenticated POST to the table's read route, which is built from the workspace ID, item ID, schema name and table name. Use the columns option to request only what you need
• Collect the streams: the response returns one or more stream identifiers, depending on how much data there is. Send a GET for each one and read the body with an Apache Arrow IPC stream reader. Streams can be downloaded in parallel

Three details matter in practice. Every stream comes from the same snapshot, so the result is consistent even if the table changes mid-read. A read session expires after 60 minutes, so retrieve every stream before then or you will get an incomplete result. And row order is not guaranteed, either within the result or by stream position.

Authentication uses Microsoft Entra ID, either a user or a service principal, with tokens for the Azure Storage audience, which is the same audience the OneLake filesystem endpoints accept. The table must be a valid Delta Lake or Iceberg table. Microsoft lists one limitation: the API does not support cross-region shortcuts.

How Security Is Enforced

The Table Read API applies OneLake security using the identity in the bearer token. Microsoft documents the behaviour precisely:

• No permission on the table: the service returns not-found
• RLS filters out every row: the request succeeds with an empty Arrow response
• Wildcard column request: you get only the columns CLS allows
• An explicitly requested column you cannot see: not-found

Because unauthorised tables and columns return not-found, Microsoft warns against using not-found to test whether something exists. It also means the agent cannot tell the difference between "missing" and "forbidden", which is what you want.

The design lesson: give each agent its own identity, grant that identity a OneLake security role scoped to the tables it needs, and let RLS and CLS do the rest. Do not reuse a broad engineering service principal. If your RLS currently lives only in the semantic model, it does nothing here. This is the classic gap we describe in the Microsoft Fabric security model, and agents find it faster than people do.

What It Costs

From Microsoft's OneLake consumption page:

• 8 CU seconds per million rows scanned, charged on the POST read call and rounded up to the nearest million. Retrieving the streams is not billed separately
• It measures rows scanned, not returned, so a narrow RLS filter on a large table still pays for the scan
• To return RLS-filtered results, the API materialises data in a hidden OneLake location. You pay for that storage, and it is kept for seven days

Microsoft says calls are billed to the calling user. For agents that read the same large table repeatedly, that adds up quickly. Our explainer on how Fabric measures usage covers smoothing and throttling. Filter early, request only the columns you need, and point agents at curated gold tables rather than raw history.

Delegated Shortcuts: Whose Identity Reaches the Data

OneLake shortcuts have two authentication models. Passthrough, the default for same-tenant OneLake shortcuts, sends the caller's identity to the target. Delegated uses a configured connection identity, an organisational account or service principal, instead. Microsoft introduced delegated OneLake shortcuts on the Fabric Updates blog as a preview, so check the current status before relying on them. Cross-tenant OneLake shortcuts and external shortcuts, such as Amazon S3, always use delegated authentication.

With a delegated shortcut, the caller sees the intersection of their own OneLake security on the shortcut and the delegated identity's access at the target. CLS works on both sides. RLS can be set on the producer side only. You cannot switch a shortcut between passthrough and delegated: you delete it and create it again.

For agents, this is a useful pattern. A producing team grants one connection identity access to a curated set of tables. The consuming workspace then layers its own OneLake security roles on top for each agent identity. The producer never has to manage every downstream agent, and the consumer cannot exceed what the producer granted.

One exception to note: when shortcut data is read through Direct Lake over SQL or T-SQL engines in delegated identity mode, the engine uses the item owner's identity to reach the target, then applies OneLake security roles to filter what the caller sees.

Keeping Data From Leaving: Outbound Protection and Policies

Reading securely is half the problem. The other half is making sure an agent, or the person behind it, cannot move data somewhere it should not go.

• Outbound access protection for OneLake shortcuts is generally available, according to Microsoft's September 2026 feature summary. When it is on, outbound shortcuts and copy operations from the workspace are blocked by default, and approved destinations are added through a connector allowlist or managed private endpoints
• Policies in Fabric are in preview. The External Data Sharing policy controls who can share data externally, from which workspaces, for which sensitivity labels and to which recipient domains. If no rule matches, the action is denied. We cover the model in Policies in Fabric

Neither control is specific to agents, which is the point. Agents should sit inside the same perimeter as every other identity, not get special treatment.

Which Path Should Your Agent Use?

• Natural-language questions about a business area: a Fabric data agent, which can be added to Copilot Studio as a tool or called over MCP
• Rows from a known table, read by code: the Table Read API, under the agent's own identity
• Joins, aggregations and ad hoc analysis: the SQL analytics endpoint, as before
• Data owned by another team or tenant: a delegated shortcut, with consumer-side OneLake security per agent

Where Solv Systems Comes In

Letting agents into OneLake safely is mostly security design: one identity per agent, roles scoped to curated tables, RLS enforced in OneLake rather than only in the model, outbound protection on, and a cost check before anything runs on a schedule. Our Microsoft Fabric consultants set this up and test it with each agent's real identity before go-live.

Sources and Further Reading

• Read OneLake table data with the table read API (preview) - Microsoft Learn
• OneLake table APIs overview - Microsoft Learn
• OneLake compute and storage consumption - Microsoft Learn
• Secure and manage OneLake shortcuts - Microsoft Learn
• Outbound access protection and OneLake - Microsoft Learn
• Fabric September 2026 Feature Summary