SQL Server 2025 AI features expand database exfiltration and C2 risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SpecterOps's blog post: SQL Server 2025 AI features let attackers abuse database-native HTTPS, external models, and embeddings to move data and C2 traffic through trusted engine behaviour.

Why it matters: Database teams and identity practitioners need to treat service accounts, outbound trust, and privileged database features as part of the same control plane, because abuse here can turn legitimate engine access into covert exfiltration.

Context

SQL Server 2025 adds database-native AI and outbound web features that blur the line between ordinary application behaviour and covert transport. When a privileged database engine can call external endpoints, host external models, and generate embeddings, defenders have to treat egress, query content, and account privilege as a single governance problem.

The core security gap is not that SQL Server suddenly became malicious. It is that highly privileged database roles, service accounts, and outbound connectivity can now be combined in ways that make exfiltration look like routine platform activity. That is a familiar NHI pattern: the engine is legitimate, but the identity and access around it are not tightly governed.

Key questions

Q: How should teams govern AI features in database engines?

A: Teams should govern database AI features as externally reachable code paths, with explicit approval, least-privilege execution, outbound allow-lists, secret isolation, logging, and a clear owner for every feature. The same controls used for application APIs should apply to database AI features, because they can send data out, call remote services, and expand the trusted boundary of the engine.

Q: Why can a database engine become an exfiltration channel?

A: A database engine can become an exfiltration channel when it is allowed to make trusted outbound connections that carry query results, prompts, or metadata to an external destination. If an attacker can influence that output path, the engine itself can relay sensitive data over HTTPS, DNS, or other egress that defenders may treat as legitimate application traffic.

Q: How do AI features change SQL Server attack surface?

A: AI features change SQL Server attack surface by adding new outbound request paths, new parsing and serialisation logic, and new permission checks around data sent to external services. That creates extra routes for data exposure, command misuse, and privilege abuse beyond normal query execution, so the feature must be treated as an internet-reachable integration point.

Technical breakdown

Database-native HTTPS as an exfiltration channel

The new REST endpoint capability lets SQL Server issue HTTPS requests from inside the engine, which means data can leave the database through a path that looks operational rather than suspicious. That matters because defenders often key on obvious web clients or custom implants, not on database processes making outbound calls. Once the engine can both read data and post it elsewhere, the database becomes a transport layer as well as a store. This changes the detection problem from spotting malware to understanding which database features are allowed to talk out.

Practical implication: Treat database egress as a governed capability and restrict outbound destinations for SQL Server instances.

External models and embeddings create a trusted callback path

CREATE EXTERNAL MODEL and AI_GENERATE_EMBEDDINGS connect the database to remote or local model endpoints, which gives operators a structured way to send data out and receive responses back. In security terms, that creates a bidirectional trust relationship anchored in the database engine. If the model endpoint is attacker-controlled, the database can be turned into a callback client without using conventional remote administration tooling. The architectural issue is not only data theft but also the reuse of AI plumbing as a communication fabric.

Practical implication: Constrain which model endpoints SQL Server may call and inventory every approved external model registration.

Privileged SQL accounts turn feature abuse into lateral movement support

The post assumes a compromised sysadmin-style account, which is realistic because over-privileged database identities often have broad access to procedures, configuration changes, and stored data. That is why the threat is not limited to exfiltration. A database account with excessive rights can enable persistence, trigger-based collection, and access to files or directories that should never be exposed to the application layer. In NHI terms, the service identity running the database and the administrative identity operating it both need lifecycle control, not just password policy. See the Service Account Security Guide.

Practical implication: Reduce database privilege to the minimum required and govern service accounts as non-human identities.

Threat narrative

Attacker objective: The attacker wants to use the database engine as a trusted channel for stealing data and maintaining covert communication without relying on noisier tools.

1. Entry occurs when an attacker gains a privileged SQL Server account or otherwise reaches an instance where the new AI features are enabled.
2. Credential and access abuse follows as the attacker uses over-privileged database rights to enable outbound features, register external models, or invoke stored procedures.
3. Escalation and persistence emerge when the attacker chains triggers, model callbacks, and engine-native requests to keep collecting data and to move traffic through trusted SQL Server behaviour.
4. Impact is data exfiltration and covert command-and-control transport that blend into legitimate database activity.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Database AI features are becoming an identity and egress governance problem, not just an application feature set. Once SQL Server can call external endpoints and external model services, the security question shifts from whether the feature works to who can activate it, where it can send data, and how that traffic is monitored. That places database service accounts, administrative roles, and outbound policy in the same control plane. Practitioners should treat database AI enablement as a governed identity decision, not a simple platform toggle.

Standing privilege inside database engines is the failure mode this tradecraft exploits. The post assumes a sysadmin-level foothold because over-privileged database identities can enable features, read sensitive tables, and launch outbound callbacks without additional approval. This is the same pattern seen in other NHI abuse cases: the tool is ordinary, but the privilege is too broad. service account security and least-privilege database administration belong in the same review cycle.

Outbound HTTPS from a database engine is now a detectable pattern, not a rare anomaly. Security teams have historically treated web egress from SQL Server as suspicious because it was unusual. AI-enabled database features change that baseline, so the governance problem becomes distinguishing approved model traffic from covert exfiltration. The new named risk here is database egress normalisation: when defenders accept the transport before they understand the use case, attackers inherit a trusted channel.

Feature exposure without compensating controls creates an abuse surface that defenders cannot see through traditional logging alone. The post shows that native logs do not reliably capture the most relevant SQL text or feature toggles, which means telemetry has to be engineered around feature enablement, external model registration, and outbound requests. This is a governance gap as much as a detection gap. Practitioners should require explicit approval, logging, and rollback for any AI-capable database feature set.

AI-enabled database platforms will increasingly force convergence between IAM, data security, and SOC monitoring. The same privileged identity can now read sensitive data, activate an outbound channel, and stage persistence through the database itself. That means identity governance cannot stop at account ownership, and SOC coverage cannot stop at network indicators. The practical conclusion is to govern the database as both a data system and a privileged runtime.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Database egress normalisation: once an engine is allowed to make outbound HTTPS calls for legitimate AI workflows, the control objective shifts from blocking all web traffic to proving that each destination, payload shape, and feature toggle is expected. That is a harder problem than standard database hardening, and it belongs in both IAM and SOC review cycles.

The practical impact will be felt in detection engineering and access governance at the same time. Teams will need to watch for feature enablement, external model registration, and unusually large outbound payloads from SQL Server, while also reducing the privilege of the identities that can invoke those behaviours.

For practitioners

• Inventory every SQL Server 2025 AI-capable instance Identify where external REST endpoints, external models, and embedding functions are enabled, then classify each instance by business need and exposure.
• Restrict outbound destinations for database engines Allow only approved model hosts and API endpoints from SQL Server subnets, and block general internet egress wherever the feature set does not require it.
• Review privileged database identities and service accounts Remove standing sysadmin rights where possible, and treat the SQL Server service account as a governed non-human identity with explicit ownership and rotation.
• Alert on external model registration and feature enablement Send SIEM detections for CREATE EXTERNAL MODEL, ALTER EXTERNAL MODEL, and enablement of external rest endpoints so feature abuse is visible quickly.
• Baseline legitimate database egress patterns Profile normal HTTPS destinations, payload sizes, and timing from SQL Server so anomalous outbound traffic can be distinguished from approved AI workflows.

Key takeaways

• SQL Server AI features can turn a trusted database engine into a covert transport for exfiltration and callback traffic.
• The abuse path depends on privileged database access, feature enablement, and outbound trust that defenders may not currently monitor closely enough.
• Restricting database egress, governing service accounts, and alerting on external model activity are the controls most likely to limit the risk.

Related NHI Mgmt Group resources: Service Account Security Guide · Lateral Movement Guide · Ultimate Guide to NHIs · Dropbox Sign breach 2024

Key terms

• sp_invoke_external_rest_endpoint: sp_invoke_external_rest_endpoint is a SQL Server stored procedure that sends an HTTP request from the database engine to an external REST endpoint. It is used to call web services from Transact-SQL, so it creates an outbound network action that must be governed like any other integration call.
• CREATE EXTERNAL MODEL: CREATE EXTERNAL MODEL is a database command used to register an external machine learning or AI model for use by the engine. It defines how the database reaches that model, what inputs are sent, and which permissions govern the call, so it is part of the database’s external execution surface.
• AI_GENERATE_EMBEDDINGS: AI_GENERATE_EMBEDDINGS is a database function that creates vector embeddings from input text by calling an AI model. It converts content into numerical representations for search or similarity use, and the call may send source data outside the database boundary to a model service.
• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect privileged access control to the broader identity decisions that shape database and platform security.