Outbound Access Protection for semantic models (Preview)

Outbound Access Protection (OAP) is a workspace-level network security and governance feature that blocks outbound traffic from a workspace by default and lets you allow only the destinations you explicitly trust. With this preview, you can now extend OAP to semantic models. Power BI reports aren't part of this preview yet; report support is coming in a separate announcement soon.

Outbound data movement from semantic models

Semantic model connections can cross workspace boundaries and can pull data from cloud and on-premises sources, including destinations that fall outside your organization's data boundary. Composite semantic models (models combining tables from multiple sources) can also send data from one source to another, when pushing filter values to a table in DirectQuery mode, as depicted in the diagram example.

The relationship between Table A and Table B might have been created unintentionally. The query does not have to return meaningful results. The point is that values from source A might be exposed to source B in certain situations. This means that sensitive filter values might show up in the wrong query logs!

Figure: User selects a value from source A in a slicer and source B runs a query with the filter value in the Where clause.

Security controls at the data gateway and network layers help, but they don't stop a model creator from binding a connection to an unsanctioned endpoint in the Power BI service. You need a policy in the service that controls outbound connections across workspace boundaries.

How OAP works for semantic models

OAP is a single toggle on the workspace. Open Workspace settings, select Network security, and turn on Block outbound public access. Once enabled, every outbound connection from items in that workspace is denied unless you create an explicit exception.

Figure: Workspace settings for outbound access protection.

For semantic models, enforcement happens on the model's bound data connection. That means Power Query transformations, M expressions, and dataset parameters can't route around the policy — the connection itself is evaluated against the workspace's outbound rules before any data moves. Import refreshes and DirectQuery queries follow the same path.

Prefer automation? The same policy is exposed through the Fabric REST API. Refer to Workspaces - Set Network Communication Policy REST API and set outbound.publicAccessRules.defaultAction to Deny. Toggle changes take about 15 minutes to propagate.

Intra-workspace connections

It’s important to note that the default OAP configuration blocks all data connections perceived as cross-workspace. This includes any sources accessed through SQL, ADLS Gen2, and other non-Fabric connection kinds. Your source lakehouse might be in the same workspace as your semantic model, but your semantic model will not be able to connect unless you allow the local workspace for the SQL connection kind (for import and DirectQuery mode) and the ADLS Gen2 connection kind (for Direct Lake mode).

Select Add new cloud connection rule, select SQL Server or Azure Data Lake Storage Gen2, and then specify the fully qualified domain name of the source’s SQL analytics endpoint or the URL of the workspace in OneLake. The following screenshot shows the corresponding exceptions with placeholder values. 

Figure: Exceptions for SQL and ADLS Gen2 data connections.

You can discover the FQDN from the lakehouse settings. On the SQL endpoint tab, the FQDN appears under SQL connection string, as in the next screenshot.

 

Figure: FQDN in the SQL Analytics Endpoint settings.

For the ADLS Gen2 URL of a workspace in OneLake, look at the URL of a Delta table. For example, in the Table properties, copy the URL to the clipboard, and then remove the lakehouse and table specific parts that follow the first (workspace) GUID in the URL. For details about the URL syntax, refer to Connecting to Microsoft OneLake in the product documentation.

Figure: Getting the URL of a Delta table.

Getting started

Follow these steps to enable OAP to create a workspace that hosts semantic models:

1. Confirm the workspace is on an F SKU and that the tenant setting Configure workspace-level outbound network rules are on.
2. Plan the workspace. If you're adding OAP to an existing workspace, ensure that the workspace only contains items that support OAP. You cannot enable OAP if the workspace contains Power BI reports, dashboards, and other unsupported artifacts.
3. Open Workspace settings > Network security and turn on Block outbound public access.
4. Add a data connection exception for each destination, including the local workspace where the semantic model resides.
5. Wait about 15 minutes for the policy to propagate.
6. Validate by refreshing an Import model and by opening a report in another workspace that connects to a DirectQuery model in the OAP-protected workspace. Connections to allowed destinations succeed; for blocked destinations, note the error indicating that the connection is blocked by Outbound Access Protection policies.