My workspace governance improvements (Generally Available)
My workspace governance features, which give administrators governance controls over their users' personal My workspaces, are now generally available. As My workspaces continue to be used for business-critical content, organizations need governance capabilities that scale with their environment. These enhancements give administrators greater flexibility to access, manage, and recover content when needed, while enabling automation that reduces operational overhead and improves consistency across the tenant. These enhanced tenant administrator controls for My workspace are also available in government clouds. What's new Two new admin REST APIs make temporary admin access to a personal workspace fully programmable: Grant Admin Temporary Access: grants a Fabric administrator 24-hour access to a user's My workspace. Remove Admin Temporary Access: revokes that access before the 24-hour window ends. Both can be called by a Fabric administrator or by a service principal. The service principal identity must be enabled for Admin API access in your tenant settings. SPN support and these new APIs allow tenant administrators to automate management of tenant users’ My workspaces contents instead of doing it by hand in the Admin Portal. Reminder: Restoring orphaned My workspaces When a user is hard deleted in Microsoft Entra, their My workspace becomes orphaned and moves to a Deleted state, with contents retained for 30 days. During that window, you can restore it with the Restore Workspace API. Important: new workspace name is required when restoring a former My workspace, and you assign a new admin to own the recovered content. Try the Admin controls and new APIs and let us know what you think in the comment section.
Fabric Policies: Granular governance at scale (Preview)
As Microsoft Fabric grows across teams, workspaces, and capacities, governance becomes harder to manage with broad tenant-wide switches alone because governance models are not one-size-fits-all. Fabric Policies provide granular controls that can fit your governance model by defining what actions are allowed, to whom and where. The result is governance that scales with your Fabric estate. Teams keep the flexibility they need to work; capacity admins can protect the resources they manage, and central administrators gain consistent controls and visibility across the organization. Fabric Policies help organizations: Match controls to organizational boundaries - Apply organization-wide rules at tenant scope and resource-specific rules at capacity scope. Protect sensitive actions without slowing routine work - Keep approved self-service available while restricting higher-risk actions to the right users and context. Apply consistent guardrails at scale - Manage policies centrally through Policy Sets, Policies Center, auditing, and public APIs. What you can govern Fabric Policies currently provide controls for item creation, external data sharing (coming soon), and selected security-sensitive workspace settings. Control item creation by capacity Capacity admins can set a policy for any Fabric item type in workspaces assigned to their capacity (Power BI item creation is not yet enforced). An admin can allow the Data Engineering security group to create Dataflow Gen2 items in selected data platform workspaces and the AI Builders security group to create Data agent items in selected AI workspaces. Matching requests proceed; requests that do not match a complete Allow rule are blocked. This control supports a gradual Fabric rollout. Organizations can make specific item types available to approved teams and workspaces as their governance requirements are met, rather than enabling every item type everywhere at once. Item creation requires both controls to allow the request: the applicable Fabric item creation setting and the active Item creation policy. Figure: Advanced Item creation policy with separate Allow rules for Dataflow Gen2 and Data agent. Protect security-sensitive workspace settings Fabric admins can protect selected settings without removing broader workspace administration capabilities. An admin can allow the Central IT team to edit Outbound access protection, Inbound access protection, and Apply customer-managed keys (CMK) in sensitive workspaces. Other workspace admins can continue to edit the rest of the settings. The policy refines what existing workspace admins can change; it does not grant the Workspace Admin role. Govern external data sharing (Coming Soon) Fabric admins can support partner collaboration while controlling who can share, which workspaces the data comes from, its sensitivity label, and the recipient email domain. An admin can allow the Finance security group to share items labeled Confidential from Finance workspaces with recipients at CALDOVA.com. Sharing proceeds only when all configured conditions match; other requests are blocked. External sharing can be allowed by either the existing External data sharing tenant setting or a matching and active policy rule. How Policies work On Policy Set creation, an administrative scope is selected, such as the tenant or a capacity. This defines the available policy types and the administrator role required to activate the Policy Set for that scope. For each policy, administrators choose Allow all, Block all, or Advanced. Advanced policies use an allow-based model: All conditions within a rule must match. A match on any complete rule allows the action. If no rule matches, the action is blocked. Once the Policy Set is activated, Fabric evaluates its policies whenever a governed action occurs within that scope. Only one Policy Set can be active for a tenant or an individual capacity. Activating a replacement changes which definitions govern that scope. Existing access requirements remain in effect. Policies do not grant Fabric roles, workspace access, or item permissions. A user must first have the access required for the action; the policy then adds a governance decision for that action and context. Fabric Policies are available in preview for supported Fabric capacities and workspaces. Standard Fabric capacity and workspace requirements apply. Get started with Fabric Policies In Admin portal > Tenant settings, enable Policies (Preview). In a Fabric-capacity-backed workspace, create a Policy Set and choose Tenant or Capacity scope. Configure a policy with Allow all, Block all, or Advanced Allow rules, then review the users, actions, and workspaces covered. Activate the Policy Set as an administrator of the target scope. For capacity scope, select a capacity you administer. Review the related Fabric setting and policy together, then verify the active result in OneLake Catalog > Policies Center. For repeatable deployment across environments or capacities, use Fabric REST APIs to automate Policy Set and policy management at scale. API operations and activation remain subject to the required item permissions and administrator role. Policies best practices and management Design Advanced policies around every allowed scenario. List every user, item type, and workspace combination that must continue to work. Because Advanced policies are allow-based, a request is blocked when no complete rule matches. Align capacity policies with capacity ownership. Item creation policies govern workspaces assigned to the selected capacity. Each capacity can have its own active Policy Set, giving capacity admins control within their resource boundary. Review policy coverage whenever workspaces move between capacities. Use a dedicated management workspace. A Policy Set can be hosted in one supported Fabric-capacity-backed workspace and activated for a different capacity. A dedicated workspace can simplify access, ownership, and lifecycle management across multiple capacities. Separate editing from activation. People with Read, or the workspace Viewer role, can view a Policy Set. People with Read and Write, or a workspace Contributor, Member, or Admin role, can edit it. Activation still requires the administrator role for the target scope: Fabric admin for tenant scope or capacity admin for capacity scope. Validate before broad rollout. Start with representative users and workspaces and review each allowed scenario. Monitor and refine. Use Policies Center to review active policies and the Microsoft 365 Audit Log to follow Policy Set and rule lifecycle operations. Conclusion As Microsoft Fabric adoption scales across teams, workspaces, and capacities, governance must scale with it. Fabric Policies provide the flexibility to apply the right controls in the right contexts while maintaining a consistent governance model across the organization. By combining centralized oversight with granular policy enforcement, organizations can confidently expand their Fabric footprint without sacrificing security or control. Learn more about policies.
Customer-Managed Key (CMK) APIs for Microsoft Fabric Workspaces (Generally Available)
Microsoft Fabric encrypts all data at rest by default with Microsoft-managed keys. For organizations with strict compliance and regulatory requirements, Customer-Managed Keys (CMK) let you wrap that encryption with your own key stored in Azure Key Vault—giving you full ownership and control of the key protecting your data. The CMK REST APIs are now generally available —so you can enable, inspect, rotate, and turn off workspace encryption programmatically, and give tenant admins a tenant-wide view of encryption state, all without leaving your automation and governance pipelines. Previously, configuring CMK was a portal-only experience. That worked for a handful of workspaces, but it didn't scale to enabling encryption at provisioning time, rotating keys across many workspaces on a schedule, or auditing which key each workspace is using. With these APIs, CMK becomes a first-class, automation-friendly operation that fits naturally into existing workflows—scriptable, permission-gated, and auditable, so you can enforce and verify encryption posture at scale. What APIs are new? Four operations cover the full CMK lifecycle: apply or rotate a key, inspect current state, reset to Microsoft-managed keys, and govern at scale across the tenant. Assign a key — POST /v1/workspaces/{workspaceId}/encryption/assign Enable CMK on a workspace or update to a different key by supplying a keyIdentifier: { "keyIdentifier": "https://my-vault.vault.azure.net/keys/my-key" } Fabric workspace CMK feature uses version-less key URIs, so key rotation flows through the same operation. Get workspace encryption — GET /v1/workspaces/{workspaceId}/encryption Retrieve the current encryption configuration for a workspace: whether CMK is applied, the key identifier (Azure Key Vault key URI) in use, and the current status (for example, Enabled, EnableInProgress, or a failed state). Ideal for validation, auditing, and drift detection before taking action. Reset encryption — POST /v1/workspaces/{workspaceId}/encryption/reset Disable CMK on a workspace and return it to encryption with Microsoft-managed keys. Admin: List workspaces with encryption state — GET /v1/admin/workspaces?include=encryption The tenant admin API for governance at scale. Returns encryption details alongside each workspace, and can be filtered—for example, &encryptionStatus=EnableInProgress to find workspaces mid-enablement, or &capacityId={capacityId} to scope to a capacity. This gives tenant admins a single, tenant-wide view of which workspaces are CMK-protected and with which key. All APIs use standard Fabric authentication (Microsoft Entra) and honor existing workspace and tenant-admin permissions, so only authorized identities can view or change a workspace's encryption posture. Getting started Refer to the Customer-managed keys for Fabric workspaces documentation and API documentation to learn more. Assign Workspace Encryption Get Workspace Encryption Reset Workspace Encryption List Workspaces Have feedback? Your input helps shape the future of Fabric. Try out the new CMK APIs and let us know what works well and what you’d like to see next. Submit your ideas on Fabric Ideas and join the conversation on the Fabric Community. Happy coding!Connectivity patterns in Microsoft Fabric: A guide for data integration workloads
This blog post focuses on connectivity options for Microsoft Fabric workloads that use Data Factory runtime components, including Dataflow Gen2, Fabric Data Pipelines, Fabric Copy Job, Fabric Mirroring, Power BI semantic models, and Power BI paginated reports. The guidance and networking considerations described in this article apply to the above data integration scenarios of Fabric. Workloads such as Notebooks, Spark Job Definitions (SJD), and other Spark-based experiences are not covered by this guidance. These workloads use the Fabric Managed Virtual Network (Managed VNet) for data access and therefore follow a different connectivity model and network architecture. Enterprise data rarely lives in a single location. It is often distributed across public cloud services, Azure virtual networks, on-premises environments, and software-as-a-service applications. Microsoft Fabric must have a supported network path to each data source before workloads can access it. The appropriate connectivity option depends primarily on the source network location and whether Fabric must cross a private network boundary. This guide will help you determine when to use a VNet data gateway, an on-premises data gateway, or a direct cloud connection for data integration scenarios of Fabric. A simple way to choose the right option is to start with one question set: Where does the data source live, and does Fabric need to cross a private network boundary to reach it? Why gateway choice matters The connectivity model determines how Fabric reaches data sources and can affect security, governance, operational overhead, and network architecture decisions. Before users can build semantic models, pipelines, reports, notebooks, or analytical experiences, the platform needs a reliable way to reach the data. A gateway acts as an intermediary between a supported Fabric workload and a data source. It establishes the required connectivity path, relays supported queries or data requests and returns results to the calling service. The exact data movement and processing behavior depends on the Fabric workload, connector, connection mode, and gateway type. Gateways provide secure connectivity to private data sources through outbound-only communication and encrypted data transfer, eliminating the need to expose internal systems to the public internet. In Microsoft Fabric, that connectivity decision can affect how securely Fabric reaches the source, whether infrastructure needs to be deployed or maintained, whether the connection can be shared across teams, and how well the pattern fits enterprise governance requirements. Selecting the right connectivity pattern early can help prevent architecture changes later. For example, a source protected by private endpoints may require a different approach than a publicly accessible SaaS application, while an on-premises SQL Server deployment often has different requirements than a cloud-to-cloud integration scenario. Option 1: VNet data gateway Use a VNet data gateway when a supported data source is reachable from an Azure virtual network and is not intended to be accessed through a public endpoint. The source might use a private endpoint, reside in a connected virtual network, or be reachable from Azure through an appropriately configured private network path, such as ExpressRoute. VNet data gateway provides a Microsoft-managed connectivity option for supported data sources that are reachable through an Azure virtual network. Organizations can enable private connectivity without deploying or maintaining gateway virtual machines, making this a good option when you need private network access without managing additional infrastructure. When to use it The data source is reachable from an Azure virtual network. The scenario requires private connectivity, such as access through a private endpoint or an ExpressRoute-connected network. Fabric workloads that need secure and scalable access to data sources enabling Dataflow Gen2, Data Pipelines, Copy Job, Mirroring, Semantic Models, and Paginated Reports to access enterprise data Your organization prefers Microsoft-managed gateway rather than deploying and maintaining gateway virtual machines. The required Fabric workload, connector, authentication method, and region are supported. The Azure virtual network has the required network configuration and available capacity. Key benefits Microsoft-managed infrastructure: Microsoft operates the gateway infrastructure, reducing the need to deploy and maintain gateway virtual machines. Private network reachability: Supported Fabric workloads can connect to sources reachable from the Azure virtual network. Network isolation: Data sources can remain behind private network boundaries instead of requiring public endpoints. Hybrid reachability: Sources connected to the virtual network through supported network paths, including ExpressRoute, can be reachable without deploying the gateway directly in the on-premises environment. Capacity management: Supported scaling capabilities can help accommodate changing workload demands while reducing manual infrastructure management. Centralized connectivity: Administrators can configure and govern shared connections for supported workloads and users Option 2: On-premises Data Gateway, standard mode The on-premises data gateway is customer-managed software that runs on a supported machine in a network that can reach the data source. The gateway can be installed on an on-premises server or on a supported virtual machine, depending on the organization’s network design and operational requirements. Standard mode supports shared connectivity across approved users, connections, and workloads. Your organization is responsible for deploying, updating, monitoring, and maintaining the gateway host. When to use it The data source resides within an on-premises environment or a private network that is not directly accessible from Microsoft cloud services. You're able to provision and manage the required gateway infrastructure, including virtual machines, software updates, monitoring, and lifecycle maintenance. Multiple users or workloads need access, and the gateway should be centrally managed. You need enterprise-grade sharing and governance across Fabric, Power BI, Power Apps, Power Automate, Logic Apps, or Azure Analysis Services. Key Benefits Securely access on-premises and private-network data sources from Microsoft Fabric. Reuse existing network, firewall, and security investments without exposing data sources to the public internet. Centrally manage and govern connectivity for multiple users, teams, and workloads. Support hybrid and multi-cloud integration scenarios from a single gateway platform. Improve reliability and scalability through gateway clustering and high-availability deployments. Accelerate Fabric adoption by leveraging existing infrastructure and operational processes. Option 3: Cloud connection with no gateway Use a cloud connection with no gateway when the source is already cloud-based and publicly accessible. In this scenario, Fabric can connect directly to the service without traversing a private networking layer. Fabric can connect directly to the service using the supported connector and authentication method. This is often the simplest connectivity path. If the source is a public SaaS application, cloud API, or cloud data service that does not require access through a private network, then a gateway may not be needed. When to use it The source is fully cloud-based and publicly reachable. There is no private endpoint or private network boundary. Direct SaaS or cloud-to-cloud connectivity is supported. You do not need gateway infrastructure or runtime management. Common connectivity scenarios The following examples illustrate common Microsoft Fabric connectivity patterns and can help simplify gateway selection. Depending on the network architecture, some on-premises data sources may be reachable through either On-premises Data Gateway or VNet data gateway. Azure SQL Database with a private endpoint: If Azure SQL Database is accessible only through a private endpoint or a virtual network, use a VNet data gateway. This allows Fabric workloads to securely access the data source without requiring public network access. Azure Storage account secured through virtual network rules: When a storage account is protected by Azure virtual network restrictions and cannot be accessed through a public endpoint, a VNet data gateway is typically the appropriate choice. On-premises data sources connected to Azure through ExpressRoute: Organizations often use Azure ExpressRoute to extend their on-premises network into Azure. When a supported data source remains on-premises but is reachable from an Azure virtual network through ExpressRoute, a VNet data gateway can provide private connectivity from Fabric without requiring customer-managed gateway infrastructure. This can simplify operations while maintaining private connectivity between Microsoft Fabric and the data source. SQL Server hosted in an on-premises datacenter: If the data source resides within a corporate datacenter or private network and is not reachable from Azure virtual networks, use On-premises Data Gateway (standard mode) to provide shared, enterprise-grade connectivity. Line-of-business applications hosted behind a corporate firewall: Applications such as SAP HANA, Oracle, or other supported data sources that are accessible only from the corporate network generally require On-premises Data Gateway (standard mode). Cloud services with public endpoints: For supported cloud services such as Salesforce, Azure SQL Database (public endpoint), Azure Data Lake Storage Gen2 (public endpoint), or other publicly accessible SaaS and PaaS offerings, Fabric can often connect directly without requiring a gateway. Although these examples represent common deployment patterns, always verify connector support, authentication requirements, networking configuration, regional availability, and workload compatibility when designing your connectivity architecture. Final takeaway When planning Microsoft Fabric connectivity, start with the location of the data source and determine whether Fabric must traverse a private network boundary. That single decision typically determines whether a VNet data gateway, an On-premises Data Gateway, or a direct cloud connection is the appropriate choice. Use VNet data gateway when you need managed gateway to securely connect Microsoft Fabric workloads to data sources protected by Azure Virtual Networks, private endpoints, or on-premises environments that are connected to Azure through ExpressRoute. Use On-premises Data Gateway standard mode for self-hosted shared enterprise access to on-premises or private firewall sources. Use a cloud connection without a gateway when the supported cloud data source is reachable directly through its public endpoint and the scenario does not require a private network path. By using this decision flow, teams can design cleaner, more secure, and easier-to-manage connectivity patterns for Microsoft Fabric. Next steps Use the decision flow in this article to identify the connectivity model that best aligns with your data source location, network architecture, and operational requirements. Before implementation, review the supported workloads, connectors, authentication methods, and regional availability for your specific scenario. To learn more, explore: Microsoft Fabric documentation VNet data gateway documentation On-premises data gateway documentation Microsoft Fabric security documentation By selecting the appropriate connectivity option early in your architecture design, you can simplify deployment, improve security, and reduce ongoing operational overhead while enabling reliable access to enterprise data. For additional guidance, review the Microsoft Fabric connectivity and gateway documentation to confirm support for your workloads, connectors, authentication methods, and regions.Securing Outbound AI Connectivity in SQL Server 2025 (Generally Available)
AI is now part of the data layer SQL Server is evolving beyond a system that only stores and queries data. In SQL Server 2025, the engine can participate directly in AI-enabled workflows through governed integrations. Database-side workloads can connect to external AI services for scenarios such as retrieval-augmented generation (RAG), where model outputs are grounded in authorized, enterprise data context. This shift helps organizations reduce custom middleware and ad- hoc integration paths while keeping governance, security, and access control closer to the data platform. For example, a financial institution analyzing suspicious transaction patterns can execute approved outbound AI calls under database governance instead of exporting sensitive data through scattered application services. However, that shift creates a valid security question: when SQL Server can reach external AI endpoints, how do you maintain control—especially for outbound connectivity to external AI services? SQL Server 2025 addresses this by extending its existing defense-in-depth model. AI connectivity is not treated as an exception path; it is enforced within SQL Server’s existing trust and control model. Why this matters Many teams adopted AI by pushing sensitive data out of the database into application code or integration services. That approach often leads to three issues: Data moves more than necessary. Security policy becomes inconsistent and fragmented across systems. Audit trails are more challenging to correlate. SQL Server 2025 supports a more controlled operating model. AI integration can happen closer to the data, under database governance, while still enabling modern AI scenarios. This approach reduces unnecessary data movement while preserving existing application patterns. This benefits security, platform, and engineering teams by simplifying control and reducing fragmentation. Strong controls over external connectivity SQL Server 2025 supports outbound AI connectivity through features such as direct REST invocation and external model objects. Both rely on explicit SQL Server permissions and approved authentication, but the controls apply differently depending on the feature. External REST invocation uses sys.sp_invoke_external_rest_endpoint to call approved HTTPS endpoints from T-SQL. External model registration uses CREATE EXTERNAL MODEL to define model objects for embedding and vector search scenarios. The shared security idea is simple: define what can be used, grant only the required permissions, and authenticate access with approved credentials or identities. Enablement applies to REST invocation, which must be turned on before use. Permissions control who can enable REST calls, create or alter model objects, and execute approved operations. Authentication determines which credential, identity, or secret is used when SQL Server reaches an external service. For sys.sp_invoke_external_rest_endpoint, SQL Server provides a direct way to invoke HTTPS REST endpoints. The feature is disabled by default in SQL Server 2025 and must be enabled through sp_configure. Changing that setting requires ALTER SETTINGS server permission (implicitly held by sysadmin and serveradmin), which keeps enablement under administrative control. After REST invocation is enabled, runtime use still depends on permissions, endpoint policy, and credential handling, including EXECUTE ANY EXTERNAL ENDPOINT for callers. Organizations should grant invocation rights only to required principals, restrict allowed destinations, and require authenticated requests. Depending on the target service, authentication can use managed identity, certificates, API keys, or other supported mechanisms. For CREATE EXTERNAL MODEL, SQL Server creates a database object that stores the model endpoint, authentication method, and model purpose. Creating or changing that object requires CREATE EXTERNAL MODEL or ALTER ANY EXTERNAL MODEL, while using it requires EXECUTE on the model. This makes model access explicit without implying it uses the same enablement switch as REST invocation. The result is a clearer security boundary: REST calls require explicit enablement and controlled invocation, while external models require governed object creation and execution. In both cases, least privilege, approved authentication, and auditability remain central. High-privilege access is still the real security boundary AI features do not change the core rule of SQL Server security: the real boundary is who has permission to do what. When privileges are tightly scoped, features remain safe to adopt. That’s why least privilege matters. Users and applications should have only the permissions they need for their specific tasks. Nothing more. In practice, this means: Avoid broad administrative role membership wherever possible. Grant only the minimum permission required for the specific operation. Separate operational roles (configuration, model management, invocation). Review role assignments and grants on a defined cadence. Remove stale access quickly after ownership changes. Strong security is not about blocking capabilities. It is about controlling who can use them, when they can use them, and under what conditions, while integrating with existing governance processes. Visibility and accountability are built in Prevention is only one part of security. Detection and response matter just as much. Because these operations execute through SQL Server interface, they can be observed with established SQL monitoring and auditing patterns, including SQL Server Audit and Extended Events. That helps teams answer operational questions such as: Who enabled external connectivity? Which principal invoked an external endpoint? Which external model object was executed? When did behavior deviate from baseline? Governed SQL-side AI execution can improve both incident response and audit readiness. By centralizing execution and logging, organizations can more easily collect, trace, and explain evidence when investigating incidents or responding to compliance reviews. Architecture still determines risk Traditional AI patterns often move data out of SQL Server into other runtime layers before calling external models. This increases the attack surface and fragments policy enforcement. SQL Server 2025 enables a different operating model: Keep data closer to where governance already exists. Use explicit model and endpoint objects with permission checks. Apply outbound network controls and endpoint allow patterns. Centralize audit trails for security and compliance review. In addition, network connectivity and SQL permissions alone should not be the final security boundary. External AI endpoints should also enforce independent authorization decisions, such as RBAC, allowing access only to approved managed identities. This creates an additional layer of protection and helps limit the impact of credential misuse or configuration errors. Secure usage best practices Use this checklist before production rollout: Enable only the connectivity features required for the scenario. Grant least privilege for configuration, model management, and invocation. Restrict outbound traffic to approved destinations. Use managed identities where supported; otherwise use centrally managed, least-privilege credentials. Enforce endpoint-side authorization and RBAC controls for service identities and credentials. Audit configuration changes and invocation activity. Establish behavioral baselines and alert on deviations. Run periodic access and configuration reviews. Include incident response runbooks for external AI call paths. These practices align with standard SQL security guidance and are not unique to AI features. Most control failures come from weak operating discipline around the feature. Strong defaults help, but repeatable processes are what keep systems safe over time. Next Steps Review permission design for AI connectivity operations in a non-production environment. Define approved endpoint policy and outbound control requirements. Pilot one AI scenario with audit-first instrumentation. Document operational ownership for enablement, credential management, and monitoring. Get Started Refer to sp_invoke_external_rest_endpoint, apply the recommended risk-mitigation controls for unauthorized access and data transfer, then validate your CREATE EXTERNAL MODEL permissions in a dev environment using the best practices checklist above, and finalize your SQL Server Database Engine permission design before production rollout.Customer-managed key encryption now extends to Spark jobs in Microsoft Fabric
Security and compliance teams increasingly expect full control over the encryption keys that protect their data—not only while it sits in storage, but while it is actively being processed. In Microsoft Fabric, Spark powers some of the most data-intensive workloads, from large-scale data engineering pipelines to data science and machine learning. As these jobs run, they read, write, and temporarily stage data on the compute cluster. Customer-managed key support has been extended to that processing layer for Spark jobs.
Control where your streaming data goes with Outbound Access Protection for Fabric Eventstream
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: Enable OAP on a workspace to block all outbound connections to external endpoints including other workspaces. 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. 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: 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: 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: Enable OAP on your workspace. Configure data connection rules for each external source endpoint and each cross-workspace destination. 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.
Use built-in Fabric data protection to get your data AI-ready
Every organization wants to put AI to work on its data. Copilot, agents, and generative AI promise faster insight, but they raise a hard question for security teams: If AI can reach all our data, what stops it from surfacing the wrong data to the wrong person? The answer is to make your data AI-ready — classified, access-controlled, protected, and observable. Microsoft Fabric builds these capabilities directly into the platform through its integration with Microsoft Purview, so you can adopt AI with confidence instead of trading productivity for protection.Notebook export controls in Microsoft Fabric
Author: Santhosh Kumar Ravindran, Principal Product Manager - Prevent data exfiltration by restricting the ability to download notebooks and rich DataFrames. This capability ensures that sensitive data remains within governed environments, reducing the risk of unauthorized access, sharing, or leakage outside approved boundaries.
