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.
