The Challenge: Where Can Your Streaming Data Go?

You've built a real-time streaming pipeline in Microsoft Fabric. Events flow from Azure Event Hubs into Eventstream, get filtered and shaped, then land in an Eventhouse for real-time analytics and a Lakehouse for historical analysis.

It works. But there is an important question: "Can that streaming data only flow to destinations that you have approved?"

In a real-time system, data is continuously moving between services and workspaces. A misconfigured pipeline could unintentionally route financial transactions, patient telemetry, customer events, or other sensitive data to an unauthorized workspace or external service. For organizations handling sensitive or business-critical data, that isn't an acceptable risk.

Workspace Outbound Access Protection (OAP) addresses this by giving workspace admins control over outbound connectivity. By default, outbound connections are blocked until they're explicitly approved through data connection rules, helping ensure that streaming data flows only where it's intended.

This post explains what OAP means for Fabric Eventstream, how it affects sources and destinations, and what to consider when designing workspaces in a secured environment. For details, refer to Workspace Outbound Access Protection (OAP) for Real-Time Intelligence (Preview).

How OAP works: The core model

OAP is a workspace-level security control. The workspace boundary becomes the outbound security perimeter: nothing leaves this workspace without explicit admin approval. At a high-level, an admin has to:

1. Enable OAP on a workspace to block all outbound connections to external endpoints including other workspaces.
2. Add exceptions via data connection rules to approve specific connectors, endpoints, or destination workspaces.

For Eventstreams and all Real-Time Intelligence items, workspace admins manage exceptions through data connection rules, defining which connectors and endpoints are permitted.

OAP separates data processing from data movement. Eventstream can still ingest, transform, filter, aggregate, and route events exactly as before. What changes is that every outbound connection the eventstream initiates is evaluated against a workspace-level policy. This gives administrators a single place to govern outbound connectivity across all supported Real-Time Intelligence items instead of configuring separate security policies for each individual item. As new Eventstreams are created in the workspace, they automatically inherit the same outbound access policy.

Important: OAP governs outbound connections initiated by Fabric items. It complements, but does not replace, identity controls, workspace permissions, or private networking etc.

For the full Fabric-level OAP story, refer to the Workspace Outbound Access Protection overview.

What OAP means for Eventstream sources, processing and destinations

A typical Eventstream pipeline consists of three stages: ingesting events from sources, processing them within the stream, and delivering results to destinations. The diagram below illustrates this flow.

Figure: OAP evaluation across Eventstream stages

OAP affects each stage differently because only the source and destination stages establish outbound connections from the workspace. Stream processing runs entirely within the workspace and is unaffected.

Sources: Eventstream establishes outbound connections to ingest data from external sources such as Azure Event Hubs, Kafka, MQTT brokers, and database CDC endpoints. OAP evaluates these connections before data can begin flowing, allowing organizations to selectively permit trusted sources.

Stream processing: Eventstream operators, including ManageFields, Filter, Aggregate, Group By, and Union, execute entirely within the workspace. Because no outbound connections are involved, OAP has no effect on this stage.

Destinations: Destination behavior depends on whether the data crosses the workspace boundary. Writing to supported Fabric items in the same workspace requires no additional evaluation, while connections to another workspace or external endpoint are evaluated by OAP.

The following diagram illustrates how these connectivity patterns map to OAP decisions:

Figure: Eventstream OAP Connectivity Patterns

The diagram highlights the core OAP decision model: source connections and cross-workspace or external destinations require explicit approval, while same-workspace destinations are allowed automatically.

The distinction between same-workspace and cross-workspace destinations is intentional. OAP treats the workspace as its unit of trust. Communication between supported Fabric items within the same workspace stays inside that boundary and doesn't require additional approval. Connections that cross into another workspace or leave Fabric must satisfy the workspace's outbound access policy. This model lets organizations choose the workspace architecture that best fits their operational and governance requirements while applying a consistent security model.

What this means for workspace design

Self-contained workspace. If your Eventstream and all its Fabric destinations live in the same workspace, you only need rules for external sources. Co-located destinations work automatically. This is the simplest path to OAP.

Separated workspaces (hub-and-spoke). In larger enterprises, teams split workspaces by function: ingestion, analytics, and compliance. Each cross-workspace destination requires its own data connection rule. The rule count grows, but so does the granularity of control. An ingestion workspace admin can approve connections to the analytics workspace without granting access to anything else in the organization.

The hub-and-spoke model can be especially useful in regulated industries, where separate workspaces provide distinct audit boundaries, independent access control, and clearer ownership. Neither workspace model is universally better: smaller teams that own an entire streaming solution may prefer a self-contained workspace with fewer outbound rules, while larger organizations may accept additional rule management in exchange for independent lifecycle management, and stronger separation across operational, analytical, and compliance workloads. OAP works with either model, enabling organizations to govern data movement between workspaces with the same explicit authorization model used for external endpoints.

Putting it all together

A mid-size insurance company processes auto and property claims in real time. They've separated their workspaces for three reasons common in regulated industries:

• Regulatory audit boundaries: their state insurance regulator requires that claims processing systems be isolated from analytics systems, with documented data flows between them.
• Team ownership: the claims operations team, the actuarial analytics team, and the compliance/fraud team each manage their own workspace with independent access controls.
• Least-privilege access: adjusters who work in the claims dashboard should not have access to the actuarial data lake, and vice versa.

Their architecture:

• Claims events flow from a third-party claims management system via Azure Event Hubs
• Eventstream in the Claims Processing workspace enriches and filters events (removing low-priority status updates, normalizing fields)
• Eventhouse in the same workspace powers a real-time claims dashboard for adjusters
• Lakehouse in a separate ClaimsDataLake workspace stores all claims for actuarial analysis and regulatory reporting
• Lakehouse in a Compliance Audit workspace captures a filtered stream of high-value claims (>$100K) for the fraud review team

With OAP enabled on the Claims Processing workspace:

Figure: Secure Claims Processing with OAP

The result: claims data can only reach the three approved destinations. A misconfigured route or an unauthorized workspace is blocked by default. If a well-meaning analyst tries to route claims events to a personal workspace for ad-hoc analysis, the connection is denied and the attempt is logged. When the state regulator asks, "Where can claims data go?", the compliance team has a definitive answer: only to these three endpoints, and nowhere else.

In this example, configuring OAP requires only three rules. The Claims Processing workspace needs one endpoint rule permitting outbound connections to Azure Event Hubs and two workspace rules allowing connections to the Data Lake and Compliance workspaces. No rule is required for the local Eventhouse because it remains inside the workspace boundary. If the organization later adds a new analytics workspace or integrates with another external service, the connection won't succeed until an administrator explicitly approves it through a new data connection rule.

This is the core value of OAP for streaming workloads. With OAP enabled, the question shifts from "Are we sure nothing is leaking?" to "Here are the three approved paths, and here's the proof."

Get started today

Prerequisites:

• Fabric capacity (F SKU, the paid capacity tier). OAP is not available on trial or other capacity types.
• The tenant admin must enable the "Configure workspace-level outbound network rules" setting.

Steps:

1. Enable OAP on your workspace.
2. Configure data connection rules for each external source endpoint and each cross-workspace destination.
3. Verify that your Eventstream resumes normal operation with the rules in place.

Key things to remember:

• OAP is workspace-level. All items in the workspace share the same policy.
• Plan your rules before enabling OAP. Inventory every external source and cross-workspace destination your Eventstream connects to.
• The OAP setting can take up to 15 minutes to take effect.
• Current limitation: Cross-workspace Eventhouse and Activator destinations aren't yet supported with OAP-enabled Eventstreams. For now, place these items in the same workspace as your Eventstream, or plan for this capability in a future update.

We'd love your feedback!

If you find this blog helpful, please give it a thumbs-up! Have ideas for what you'd like to see next? Drop us a comment or reach out to [email protected] — we'd love to hear what real-time scenarios you're building and what topics you'd like us to cover in future posts.

Have new feature ideas? Submit them at Fabric Ideas - Microsoft Fabric Community.