SQL Server 2025 AI features can be abused for data theft and covert command channels

Security researchers have shown how Microsoft SQL Server 2025’s new AI and external endpoint features can be abused after a database server is compromised. The research does not describe a remote unauthenticated SQL Server flaw, but it does show how legitimate database features can help attackers steal data, maintain access, and hide activity inside normal-looking SQL traffic.

The findings come from SpecterOps, which tested how new SQL Server 2025 capabilities could extend post-exploitation activity. The research focuses on features such as REST endpoint calls, external AI model definitions, vector embeddings, SQL triggers, and CLR-based execution paths.

Microsoft built these features to support modern AI workloads, including Retrieval-Augmented Generation, vector search, and direct integration with AI services. The risk is that the same database-native connectivity can become useful to attackers if they already control a powerful SQL account.

What the researchers found

The most important finding is that SQL Server 2025 can now make HTTPS requests from inside the database engine through sp_invoke_external_rest_endpoint. Microsoft’s documentation says the stored procedure can invoke a REST endpoint supplied as an input argument.

In legitimate deployments, that helps databases connect to cloud services, APIs, automation workflows, and AI endpoints. In a compromised environment, it can also give attackers a database-native path to send data out over HTTPS.

SpecterOps also published a public proof-of-concept repository containing companion material for its research. The repository covers data exfiltration primitives, a simple command-and-control agent, and a CLR-based C2 example that imitates embedding-style traffic.

SQL Server 2025 feature	Legitimate purpose	Potential abuse after compromise
External REST endpoint calls	Send HTTPS requests to approved services	Move database records or files to attacker-controlled servers
External AI models	Register AI inference endpoints for embeddings	Use model endpoints as covert communication channels
AI-generated embeddings	Create vector arrays for semantic search and RAG	Encode command traffic inside AI workflow requests
Database triggers	Automate actions after table changes	Leak new or updated rows continuously
CLR assemblies	Extend SQL Server with managed code	Run in-memory agent logic with fewer disk artifacts

How SQL Server 2025 changes the risk model

For years, defenders treated outbound web requests from database servers as suspicious. SQL Server 2025 complicates that assumption because AI workloads may now require databases to call external services as part of normal application behavior.

The Azure SQL Dev Corner says CREATE EXTERNAL MODEL and AI_GENERATE_EMBEDDINGS work together as an integrated pipeline for generating vector embeddings from T-SQL. That means modern SQL environments can send selected data to external model endpoints as part of approved AI workflows.

That design can help developers build search, recommendation, and RAG systems directly inside SQL. It also means defenders need better visibility into which accounts, models, credentials, and endpoints the database is using.

The REST endpoint feature can move large payloads

The external REST endpoint feature stands out because it supports sizeable data movement. Microsoft’s stored procedure documentation says payloads are limited to 100 MB when sent or received over the wire using UTF-8 encoding.

SpecterOps showed that a highly privileged attacker could collect table data, convert it into a structured format, and send it to an external server from the SQL Server process itself. This traffic may look different from older attacker patterns that relied on PowerShell, xp_cmdshell, or separate malware processes.

The feature is not automatically a security flaw. It needs to be enabled and permissions matter. The risk grows when privileged database accounts are overused, monitoring is weak, and outbound HTTPS from database servers is too open.

• Attackers can use approved-looking HTTPS traffic instead of noisy command execution.
• Large payload limits make bulk data movement more practical.
• Database-originated traffic may bypass endpoint detections focused on user workstations.
• Existing SQL logic, including triggers, can turn one-time access into recurring data leakage.

AI model features create another channel

SQL Server 2025 also adds model-aware database objects. Microsoft’s CREATE EXTERNAL MODEL documentation says the statement creates an external model object containing the location, authentication method, and purpose of an AI model inference endpoint.

That is useful for AI applications because developers can register a model once and reuse it from T-SQL. However, an attacker who can create or misuse an external model can make the database communicate with a server under attacker control.

The companion AI_GENERATE_EMBEDDINGS function creates vector arrays by using a precreated model definition stored in the database. SpecterOps showed how a malicious workflow could hide command check-ins and responses inside traffic that resembles AI embedding operations.

Why defenders may miss this activity

Many security programs monitor SQL injection, suspicious logins, large exports, and known dangerous procedures. Fewer programs inspect database-to-AI traffic, model metadata, outbound endpoint destinations, and service-account use with the same care.

The SpecterOps research shows why that gap matters. A database server that already holds sensitive data can become its own exfiltration tool once it has native HTTPS and AI endpoint capabilities.

Traditional alerts may also miss persistent leakage through triggers. If attackers create a trigger on a sensitive table, newly inserted or updated rows can be sent out automatically without a separate malware process.

Detection challenge	Why it matters	Useful signal
Database-originated HTTPS	May look like normal AI or API traffic	New external destinations or unusual request volume
Service accounts	Often hold broad permissions and run unattended	New use of external endpoint permissions
AI model objects	Can store endpoint and credential details	Unexpected model creation or modification
Triggers	Can create persistent leakage after table changes	New triggers on tables containing credentials or customer data
CLR assemblies	Can run logic inside SQL Server	New assemblies, unsafe permission sets, or unusual procedure calls

NTLM coercion risk adds another concern

The research also highlights a separate issue involving external model paths and NTLM authentication. SpecterOps said UNC paths in some AI model configurations could cause SQL Server to attempt SMB authentication, creating an opportunity to capture or relay NTLM authentication.

According to the researchers, Microsoft did not classify that behavior as a security boundary violation. For defenders, the practical response is still clear: SQL Servers should not freely reach arbitrary SMB destinations, and outbound SMB should remain tightly restricted.

This risk fits a broader pattern. AI features do not only expand application capability. They also introduce new identity, network, and credential flows that administrators must map before production rollout.

Who is most exposed?

The risk is highest for organizations that enable SQL Server 2025 AI features without strong governance. Environments with overprivileged SQL logins, broad outbound internet access, weak service-account controls, and limited database auditing face the greatest exposure.

Developers and data teams may enable these features to support semantic search, RAG, product recommendations, support search, or document retrieval. The Microsoft Azure SQL blog describes the features as a way to build AI workflows without separate application-layer orchestration.

That convenience is valuable, but it also puts more responsibility on database, security, and network teams to define what normal AI-related SQL traffic should look like.

• Databases containing credentials, tokens, customer records, payment data, or sales data need stricter controls.
• Production SQL Servers should not have broad outbound internet access by default.
• AI model endpoints should be allowlisted, owned, documented, and monitored.
• Privileged SQL roles should be limited and reviewed regularly.
• Security teams should treat SQL service accounts as high-value identities.

Defensive steps for SQL Server 2025 deployments

Organizations should first decide whether they need these features on each SQL Server instance. If external REST endpoints or AI model integration are not required, they should remain disabled or blocked by policy.

Administrators should also review who can create external models, execute external endpoint calls, manage database-scoped credentials, create triggers, and load CLR assemblies. Microsoft’s external model documentation notes that creating and altering external models requires specific permissions, and using a model requires execute access to that model.

The AI_GENERATE_EMBEDDINGS documentation also lists prerequisites, including enabling external endpoint functionality and using an accessible embeddings-type external model.

Control	Recommended action
Feature enablement	Disable external REST and AI runtime features unless required
Permissions	Limit sysadmin, external endpoint, external model, credential, trigger, and CLR privileges
Network egress	Allow database servers to reach only approved API and AI endpoints
Logging	Monitor external endpoint calls, model creation, trigger changes, and unusual query patterns
Identity	Harden SQL service accounts and remove unnecessary domain privileges
SMB restrictions	Block outbound SMB from SQL Servers unless a documented business need exists

Proof-of-concept code raises the urgency

The public mssql2025-poc repository makes the research easier for defenders to reproduce in a lab. It also means security teams should assume attackers can study the same techniques.

That does not mean every SQL Server 2025 deployment is immediately compromised. It means organizations should review feature use, permissions, outbound access, and monitoring before AI-enabled database workflows become common in production.

The main lesson is straightforward: AI features inside databases need the same security model as any other powerful execution and network feature. Teams should approve them deliberately, monitor them continuously, and restrict them to the smallest set of users, systems, and destinations possible.

FAQ