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.
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.
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.Announcement: Microsoft Purview data loss prevention policies for Power BI are now generally available (GA)
We’re excited to announce the general availability of Microsoft Purview’s data loss prevention policies (DLP) for Power BI. This follows the successful public preview of DLP policies for Power BI which we launched back in April 2022! DLP policies help you automatically detect sensitive information managed in your Power BI tenant and take risk remediation actions, to help you comply with governmental or industry regulations, such as the European Union’s General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). On top of the GA we’re also introducing further enhancements to DLP policies in Power BI: DLP policies—classify and protect your Power BI data Nowadays, organizations are taking more measures to properly classify sensitive information and install processes and guardrails for their employees on how to interact with sensitive information. That said, we still see Compliance and Security Administrators who are worried about business-critical data that is still in the dark. This is precisely where the power of DLP policies comes into play: with DLP you can automatically detect sensitive information as it is uploaded to Power BI, and by thus uncover data that may have been accidentally uploaded into the wrong workspace, for instance. Compliance admins can set alerts to be automatically generated when sensitive information is found in datasets. They can provide customized messages to users and help guide them on how to interact with the sensitive data. For example, whenever proprietary information is detected, show Power BI users a message explaining that this information is internal and should not be shared externally. DLP is audited in the Microsoft Purview Compliance Portal, where compliance admins can also monitor their policies and refine them based on feedback from users, such as reported false positives. Identify sensitive information as it is being uploaded from Power BI desktop By using DLP policies in Power BI, you strengthen your security posture and reduce the risk of sensitive information being uploaded to the cloud without your knowledge. To learn more about how to setup DLP policies, visit our interactive guide. Detect sensitive information using custom keywords Some organizations consider certain terms, such as internal project names, as sensitive information that they want to ensure is not exposed outside of the organization. With this update you will be able to define those unique internal terms as a custom keyword sensitive info type and use it as a trigger for DLP in Power BI. Create a custom SIT of the Keyword Dictionary type to be used as a policy condition and trigger an alert. Complex conditions Complex conditions enable Admins to create advanced rules using a combination of AND/OR/NOT operators. With a new and improved flow, you can configure granular and flexible rules that utilize a combination of conditions, such as detecting bank account numbers in datasets that are not labeled as 'confidential'. A common scenario is locating sensitive data where it is not properly labeled according to the organization’s guidelines. In this case you could also use the custom policy tip text to draw this guideline into attention and encourage users to set the correct label. Define a complex condition: dataset contains credit card numbers and is labeled as general, OR it contains bank account numbers but is not labeled as confidential. DLP policies in national clouds All of the capabilities above have been extended to include national clouds: US Government: GCC, GCC High, DoD; China: China East. With the introduction of DLP in national clouds, users can take advantage of all the value DLP brings to the organization in governmental scenarios as well. Resources: Overview video Overview of DLP policies for Power BI Configure a DLP policy for Power BI Respond to a policy violation CPU metering for DLP policy evaluation Define Microsoft Purview DLP policies for Power BI (cloudguides.com) – Interactive Guide We’re always happy to hear any comments or feedback you may have regarding data loss prevention in Power BI. For any suggestions, please fill out this form.Updates to Microsoft Purview data loss prevention policies in Power BI
Data loss prevention (DLP) policies help you govern the sensitive information managed in your Power BI tenant and comply with governmental or industry regulations, such as GDPR (the European Union’s General Data Protection Regulation). Earlier this year, we announced the release of DLP policies for Power BI to public preview. We’ve seen impressive results with DLP policies in Power BI, with tenants scanning tens of thousands of datasets per day, and more. DLP policies provide you with an automatic solution to govern sensitive business data in your Power BI tenant, at scale. DLP policies identify sensitive data uploaded from Power BI Desktop and show a policy tip. We're happy to share with you two significant enhancements to DLP policies in Power BI: CPU metering for DLP policy evaluation Overriding policy tips and reporting false positives Introducing CPU metering for DLP policy evaluation Today, you can set up DLP policies in your organization that will automatically detect uploading of sensitive information or of data with a specific sensitivity label to "import datasets" into workspaces associated with your Gen2 Premium capacities. When a dataset is evaluated by the policy, it is scanned for sensitive information types or sensitivity labels, according to the policy conditions configured in Microsoft Purview compliance portal. This evaluation is triggered in one of the following data upload scenarios: Publish, Republish, On-demand refresh and Scheduled refresh. With each of these actions, Power BI will evaluate the dataset to determine if it contains sensitive information or not. This process utilizes CPU from the premium capacity associated with the workspace the evaluated dataset resides in. The CPU consumption of the evaluation will be equal to 30% of the CPU consumed by the refresh action that triggered the evaluation. For example, if a refresh action costs 30 milliseconds of CPU, then the DLP scan will cost an additional 9 milliseconds. The fixed 30% additional CPU consumption for the DLP evaluation can help you predict the impact of DLP policies on your overall Capacity CPU utilization, and perform capacity planning when rolling out DLP policies in your organization. *To clarify, there is no additional CPU metering due to DLP evaluation for Premium Per User workspaces, as they are not associated to Premium capacities. To see the CPU usage of your data loss prevention policies, go to the “Power BI Premium Capacity Metrics App”. For more information visit Monitor Power BI Premium capacities with the Premium Capacity Metrics app. - Power BI | Microsoft Docs Override policy tips and report false positives We’re introducing the ability for Power BI users to give feedback on the policy rules evaluating their datasets. This will enable them to provide insight on the datasets met with rules defined by the Security Admins in Microsoft Purview Compliance Portal, and help create a built-in line of communication to ensure smooth operation on both teams. In the dataset’s detail page, you will now be able to see all the policy rules that have been matched for this dataset. By clicking on the "view all" in the top yellow banner, you will open a side panel with a card representing each and every rule. On top of viewing all the matched rules, data owners will be able to take action if they believe the data was falsely identified. Based on how the policy rule was configured, you will be able to see one or a combination of these actions: Report an issue: Report the issue as a false positive (meaning that the policy has mistakenly identified non-sensitive data as sensitive, for example). Override: Override the policy. Overriding a policy means that this policy will no longer evaluate this particular dataset. Depending on the policy configuration, you may be required to provide a justification for the override. Report and override: Report the issue as a false positive and override the policy. Policy tip panel with a card representing each rule matched by the DLP policy, and its available actions. Learn more For more information, see Data loss prevention policies for Power BI.
