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.
Outbound access protection for Data Factory (Generally Available)
Co-author: Abhishek Narain Workspace outbound access protection (OAP) is widely accessible for Data Factory workloads—including Pipelines, Copy Job, and Dataflows—as well as for Mirrored Databases such as Mirrored SQL Database and Mirrored Snowflake. Key benefits Enhanced outbound security: By leveraging OAP rules, organizations can ensure that the Data Factory items from the protected workspace can only connect to trusted endpoints allowed by workspace admins. All the other outbound connections to public internet and other destinations are blocked from the workspace. Granular control: Control outbound access per workspace. This allows you to apply differentiated controls across business units, environments (dev/test/prod), data domains, or project. Data exfiltration prevention: Workspace OAP when combined with Inbound protection can help the customer prevent the data from exfiltrated outside the workspace boundary. Better compliance: Meet stringent compliance and regulatory requirements by ensuring your sensitive data never leaves the workspace boundary if it’s not allowed by Workspace Admins. Additional functionalities Exploratory APIs in pipelines and Copy Job: APIs used for Browse, Preview, and Test Connection operations will support outbound access protection. Copy job in OAP will support Datawarehouse as destination. Workspace level granularity for Notebook and Spark Job Definitions connection types. Machine Learning Models and Experiments are supported with outbound access protection. Data Agent and Eventstreams are now supported with outbound access protection in preview. To learn more about Workspace OAP for Data Factory, set-up scope and limitations, refer to the Workspace outbound access protection overview documentation and Workspace outbound access protection for Data Factory documentation. What’s next? We are actively working to expand OAP support for additional experiences and plan to add support for Power BI Semantic Models and Reports soon. Your feedback is essential! Let us know how we can make Fabric even more secure and flexible for your workloads by sharing your feedback at Fabric Ideas – Microsoft Fabric Community.
New data protection capabilities in Microsoft Fabric: Native security for the modern data estate
As organizations continue to scale analytics and AI initiatives, protecting sensitive data has never been more critical. With Microsoft Fabric, we are building data security directly into the analytics platform—so protection is consistent, automated, and enforced wherever data lives and travels. Today, we’re sharing several new data protection capabilities in Microsoft Fabric, powered by deep integration with Microsoft Purview. Together, these updates help organizations reduce data oversharing risk, improve visibility into sensitive data usage, and respond faster to potential data theft scenarios, without compromising productivity. Expanded DLP Restrict Access for Structured Data in OneLake (Preview) We’ve expanded DLP restrict access capabilities to cover all structured data in OneLake*, giving organizations broader, automatic protection for sensitive information once it is detected, more holistically across their OneLake data. With this release, restrict access will also apply to SQL databases, KQL databases and Warehouses (on top of Lakehouses and semantic models that were already supported). As a result, security and compliance teams can reduce the risk of accidental or intentional data exposure while still enabling broad data access for analytics and AI scenarios. These controls are policy-driven, consistent, and enforced automatically helping security teams scale protection without relying on manual processes. Figure: DLP restrict access indication on Warehouse * Support for c is coming soon. Sensitivity Labels Available Through Public APIs (Generally Available) To support automation and extensibility, sensitivity labels are now accessible through public APIs. This enables customers and partners to programmatically discover, apply, and manage classification across Fabric assets. This enhancement includes the following API operations: List Items – The response now includes the Sensitivity Label ID for each item. Get Item – The response includes the item’s Sensitivity Label ID. Create Item – Include a label ID to create an item with a sensitivity label. Update Item – The response includes the Sensitivity Label ID. (Note: labels can be retrieved programmatically but update labels via this API is not supported) These capabilities align with the existing label management APIs available today: Bulk Set Labels allow admins apply sensitivity labels to items. Bulk Remove Labels allow admins remove sensitivity labels from items. Now, users can programmatically access sensitivity label metadata without additional queries, streamlining compliance and improving automation. Insider Risk Management Support for Lakehouse Indicators (Generally Available) We’re also extending Microsoft Purview Insider Risk Management to support Lakehouse indicators in Fabric. This allows security teams to detect, investigate, and respond to potentially risky user activities involving sensitive data stored in Fabric Lakehouses. By ingesting Fabric audit signals into Purview Insider Risk Management, organizations can apply the same insider risk detection and investigation capabilities they already use across Microsoft 365 and other data sources, including Fabric analytics workloads—bringing the real power of a centralized management across your entire data estate. Figure: Lakehouse indicators used within the IRM tool New Quick Data Theft Policy in IRM for Fabric (Generally Available) To simplify and accelerate risk response, we’ve introduced a new quick policy creation of the Data Theft rule for Fabric. This streamlined experience makes it easier to set up protection against data exfiltration scenarios, helping security teams act faster when sensitive Fabric data is at risk. With fewer steps and clearer guidance, organizations can move more quickly from detection to remediation, reducing exposure while maintaining productivity. IRM Pay-as-you-go Usage Report (Generally Available) The Microsoft Purview Insider Risk Management pay-as-you-go feature usage report is designed to provide transparency to the customers, enabling more accurate budget planning and policy tuning. IRM admins can check the distribution of PAYG processing units that were billed across workloads (Fabric), sub workloads (Power BI, Lakehouse), and indicators (downloading power BI reports, etc.) to fine-tune their policies and plan PAYG budgets accordingly. Purview Data Security Posture Management (DSPM) for AI for Fabric Copilots and data agents (Preview) As organizations adopt AI, implementing controls becomes crucial to discover risks and prevent data oversharing when using AI. With DSPM for AI for Fabric, organizations can monitor Copilots and data agents interactions in Fabric. Users can now: Surface data security risks by detecting sensitive information in AI prompts and responses, with actionable recommendations available directly in the DSPM dashboard. Detect and investigate risky AI behavior using Insider Risk Management, helping security teams identify scenarios where users may have unintentionally shared sensitive data or bypassed established security practices. Apply governance and oversight to AI interactions through Purview Audit, eDiscovery, retention policies, and detection of non‑compliant usage, enabling consistent controls across AI-powered experiences. Figure: Purview DSPM for AI report showing Data Agent interaction in Fabric Bringing it all together Taken together, these updates reinforce a core principle of Microsoft’s approach to data security: protection is built in, consistent, and end-to-end. From sensitivity labeling and automated access restrictions in OneLake to advanced insider risk detection and fast remediation, Microsoft Fabric and Purview work together to help secure data across analytics, AI, and collaboration. As data estates continue to grow and complexity, we remain committed to delivering security capabilities that scale with your business—without slowing innovation. Learn more about DLP restrict access. Learn more about IRM for Fabric. Learn more about DSPM for AI in Fabric.
