SQL Server Isn't Dying. It's Being Promoted to Cash Cow

Last week, The Register ran a line about SQL Server that I haven't been able to shake: that it's "too lucrative to ditch, but too legacy to love". Both halves are true, and they pull in opposite directions. One half is why you can sleep at night. The other is why you should be paying attention.

I've built a career on this engine, so 'too legacy to love' lands a little sharp. But the market gets a vote, too, so let's do this with evidence, not feelings.

The Stage SQL Server Didn't Get

The loudest signal this year wasn't an announcement. It was a matter of placement. At Build 2026, the keynote spotlight went to AI agents, and the headline database announcement was HorizonDB. SQL Server had its sessions, but it didn't have the stage.

That placement is louder than it looks, because SQL Server 2025 had only just shipped, carrying native vector search that one analyst rated its strongest addition in a decade. There were breakout sessions on SQL Server and Azure SQL AI features, so it wasn't absent from the event. But the keynote spotlight and the headline database announcement went elsewhere, and for a flagship-grade release that's the tell.

Two personnel facts sit underneath that. Rohan Kumar, the long-time SQL Server champion inside Microsoft, left the company in June. The SQL Server remit now belongs to Arun Ulag, president of Azure Data, who also runs Fabric and a portfolio of open-source database services. The product no longer has its own champion at the top; it shares one with the very platform that's replacing it in the spotlight.

And then there's the licensing. Microsoft's own terms let you carry SQL Server licenses over to AWS's RDS service without paying twice. Read that again. They are fine with you running SQL Server on a direct competitor's cloud, so long as the license revenue keeps landing in Redmond.

Why It's Not Going Anywhere

Now the other half. SQL Server is not dying as a product, and anyone telling you otherwise is selling a migration.

Cloud and AI get most of the public attention, but on-prem systems are still the bedrock of enterprise operations: the things that record a sale or clear a bank transaction. Microsoft pulls roughly $15 billion a year from the on-prem DBMS market, most of it SQL Server, and that business was still growing around 8% in 2025. Of the major legacy database vendors, Microsoft is the only one to have grown its DBMS market share over the last fifteen years, reaching roughly 33% of the on-prem market and trailing only Oracle. This is a winning business, not a dying one.

You're not getting orphaned either. Support for SQL Server 2025 runs through 2036. That's a decade-plus of patches and updates on a version you can install today.

Where the Energy Actually Went

So if the money is flowing and support runs to 2036, what's the problem? The problem isn't survival. It's direction.

In the cloud, PostgreSQL has become the de facto API for relational databases. It's gone so far that vendors now ship Postgres-compatible wire protocols on purpose, as an insurance policy against vendor lock-in. Microsoft isn't fighting that current. They're swimming in it, and their answer is HorizonDB -- a cloud-native, PostgreSQL-compatible database of its own. It runs on a custom, memory-safe Rust storage engine and scales to 128 TB and thousands of vCores. It ships DiskANN vector search and mirrors directly into Fabric, and Microsoft is now the number-one PostgreSQL committer among the hyperscalers.

At the same time, the operational databases like Cosmos, Azure SQL, and Postgres, are being pulled under the Fabric umbrella, and Microsoft has been clear that Fabric is where it expects its growth to come from. That is the strategy. Period.

Developer mindshare tells the same story from the ground up. The DB-Engines popularity race at the top is tightening:

Engine	Rank	Score
SQL Server	#3	698
PostgreSQL	#4	688

Those DB-Engines numbers are from June 2026. Oracle and MySQL still lead the overall table, so the real story is that ten-point gap between #3 and #4, and the direction it's been closing. Developer mindshare points the same way. In the 2025 Stack Overflow survey, Postgres is now the most-used database among professional developers at 55.6%, up from 48.7% a year earlier, while SQL Server sits fourth. The engine that gets championed is not the one the next generation reaches for first.

Cash Cow, Not Flagship

Put those three things side by side and a shape appears. A cash cow is a product a company milks for steady, low-effort revenue while it spends its real innovation budget somewhere else. That's not an insult. It's a portfolio decision, and a common one.

Watch how cleanly SQL Server fits the pattern. Steady milking: $15 billion a year, license portability even onto a rival's cloud, support locked in to 2036. Growth budget elsewhere: HorizonDB, Fabric, the Postgres committer push. The soft signals: the champion gone, the remit folded into the Fabric executive's portfolio, a fresh release that drew sessions but not the stage. None of those is a death warrant.

Each is a product that earns its keep while the attention moves elsewhere. The open-source tide is running toward Postgres, but SQL Server's stability, security, and deep ecosystem keep it entrenched in corporate stacks that aren't going anywhere -- which is what makes it a good cow to be milking. The revenue and the licensing economics tilt the same way: toward Azure, where Fabric and HorizonDB are waiting. SQL Server doesn't have to win for Microsoft to win, as long as your workload ends up in their cloud, feeding the newer, bigger tools.

That's the read I'd stand behind: SQL Server isn't dying. It's being quietly promoted to cash cow. Maintained, not championed.

To be clear, that's my read of the evidence, not an official press release. Microsoft will tell you SQL Server 2025 is a major release, and on the technical merits, they're right. But where a company aims its keynote, its org chart, and its committer headcount tells you where it thinks the future lives, and right now, none of those arrows point at SQL Server.

What This Means If You Run It

So what do you actually do with this? First: don't panic. The engine is excellent, funded, and supported for years. Don't let a blog post talk you into a migration you don't need.

Second: know exactly where you stand. Run this and write down the answer.

-- Where am I, and how long is it supported?
SELECT 
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel')   AS product_level,
    SERVERPROPERTY('Edition')        AS edition;

Map that version to its support horizon and plan your upgrades on your timeline.

Third: read the room. Microsoft is pointing its own future in two directions, and neither one is SQL Server. One is Postgres, the engine. The other is Fabric, the platform it wants your data to live in. Both are worth your time. Pick up Postgres so you're bilingual at the engine level, and get familiar with Fabric so you're not a stranger to where the data's expected to land. Not because SQL Server is going away (it isn't), but because the people signing the checks have told you which direction they're headed. That's just good career insurance.

Too lucrative to ditch, too legacy to love. I'll quibble with the second half. I've loved worse things for worse reasons, and this engine has earned its keep many times over. But I can't argue with the evidence behind it. SQL Server is in no danger. It's just no longer the thing Microsoft is excited about. Plan accordingly.

More to Read

The Register – Too lucrative to ditch, too legacy to love
Stack Overflow 2025 Developer Survey – Databases
DB-Engines – SQL Server popularity trend
Microsoft – Azure HorizonDB
Related: SSIS Isn't Dead Either. Yet.

Copilot in SSMS Runs As You — Until You Fence It In

Here is a piece that many people miss when they wire up GitHub Copilot in SSMS: when Copilot runs a query, it runs as you. Same login, same permissions, and same blast radius. Connect as sysadmin and your helpful AI assistant is also sysadmin — db_owner in means db_owner out.

That is fine when you are poking at a dev box, but it's a different thing entirely when a DBA with db_owner in production asks Copilot to 'clean up some old rows', and Copilot happily obliges without any safety checks. SSMS 22.7 finally gives us a way to fence that in.

What changed in 22.7

Starting in SSMS 22.7, you can give Copilot its own execution context — a dedicated identity that is separate from the user driving it. You point Copilot at a database user or SQL login, and from then on every query Copilot runs executes as that principal instead of the human at the keyboard. The DBA keeps their own access in the Query Editor and Object Explorer, but what Copilot executes on their behalf is now restricted to only what Copilot's identity can access. See Microsoft's writeup, Introducing execution context for GitHub Copilot in SSMS.

I believe this is a remarkable step forward in the AI realm that we now exist in.

The setting is called agentExecuteAsUser, and it lives in the frontmatter of that database's CONSTITUTION.md, which is the markdown instruction block SSMS stores as a database-level extended property. It is configured per database. When Copilot connects, it reads the constitution, and if it finds agentExecuteAsUser, Copilot then executes database actions under that user context.

Set it up

Here is a self-contained walk-through with two tables: one Copilot is allowed to touch and one that it isn't.

USE DBA;
GO

CREATE TABLE dbo.Orders (OrderID int IDENTITY PRIMARY KEY, Customer nvarchar(50), Total money);
CREATE TABLE dbo.Payroll (EmpID int IDENTITY PRIMARY KEY, EmpName  nvarchar(50), Salary money);
GO

INSERT dbo.Orders (Customer, Total) VALUES (N'Acme', 100.00), (N'Globex', 250.00);
INSERT dbo.Payroll (EmpName, Salary) VALUES (N'Employee A', 90000), (N'Employee B', 120000);
GO

Now we create the identity Copilot will run as, and grant it only the permission it needs -- SELECT on Orders, nothing else. No rights on Payroll at all.

USE DBA;
GO

-- The least-privilege identity Copilot executes as
CREATE USER CopilotExec WITHOUT LOGIN;
GO

-- Only what Copilot needs. SELECT on one table, full stop.
GRANT SELECT ON dbo.Orders TO CopilotExec;
GO

Now store the CONSTITUTION.md as the database's extended property. The agentExecuteAsUser line goes in the frontmatter: the block at the very top of the CONSTITUTION.md file, opened and closed by its own '---' line, as the code below shows. Everything after that closing '---' is the body, where the behavioral guidelines go.

USE DBA;
GO

DECLARE @DBUser NVARCHAR(128) = N'CopilotExec';

DECLARE @constitution NVARCHAR(4000) = N'---' + CHAR(10)
    + N'agentExecuteAsUser: ' + @DBUser + CHAR(10)
    + N'---' + CHAR(10)
    + N'# Database Constitution' + CHAR(10)
    + CHAR(10)
    + N'## Coding Guidelines' + CHAR(10)
    + N'- Never suggest DROP statements' + CHAR(10)
    + N'- Always include a WHERE clause on UPDATE or DELETE' + CHAR(10)
    + N'- Avoid SELECT * in production code';

IF EXISTS (SELECT 1 FROM sys.extended_properties
           WHERE class = 0 AND name = N'CONSTITUTION.md')
    EXEC sp_updateextendedproperty @name = N'CONSTITUTION.md', @value = @constitution;
ELSE
    EXEC sp_addextendedproperty @name = N'CONSTITUTION.md', @value = @constitution;
GO

One last step that is easy to forget. The human using Copilot must be able to impersonate CopilotExec, or the engine will not let Copilot switch context. Grant IMPERSONATE to your Copilot user — here, the database user is me.

USE DBA;
GO

GRANT IMPERSONATE ON USER::CopilotExec TO [sqlfingers\rlewis];
GO

First, let's verify the SQL Server boundary manually. This simulates the execution context SSMS Copilot should use when agentExecuteAsUser is active.

USE DBA;
GO

EXECUTE AS USER = 'CopilotExec';
GO

SELECT
    USER_NAME() AS DatabaseUser,
    ORIGINAL_LOGIN() AS OriginalLogin,
    HAS_PERMS_BY_NAME('dbo.Orders', 'OBJECT', 'SELECT') AS CanSelectOrders,
    HAS_PERMS_BY_NAME('dbo.Payroll', 'OBJECT', 'SELECT') AS CanSelectPayroll;

SELECT * FROM dbo.Orders;    -- returns rows
SELECT * FROM dbo.Payroll;   -- Msg 229, denied
GO

REVERT;
GO

We see results from the top two SELECTs but that call to Payroll fails with Msg 229. This proves the database wall we just put up works. CopilotExec can read Orders but the call to Payroll fails with Msg 229.

Now that we've proven the SQL Server boundary manually, let's verify the permissions available to the execution context itself.

EXECUTE AS USER = 'CopilotExec';
GO

SELECT
    USER_NAME() AS DatabaseUser,
    HAS_PERMS_BY_NAME('dbo.Orders', 'OBJECT', 'SELECT') AS CanSelectOrders,
    HAS_PERMS_BY_NAME('dbo.Payroll', 'OBJECT', 'SELECT') AS CanSelectPayroll;
    
REVERT;
GO

As intended, CopilotExec can read Orders but not Payroll. With that established, I then asked Copilot to return the top 10 rows from dbo.Payroll:

There it is. Copilot can only query what CopilotExec is privileged for. It sees that it doesn't have SELECT on Payroll and very kindly gives us a script to do it ourselves.

Even better, Copilot did not simply obey the prompt. It recognized the execution context defined in the database constitution and determined that the current context did not have permission to access the requested table. To me, THAT is the type of governance we need in AI to manage data safely, legally, and ethically.

Two boundaries, and only one of them is real

It is worth being precise about what is actually protecting you here, because the constitution does two different jobs:

Mechanism	Type	Enforced by
agentExecuteAsUser	Hard boundary	SQL Server permissions on the impersonated user
Constitution body (ie., 'never DROP')	Soft boundary	The model choosing to behave

The guidelines in the body steer behavior. They do not stop anything. Microsoft is blunt about this in the Agent mode docs: "The security boundary is SQL Server's permission enforcement, not Copilot's approval system." The approval prompts and the READ_ONLY default are seatbelts. The permissions on agentExecuteAsUser are the wall. You need to build the wall AND enforce seatbelt usage.

Gotchas worth knowing before you ship it

Gotcha	What happens
Missing IMPERSONATE grant	Copilot cannot assume the configured agentExecuteAsUser identity, so the execution context never activates
Per database	It is not server-wide. Set this on every database you care about
Lazy account choice	Do not point it at sa, dbo, or a broad admin login because it is convenient. That defeats the feature

Version requirements

Requires SSMS 22.7 or later with the AI Assistance workload installed (it is a separate component in the Visual Studio Installer), plus a GitHub account with Copilot access. SSMS 22.7.0 shipped June 9, 2026 and 22.7.1 followed on June 16 with a query-editor fix for large scripts. 22.7.1 is the most current SSMS 22 build.

Again, I think this is a real step forward for better controls with AI and SQL Server, but it still requires a common-sensical approach with best practices. Follow the least privilege principle with your agentExecuteAsUser just like you would any other user. Grant the minimum permissions needed for the tasks at hand. Just like Erin Stellato said, "The tighter the permissions on this user, the more confidence you have in what GitHub Copilot in SSMS can and can't do." Read more on the Copilot best practices here.

More to Read

Introducing execution context for GitHub Copilot in SSMS
Announcing the Release of SSMS 22.7.0 - and many previews
GitHub Copilot Agent Mode (Preview) - Microsoft Learn
Database Instructions (CONSTITUTION.md / AGENTS.md) - Microsoft Learn
Best Practices for GitHub Copilot in SSMS - Microsoft Learn

Cannot Generate SSPI Context: The July RC4 Change That Breaks SQL Logins

Here's a fun one. In July, a Windows security change is going to walk up to some of your SQL Server logins and quietly stop trusting them. No SQL patch. No SQL CVE. Nothing in the error log pointing at the real culprit. Connections that worked on Monday just start failing on Tuesday, and the message you get -- if you get one -- sends you off chasing the wrong thing entirely.

The change is the death of RC4 as a Kerberos fallback, tracked as CVE-2026-20833. It has been rolling out in phases all year. July is the phase with no take-backs, and the final enforcement phase arrives with the July 2026 Patch Tuesday releases.

The symptom you will actually see

This is the cruel part. The thing breaking is Kerberos ticket encryption out at the domain controller, but SQL Server doesn't know that. What lands in your lap is the same tired, generic error that has meant a hundred different things for twenty years:

Cannot generate SSPI context.

Or a login that times out. Or an app pool that starts throwing connection failures at 9:05am because that is when the service account went looking for a fresh ticket. The symptoms vary, but none of them say 'RC4' anywhere. You will burn an hour on SPNs and DNS before even looking at Kerberos.

So let's get ahead of it. First, we need to clarify what is changing and then we need to find out whether any of your instances will be impacted.

What is changing, in three dates

For roughly two decades, Active Directory handed out Kerberos tickets encrypted with RC4 as a compatibility fallback. RC4 is cryptographically weak. An attacker who can obtain an RC4-encrypted service ticket can crack the service account password offline, on their own machine, where nothing you own ever sees a failed login or account lockout. Against a weak service account password, this can happen far faster than most administrators realize. That is the entire Kerberoasting playbook, and it is exactly why MSFT is finally pulling the fallback.

CVE-2026-20833 (CVSS 5.5, information disclosure) is the staged removal of that fallback. Three milestones matter:

Phase	What happens	Can you roll back?
Jan 2026	Audit only. New System-log events warn you about at-risk tickets. RC4 still works. Nothing breaks yet.	N/A
Apr 2026	KDC default flips to AES-only (0x18) for accounts with no explicit encryption type set. RC4 still allowed where explicitly configured.	Yes
Jul 2026	Full enforcement. Audit mode is gone, the rollback registry key is retired, implicit RC4 fallback is removed from the KDC path for good.	No

As of today, June 18th, the default has already flipped, but there is still an escape hatch. July takes that hatch away. After that, RC4 only works for an account where someone has gone out of their way to explicitly allow it, which is a thing you should be removing, not adding.

Why SQL Server is squarely in the blast radius

Every SQL Server using Windows Authentication over Kerberos has a Service Principal Name, the MSSQLSvc/ SPN, registered against the account running the service. That SPN is the thing a client uses to request a Kerberos ticket for your instance. Which means your SQL service account is, by definition, a Kerberoastable target -- any authenticated user in the domain can request a service ticket for that SPN. No admin rights required.

Most modern service accounts are fine. An account picks up its AES keys the moment its password is set in a domain at the Server 2008 functional level or higher -- which, since AES-SHA1 shipped with Server 2008, has been the floor for close to 18 years. The accounts that will break in July are the stragglers whose passwords predate that:

The accounts that will fail silently

An old service account explicitly pinned to RC4-only. A downlevel client or appliance that only knows how to ask for RC4. A service account whose msDS-SupportedEncryptionTypes is something legacy and nobody has touched since the box was built on Server 2008. A linked server hop where the far end is the weak link. These are the connections that worked yesterday and will not work after enforcement, with nothing in the SQL error log to tell you why.

The point is not panic. Most of your estate is probably clean. The point is that the failures are silent and the deadline is real. The July updates that flip enforcement start shipping on Patch Tuesday, July 14, and your domain controllers cross the line whenever they take that update. So you want to know now, rather than find out from a 5AM phone call the morning after your DCs patched.

Find out if you are exposed -- the SQL-native check first

Start where you live. This query tells you which sessions on an instance are riding on Kerberos right now, which is exactly the set of connections that depend on the SPN and ticket encryption that is about to be enforced.

-- Who is authenticating via Kerberos right now?
SELECT
    s.session_id,
    s.login_name,
    c.auth_scheme,          -- KERBEROS, NTLM, or SQL
    c.net_transport,
    c.client_net_address
FROM sys.dm_exec_connections c JOIN sys.dm_exec_sessions s
  ON c.session_id = s.session_id
WHERE c.auth_scheme = 'KERBEROS'
ORDER BY s.login_name;

Anything coming back as KERBEROS is leaning on the machinery that changes in July. Here's a one-liner just for your own connection:

SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

This will return different values -- KERBEROS, NTLM, SQL. KERBEROS means the connection is riding the exact machinery being enforced in July. NTLM means Kerberos was not used for this connection. Sometimes that is by design -- connecting by IP instead of the FQDN, or an environment with no SPNs set -- and sometimes it points at a missing or misregistered SPN. Either way it is not in scope for July. SQL means SQL Authentication, so this change does not touch it at all.

Now go check the account itself

The sys.dm_exec_connections DMV tells you which sessions are on Kerberos. Active Directory tells you whether the service account behind them can actually negotiate AES. Find the SQL service account's SPNs and its current encryption types:

# List the MSSQLSvc SPNs registered to the service account
setspn -L DOMAIN\svc_sql

# What encryption types does AD think this account supports?
Get-ADUser -Identity 'svc_sql' -Properties 'msDS-SupportedEncryptionTypes' |
    Select-Object Name, 'msDS-SupportedEncryptionTypes'

Read the result like this:

Value	Meaning
null or 0	No explicit setting -- inherits the domain default, which is now AES-only. Fine IF the account has AES keys. Worth confirming.
4 (0x4)	RC4 explicitly allowed. This is the one to fix.
24 (0x18)	AES128 + AES256. This is where you want to be.

Checking one account's attribute only tells you about that one account. The Windows event logs on your domain controllers see everything -- clients, appliances, and downlevel boxes you might not even think about checking. There are two logs to look at, and they tell you different things.

One thing up front: these are logs on the domain controllers, not on your SQL boxes. If you do not have rights to read DC event logs -- and as a DBA you may not -- this is the part you hand to your AD team. You can open these in Event Viewer by hand, but the fastest way to filter them is PowerShell, run on the DC. The commands below are PowerShell.

Start with the Windows System Event log. The January update added new RC4 warning events here, and the DC writes one whenever it handles a ticket that will break once enforcement is complete. This pulls the most recent 50 of them:

# PowerShell, run on a domain controller
# Pulls the new RC4 warning events the January update added to the System log
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=201,202,206,207 } -MaxEvents 50 |
    Format-List TimeCreated, Id, Message

Each result has an event ID and a Message. All four IDs are the same family of RC4 warnings, but read 202 and 207 first -- the Message on those names a specific at-risk service account, which is exactly what you are hunting. 201 and 206 are broader warnings about the same activity, with no single account called out.

The System event log tells you what the DC flagged. The Security event log lets you watch RC4 happen in real time. Events 4768 and 4769 are the routine Kerberos ticket requests every DC logs, and each one records the cipher that was actually issued in its 'Ticket Encryption Type' field. A value of 0x17 in that field is RC4 caught in the act. This pulls recent ticket requests and keeps only the RC4 ones:

# PowerShell, run on a domain controller
# Keeps only the 4768/4769 ticket events whose encryption type is RC4 (0x17)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4768,4769 } -MaxEvents 200 |
    Where-Object { $_.Message -match '0x17' } |
    Format-List TimeCreated, Id, Message

In the results, the account pulling the RC4 ticket is in the Message -- the 'Account Name' field for a 4768, the service in 'Service Name' for a 4769. Any account that turns up in either query is one to fix before July.

The fix -- and whose job it is

Here is the important part: the fix lives in Active Directory, not in SQL Server. As the DBA, your job is to find the exposed SQL service account and hand the AD team a specific, actionable request. Unless you're also the AD admin, you shouldn't be running commands against the DC yourself. You want to know if this will impact you and what has to be done.

There are two pieces to the remediation, and both are AD-side:

1. Allow AES on the account. The account's msDS-SupportedEncryptionTypes attribute needs to be set to 0x18 (AES128 + AES256). For reference, that is a one-line change your AD admin would make:

# For the AD team, not the DBA -- run by AD against the service account
Set-ADUser -Identity 'svc_sql' -Replace @{ 'msDS-SupportedEncryptionTypes' = 0x18 }

2. Make sure the account has AES keys. Allowing AES does nothing if the account has no AES keys to hand out, and those keys only get generated when the password is set in a domain at the Server 2008 functional level or higher. For an account whose password has changed in recent memory, this is already done. For an account that predates AES key generation, the AD team typically resets the service account password so Active Directory can generate fresh AES keys for the account.

The password reset is the piece that reaches back into your world, so it needs to be coordinated. It is a real service account. The new password has to be updated wherever the SQL Server service uses it, the service restarted, and authentication confirmed afterward. That is a planned, change-controlled maintenance task across two teams. Do it in a lower environment first.

One anti-pattern to name and shame: Yes, you can buy yourself time by explicitly setting an account back to RC4 (0x4) -- but don't. That is putting the weak cipher back specifically so the attacker's offline crack keeps working. The whole point of July is to make that impossible by default. Fix the account properly instead of pinning it to the thing being removed.

The reason this lands now

July 14 is a genuinely rough day on the SQL calendar. SQL Server 2016 reaches end of support that day, and the Kerberos RC4 hardening moves into its enforcement phase the same month. For RC4-dependent accounts, MSFT's own framing is the right one to borrow: you have weeks, not months.

This is a calendar problem, not a fire. Calendar problems are the ones you can get in front of. Run the Kerberos query, check your service accounts, fix the stragglers, and let July be boring on the database tier.

More to Read

Microsoft Support: Manage Kerberos KDC usage of RC4 (CVE-2026-20833)
AskDS: What is going on with RC4 in Kerberos? (the at-risk event IDs)
Microsoft/Kerberos-Crypto: detection scripts on GitHub
Microsoft Learn: Detect and remediate RC4 usage in Kerberos

Fast Is Not Ready: What the AI Data Shows

There is a slide making the rounds in my world right now. You have probably seen a version of it. It promises a live AI agent in production, a validated ROI model, and a scale roadmap. Six weeks. Fixed price. The design is clean, the language is confident, and the offer is hard to argue with.

I want to clarify something before I go further. I am not anti-AI. I use it every working day, often inside the very SQL Server work that pays my bills. Where it lands on a real problem with real data, it earns its place at the table. This is not a 'STOP AI!' post.

My concern is more focused, and I think it is harder to dismiss. It is the speed. We are wiring these systems into production faster than we are building the boundaries that production demands. And the reason we are moving this fast is that someone has made moving fast look easy, packaged it up, and put a price on it. That package is worth a hard look before we talk about what it leaves behind.

What the packaging promises

The pitch is consistent across vendors -- A high-value use case, fully deployed. A cost model your CFO can sign. A backlog of the next ten use cases, ready to go. All of it on a timeline measured in weeks rather than quarters, and all of it for a number you agree to up front.

I understand why leaders say yes. It is a clean answer to a messy mandate. When the directive from the top is 'we must do AI now,' a fixed-price sprint to production looks like progress you can put on a slide. The trouble is that the slide and the outcome don't always follow the same path.

The door we are leaving open

Every agent stood up in a hurry is a new door into the environment, and too many of them are being hung without locks -- and the people who make a living finding unlocked doors have definitely noticed. Consider what has already happened, in production, to organizations far better resourced than most.

In June 2025, researchers disclosed a flaw in Microsoft 365 Copilot they named EchoLeak (CVE-2025-32711, rated 9.3 critical). It was a zero-click attack. An outsider sent a single crafted email, and when Copilot did the helpful thing and read it, hidden instructions inside told the assistant to go find sensitive material across OneDrive, SharePoint, Teams and Outlook and quietly ship it out. The victim clicked nothing. There was no malware to scan for, because the payload was plain English. Microsoft patched it and reported no exploitation in the wild, but the lesson should still stand: the assistant became an insider threat, and it never knew it.

Or consider the coding agent that, in 2025, deleted a production database despite instructions not to modify production systems, then produced inaccurate information about the recovery state. You can read about it here. No attacker required. The agent simply had more authority than judgment.

These are not edge cases. The OWASP project that tracks AI security risks used to catalog threats as things that might happen. Its current edition catalogs them as CVEs, vendor advisories and breach reports -- in other words, things that already happened. That is the part the vendor's six-week timeline never mentions. An agent that can read your data and act on your systems is a privileged user, and we are handing out that privilege faster than we are regulating who, what or how, it is managed.

What the data says

MIT's NANDA initiative studied 300 enterprise AI deployments. Roughly 95 percent of generative AI pilots produced no measurable impact on the bottom line. Only about 5 percent reached real, scaled value. I will be fair about that headline. It has been widely cited, though not without criticism of the methodology. But even the people pushing back tend to agree on the underlying point, which is that most pilots stall long before they reach production. You can read the coverage here.

Gartner is more direct, and more relevant, because the slide I described is selling agentic AI specifically. Gartner predicts that more than 40 percent of agentic AI projects will be canceled by the end of 2027. The reasons it gives are "escalating costs, unclear business value or inadequate risk controls." The full prediction is here.

Gartner even has a name for part of the problem, 'agent washing'. The practice of rebranding ordinary chatbots and automation as autonomous agents. By its count, of the thousands of vendors claiming agentic AI, Gartner estimates only about 130 of them are real. Most of what is being sold as an agent is an old tool wearing a new label.

The failures are not about the model

This is the part that should matter to anyone who runs systems for a living. Read those reasons again. Escalating costs. Unclear business value. Inadequate risk controls. Not one of them says the AI is too dumb. The pilots are not failing on intelligence. They are failing on the pieces that were missed: data that was never cleaned, integration that was never scoped, governance that was never written, controls that were never tested.

Those are boundaries, and a six-week, fixed-price sprint to production is, almost by definition, a sprint past those boundaries. You cannot clean the data, prove the ROI, establish governance, test the controls, and build the system all in the same six-week sprint. Something gets deferred. In many organizations, it is the part that was supposed to keep everyone out of trouble. In a regulated environment, the things that get cut are usually the same things that surface in an audit eighteen months later, long after the launch party.

What the 5 percent did differently

Here is the encouraging part of the story. The organizations that got real returns were not the fastest. They were the narrowest. They picked one painful, well-understood problem instead of trying to transform everything at once, and they fixed their data before they pointed a model at it. They also tended to partner rather than build everything in-house, and they often started in the boring back office rather than the flashy customer-facing demo -- where the value was quiet but real.

None of that fits on a six-week timeline, and none of it markets well. Patience is the least sellable quality in anybody's board room. It is also, apparently, the one that correlates with success.

Why I am writing this down

I am not asking anyone to slow the technology. At this point, I doubt anyone could if they tried. I am asking that we let the boundaries keep pace with it. Governance, data quality, risk controls, and a human who can still read the audit trail -- these are not friction. On the evidence above, they are the entire difference between the 5 percent and the 95 percent.

The technology itself is going to be fine. It always is. My worry is for the organizations that bet the timeline before they build the guardrails, because that bill always comes due, and it does not come due on the quarter the slide was presented. Fast is exciting. Fast is sellable. But fast is not the same thing as ready. The organizations that succeed will not be the ones that moved first. They will be the ones that understood a very simple truth: Powerful systems require equally powerful controls.

xp_cmdshell: The Door Is Closed by Default. Keep It Shut.

This year's SQL Server CVEs have a common shape. CVE-2026-21262 (March Patch Tuesday, CVSS 8.8) lets an authenticated, low-privileged login climb to sysadmin over the network. That sounds bad on its own, but sysadmin is not the finish line for an attacker. It's just the on-ramp. The exit ramp is xp_cmdshell, and that is the piece that turns 'they got into the database' into 'what they ran under your service account'.

If you run managed services, you are not patching one instance, you are patching a fleet, and somewhere in that fleet is an instance where this gate is open and nobody noticed. Let's look at the gate and how to verify it is shut across the servers you manage.

The gate is closed by default

Since SQL Server 2005, xp_cmdshell ships disabled. Call it on a clean instance and you get the classic refusal:

EXEC xp_cmdshell 'whoami';

Msg 15281, Level 16, State 1, Procedure sys.xp_cmdshell, Line 1 [Batch Start Line 0]
SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this 
component is turned off as part of the security configuration for this server. A system administrator 
can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 
'xp_cmdshell', search for 'xp_cmdshell' in SQL Server Books Online.

Good. The door is shut as it should be. The problem is how easy the door is to open when you're sysadmin, and how many times it's probably already been opened by some long-departed vendor install script.

Check the current state

Before anything else, find out where you actually stand. sys.configurations tells you both the saved value and the running value:

SELECT name,
       value,
       value_in_use,
       description
FROM   sys.configurations
WHERE  name = 'xp_cmdshell';

Of course, this is my server, so it's 1. That means xp_cmdshell is enabled. 0 would mean disabled. On your servers, if this comes back 1 and you did not put it there, that is an immediate concern.

Why this is a risk

Here is a demo so you can see exactly why this matters. Since my server already shows 1, I'll walk through how it gets opened in the first place. Enabling it takes four lines:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

And now the door is open.

EXEC xp_cmdshell 'whoami';

Look at that closely. The command did not run as the login that called it. It ran as the SQL Server service account. Whatever that account can touch on the host and the network, the attacker can now touch, from a T-SQL prompt, no shell access required. Swap whoami for anything the service account can reach and you understand the rest of the story. The exposure. The risk.

Who runs as what

The execution context depends on who is calling, which is worth keeping straight:

Caller	Command runs as
sysadmin member	SQL Server service account
non-sysadmin (proxy configured)	xp_cmdshell proxy credential
non-sysadmin (no proxy)	Cannot execute

This is why CVE-2026-21262 is more than 'just' a privilege escalation. The climb to sysadmin hands an attacker the first row of that table, and the first row is the host.

Catch it being flipped on

A point-in-time check is fine, but you want to know when the value changed, not just that it is wrong today. Every sp_configure change gets written to the error log. Pull it straight out:

EXEC xp_readerrorlog 0, 1, N'xp_cmdshell';

We're looking for any lines recorded in the log including 'xp_cmdshell'. Mine was already at 1, so I flipped it to 0 to gen the image for this post. The point is that you can see the timestamp when the change was made. For something more durable than the rolling error log, a Server Audit capturing server configuration changes will keep the record where log cycling cannot quietly erase it.

Sweep the whole inventory at once

One instance at a time does not scale when you manage dozens. dbatools turns the same check into a single pass across every registered server:

Get-DbaSpConfigure -SqlInstance $instances |
    Where-Object Name -eq 'XpCmdShellEnabled' |
    Select-Object SqlInstance, ConfiguredValue, RunningValue

Any server where the running value is 1 goes to the top of your review list.

Shut the door and keep it shut

If nothing legitimately needs xp_cmdshell, the cleanup is the same shape as the setup, in reverse:

EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

Beyond that toggle, the boring controls are the ones that hold. Keep the SQL Server service account on a least-privilege footing so that even if the door is opened, the service account is not a domain admin waiting to be borrowed. Do not expose the instance to the internet, because the scanners already know your port is there. And patch the escalation paths, because the whole reason xp_cmdshell is a back half of an attack is that something else got the attacker to sysadmin first.

The door is closed by default purposely. Your job is to keep it closed, or IF it needs to be opened, be sure to close it properly afterward.

Applies to SQL Server 2005 through 2025. xp_cmdshell has been disabled by default the entire time, which means anywhere you find it on was a deliberate act, by someone.

More to Read

xp_cmdshell Server Configuration Option (Microsoft Learn)
xp_cmdshell (Transact-SQL) (Microsoft Learn)
Create a Server Audit and Server Audit Specification (Microsoft Learn)

Kali365: The FBI Just Warned You About Your Azure SQL Login Screen

The FBI put out a PSA this month about a phishing kit called Kali365. And, if you've ever connected to Azure SQL with Entra authentication, you have already stared at the exact screen this whole attack depends on.

To sign in, use a web browser to open the page https://microsoft.com/devicelogin
and enter the code A1B2C3D4E to authenticate.

Look familiar? That is the Microsoft OAuth device code flow. It is legitimate, it is everywhere, and Kali365 weaponizes it without ever touching your password.

What Kali365 Actually Does

It is a subscription service. First spotted in April 2026, sold over Telegram for roughly $250 a month or $2,000 a year, marketed at people who could not write a phishing kit themselves. For that money they get AI-generated lures, automated campaign templates, live targeting dashboards, and the piece that matters -- the OAuth token capture.

Instead of stealing a password, the attacker tricks the victim into completing a sign-in the attacker started. Microsoft then issues access tokens to the attacker's session, already satisfying MFA requirements. The result is access to Outlook, Teams, OneDrive, and other Microsoft 365 resources without ever knowing the victim's password.

Why This Should Make a DBA Twitch

Because you do this on purpose, all the time. Connect to an Entra-backed Azure SQL database with device code auth and SQL Server tells you to go enter a code at a Microsoft page:

sqlcmd -S myserver.database.windows.net -d mydb -G ^
  --authentication-method=ActiveDirectoryDeviceCode

You get a code, you open microsoft.com/devicelogin to type it in, and you are connected. SSMS does the same thing under 'Azure Active Directory - Device Code Flow'. The flag name varies a bit by sqlcmd version, but the muscle memory is identical, and that muscle memory is exactly what the attack is counting on.

Step	You, connecting to Azure SQL	You, getting phished
1	You run sqlcmd / SSMS	Attacker starts a sign-in for your tenant
2	Microsoft returns a device code	Attacker emails you that code
3	You open microsoft.com/devicelogin	You open microsoft.com/devicelogin
4	You enter the code, you get in	You enter the code, they get in

Same page. Same code box. Same real Microsoft domain. But two things change: who started the sign-in and who gets in.

There Is Nothing to Misspell

This is what makes it nasty. Every 'spot the phish' habit we have trained on is about catching a fake. The wrong domain, the off-color logo, the cert warning. Here there is no fake. The page is genuinely microsoft.com. The token grant is genuinely Microsoft issuing a token. The only lie in the entire transaction is the unspoken assumption that you are the one who kicked it off. You are not. The attacker is, and you are politely finishing their login for them.

Hunt It in Your Own Tenant

Want to know if this already happened in your tenant? The Microsoft Graph PowerShell module will tell you. You need the module installed and access to Entra sign-in logs. Available retention periods and reporting capabilities depend on your licensing tier.

# One-time: install the module
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect with just the scope you need
Connect-MgGraph -Scopes 'AuditLog.Read.All'

Now pull the last 7 days of sign-ins and keep only the ones that used the device code flow. I filter client-side on AuthenticationProtocol because the server-side $filter does not reliably support that property across tenants:

$start = (Get-Date).AddDays(-7).ToString('yyyy-MM-ddTHH:mm:ssZ')

Get-MgAuditLogSignIn -Filter "createdDateTime ge $start" -All |
    Where-Object { $_.AuthenticationProtocol -eq 'deviceCode' } |
    Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, IpAddress,
        @{ N = 'City';    E = { $_.Location.City } },
        @{ N = 'Country'; E = { $_.Location.CountryOrRegion } } |
    Sort-Object CreatedDateTime -Descending |
    Format-Table -AutoSize

A clean tenant gives you either nothing or a short list you recognize, with your own admin box connecting to Azure SQL (sample output, values are illustrative):

CreatedDateTime       UserPrincipalName     AppDisplayName              IpAddress      City     Country
--------------------  --------------------  --------------------------  -------------  -------  -------
2026-06-14 09:12:03   dba@contoso.com       Microsoft Command Line ...  203.0.113.10   Cozumel  MX

What you are hunting for is the row nobody can explain. A sign-in no one on your team started, from somewhere you do not operate, often against an app you never deploy:

CreatedDateTime       UserPrincipalName     AppDisplayName              IpAddress      City     Country
--------------------  --------------------  --------------------------  -------------  -------  -------
2026-06-13 02:47:55   finance@contoso.com   Microsoft Authentication..  185.220.101.4  Unknown  RO

Device code flow is something developers and admins use to log in from places a browser cannot easily go. So when a finance mailbox completes one at 3 AM from a country you don't operate in, that is the tell. Nobody on your team started that login. Someone else did, and your user finished it for them.

What To Actually Do

Never finish a sign-in you did not start.

A device code is only safe when you generated it yourself. A code that arrives by email or Teams that you did not ask for is bait, every single time. There is no legitimate reason for someone to send you one in this fashion.

Admins: block the flow if you do not need it.

Microsoft Entra Conditional Access can block the device code flow tenant-wide. Most organizations use it in a handful of narrow spots, so a default block with a tight exception list could shut a lot of this down. If your team only hits device code auth for the odd Azure SQL connection, you might consider whether you even need it enabled broadly.

If you got caught, report it.

The FBI is collecting these at the Internet Crime Complaint Center. Revoke sessions, rotate where you can, and then file.

The convenience that lets you authenticate to a database from a headless box with no browser is the same convenience that lets a $250 kit drain a mailbox. The flow is not the villain. Typing a code you did not ask for is.

More to Read

FBI IC3 Public Service Announcement on Kali365
Bitdefender: Kali365 phishing kit breaks Microsoft 365 accounts, no password required
Arctic Wolf: Token Bingo, don't let your code be the winner
Internet Crime Complaint Center (file a complaint)

Cursed SQL, Part Two: Six Ways NULL Lies to Your Face

A week ago I wrote about six queries that run fine until they don't. Cursed SQL. That one struck a nerve, so here's the sequel. Same idea, but this time NULL is the one villain behind every example, and the three-valued logic that rides along with it.

These queries are worse in a quieter way. They don't run slow. They never throw an error. They just give you the wrong answer every time, and SQL Server never says a word. That is the curse.

First, the One Rule

SQL Server does not deal in just true and false. It uses a three-valued logic system, or '3VL', in which conditions must evaluate to TRUE, FALSE, or UNKNOWN. That third one comes to the table whenever NULL is involved in a comparison because NULL is not a value. NULL is not zero and it does not equal anything -- not even another NULL. Any direct comparison to NULL always evaluates to UNKNOWN. Never TRUE or FALSE. Just UNKNOWN.

That single rule is behind all six curses below. Keep it in your pocket and you'll start to see them coming.

The Setup

An Employee table with a few NULLs planted exactly where real data goes missing. A CEO with no manager, an employee not yet assigned a department, and an employee missing their salary. Simple omissions that happen all the time.

CREATE TABLE dbo.Employee
(
    EmployeeID  INT IDENTITY(1,1) PRIMARY KEY,
    FullName    NVARCHAR(100) NOT NULL,
    ManagerID   INT           NULL,   -- the CEO reports to no one
    Department  NVARCHAR(50)  NULL,   -- some not yet assigned
    Salary      DECIMAL(10,2) NULL    -- some withheld
);

INSERT dbo.Employee (FullName, ManagerID, Department, Salary)
VALUES (N'Dana Reyes', NULL, N'Executive', 250000),  -- CEO, no manager
       (N'Sam Carter', 1,    N'Sales',     90000),
       (N'Priya Nair', 1,    N'Sales',     NULL),     -- salary withheld
       (N'Tom Becker', 1,    NULL,         75000),    -- department not assigned
       (N'Lena Frost', 2,    N'Sales',     82000);

See our data with the NULLs:

Curse 1: NOT IN Hits a NULL and Returns Nothing

You're reporting for HR and you want to know which Departments have nobody assigned yet. So you pass the department values into your query and ask the system which ones don't exist in the Employee table.

-- Which departments have nobody assigned? (ie., the empty ones)
SELECT DeptName
FROM (VALUES (N'Executive'), (N'Sales'), (N'Engineering')) AS d (DeptName)
WHERE DeptName NOT IN (SELECT Department FROM dbo.Employee);

Dana is in Executive, three people are in Sales, and nobody has been assigned to the Engineering department yet. So that's the one you expect in the return, but you get this instead:

Nothing. Why isn't Engineering returned?

Here's the problem, step by step. First, we must recognize that the subquery actually returns every Department value in the table:

One of those values is NULL because Tom has not been assigned a department yet, and that NULL is the entire problem. Here's how NOT IN works: it takes a row's DeptName and compares it to every value in that list with 'not equal' (<>), joining the results with AND. So this:

DeptName NOT IN ('Executive', 'Sales', NULL)

Actually translates to this:

DeptName <> 'Executive'  AND  DeptName <> 'Sales'  AND  DeptName <> NULL

A result to that query only survives if its DeptName is not equal to all of them.

Now walk the Engineering row through it -- the one you actually expected back. For that row, DeptName is 'Engineering'. It is not equal to Executive or Sales, so both comparisons pass... but then it hits the NULL:

'Engineering' <> 'Executive'  ->  TRUE
'Engineering' <> 'Sales'      ->  TRUE
'Engineering' <> NULL         ->  UNKNOWN   (any compare to NULL is UNKNOWN)

TRUE AND TRUE AND UNKNOWN      ->  UNKNOWN

That's what gets you. Engineering genuinely has no employees, so without that NULL in the list, it would have been returned. But remember, TRUE + TRUE + UNKNOWN = UNKNOWN. Not TRUE. A row will only be returned when its WHOLE chain evaluates to TRUE, and that UNKNOWN is why your result came back empty.

Microsoft says so right in the docs: "Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN."

The fix is to stop using equality for this. NOT EXISTS tests for the existence of a matching row, not equality against a list, so a stray NULL doesn't poison it.

-- Fix 1: NOT EXISTS is immune to the NULL trap
SELECT d.DeptName
FROM (VALUES (N'Executive'), (N'Sales'), (N'Engineering')) AS d (DeptName)
WHERE NOT EXISTS (SELECT 1
                  FROM dbo.Employee e
                  WHERE e.Department = d.DeptName);

-- Fix 2: keep NOT IN, but strip the NULLs out of the subquery
SELECT DeptName
FROM (VALUES (N'Executive'), (N'Sales'), (N'Engineering')) AS d (DeptName)
WHERE DeptName NOT IN (SELECT Department
                       FROM dbo.Employee
                       WHERE Department IS NOT NULL);

Both return Engineering. Make NOT EXISTS your habit. It sidesteps this entirely, and often gets you better performance as a bonus.

Curse 2: The Inequality That Silently Drops the Row You Wanted

You want everyone who is not in Sales. Reasonable.

SELECT FullName, Department
FROM dbo.Employee
WHERE Department <> N'Sales';

You expected Dana in Executive and Tom, whose department is not assigned yet, but you get only Dana. Tom vanishes, because NULL <> 'Sales' is UNKNOWN, not true, and his row never qualifies. The employee with no department -- arguably the exact person you were hunting for -- silently falls out of the 'not in Sales' report. The NULL rows fall through the cracks and your data set is incomplete.

Use this method to account for any NULL values, and Tom comes back:

SELECT FullName, Department
FROM dbo.Employee
WHERE Department <> N'Sales' OR Department IS NULL;

Curse 3: The Average That Quietly Skips a Person

This one hands your boss a wrong number that looks completely right. You want the team's average salary -- one figure for a comp review.

SELECT AVG(Salary)   AS AvgSalary,
       COUNT(*)      AS HeadCount,
       COUNT(Salary) AS PaidCount
FROM dbo.Employee;

Five people on the team, but watch the counts. COUNT(*) returns 5 -- every row. COUNT(Salary) returns 4 -- only the rows with a salary. Priya's is NULL, and AVG skipped her, because aggregates ignore NULL instead of treating it as zero. So your 'average' added up four salaries and divided by four, not five. The figure looks fine, but it quietly left a person out.

SQL Server does warn you, exactly once, in a message most tools tuck out of sight:

Warning: Null value is eliminated by an aggregate or other SET operation.

That warning is the entire story. A row was removed from your math and the engine mentioned it on the way out. The point is not that one number is right and the other wrong. The point is that the default decided for you. If a withheld salary should count as zero, say so:

SELECT AVG(ISNULL(Salary, 0)) AS AvgSalary_NullAsZero
FROM dbo.Employee;

Same data, divided by five this time, on purpose. Different answer, and now it's mathematically correct.

Curse 4: One NULL Poisons the Whole String

You want a tidy label for each employee.

SELECT FullName + ' - ' + Department AS Label
FROM dbo.Employee;

Four rows look fine, but what happened to Tom? He came back as NULL. Curious why it didn't come back as 'Tom Becker - ' ? The entire string collapsed to NULL. This happens with the + operator. If any piece is NULL, the whole result becomes NULL. That is CONCAT_NULL_YIELDS_NULL doing its job, and since SQL Server 2017 it is always ON -- you can't turn it off anymore. So a single missing department wipes out the entire label.

The fix is CONCAT, which treats NULL as an empty string instead of a contaminant. Or guard each piece yourself if you'd rather show a placeholder.

-- CONCAT() ignores NULLs, treating them as empty strings
SELECT CONCAT(FullName, ' - ', Department) AS Label
FROM dbo.Employee;

Or you can use a default to show a placeholder:

SELECT FullName + ' - ' + ISNULL(Department, N'(unassigned)') AS Label
FROM dbo.Employee;

CONCAT gives you 'Tom Becker - ' with an empty tail; the ISNULL version gives you 'Tom Becker - (unassigned)'. CONCAT arrived in SQL Server 2012, so it's most likely a non-issue on anything you're running today.

Curse 5: = NULL Is Not IS NULL

You want to list all employees with no department assigned.

SELECT FullName
FROM dbo.Employee
WHERE Department = NULL;

Zero rows. But what about Tom? Remember, Department = NULL means UNKNOWN for every row, including the ones that actually are NULL, because nothing equals NULL. Not even NULL equals NULL. The right tool is the predicate built for the job:

SELECT FullName
FROM dbo.Employee
WHERE Department IS NULL;

Now Tom comes back. Years ago, with ANSI_NULLS OFF, = NULL would behave like IS NULL, but that setting is deprecated and ANSI_NULLS has been forced ON since SQL Server 2017. Don't lean on it. Use IS NULL and trust your results.

Curse 6: The CHECK Constraint That Waves NULL Right Through

This is the sneaky one, and most people don't know it. You add a guard rail to keep salaries positive.

ALTER TABLE dbo.Employee
ADD CONSTRAINT chk_salary_positive CHECK (Salary > 0);

It creates without question or error -- even though Priya already sits in the table with a NULLable salary. That should be your first clue. Now insert a brand new row with no salary at all:

INSERT dbo.Employee (FullName, Salary) VALUES (N'Ghost Worker', NULL);

It goes right in. The constraint you wrote to guarantee a positive salary just accepted a missing one. Here is why: a CHECK constraint rejects a row only when the condition evaluates to false. NULL > 0 is UNKNOWN, not false, so the row is allowed. CHECK treats true and UNKNOWN as the same verdict -- both pass. Your 'salary must be positive' rule quietly permits 'salary is missing entirely'.

The fix is to say what you actually mean. If a salary is required, the column belongs NOT NULL (clean the data first, then alter it). If NULL is genuinely allowed but any real value must be positive, spell that out in the constraint itself:

-- clear the ghost worker record
DELETE dbo.Employee WHERE FullName = N'Ghost Worker';

-- drop constraint 
IF OBJECT_ID('chk_salary_positive') IS NOT NULL
ALTER TABLE dbo.Employee DROP CONSTRAINT chk_salary_positive;

-- clean up the data with null salary
DELETE dbo.Employee WHERE Salary IS NULL;        -- this clears Priya too

-- make column not null
ALTER TABLE dbo.Employee ALTER COLUMN Salary DECIMAL(10,2) NOT NULL;

-- above prevents NULL, this enforces that all values are positive
ALTER TABLE dbo.Employee
ADD CONSTRAINT chk_salary_positive CHECK (salary > 0);

-- Now try that insert again
INSERT dbo.Employee (FullName, Salary) VALUES (N'Ghost Worker', 00000.00)

The lesson holds for every CHECK you write. The constraint does not enforce what you assume. It enforces what evaluates to false. The corrected constraint now blocks zero and negatives, and NOT NULL is what handles the missing values.

In Summary

Six shapes, one root cause. NULL means 'I don't know', 3VL logic is how the engine handles it, and UNKNOWN is the value that falls through the cracks more often than not. None of these throw errors or run slow. They just produce the wrong answers with every call.

The fixes aren't exotic. Pretty simple, actually. Reach for NOT EXISTS instead of NOT IN. Account for NULL on both sides of an inequality. Decide what your aggregates should do with missing values instead of letting AVG decide for you. Use CONCAT over +. Write IS NULL, never = NULL, and remember that a CHECK constraint only ever blocks false. Get those right and the curse lifts. Now you've got six more shapes you can spot on sight.

More to Read

sqlfingers inc: Cursed SQL -- Six Queries That Run Fine Until They Don't
Microsoft Learn: IN (Transact-SQL)
Microsoft Learn: SET ANSI_NULLS (Transact-SQL)
Microsoft Learn: SET CONCAT_NULL_YIELDS_NULL (Transact-SQL)
Microsoft Learn: CONCAT (Transact-SQL)

Miasma. The Worm That Fires When You Open the Folder.

Last Friday, June 5th, GitHub yanked 73 Microsoft repositories offline in about 105 seconds. Not fringe stuff, either. They were repos across the Azure, Azure-Samples, Microsoft and MicrosoftDocs organizations, including Azure/durabletask and Azure/functions-action. The culprit is a self-replicating supply chain worm the researchers are calling Miasma, and this is the part that gets my attention: The payload fires when you open the repository in an AI coding tool or IDE. You don't have to run anything. You don't have to install anything. You just open the folder.

Maybe you're thinking 'I'm a DBA, not a developer, this isn't my problem', but stay with me. I'll explain why your scripts folder is exactly the kind of target this thing was built for.

What happened

An attacker used a previously compromised contributor account to push a malicious commit to the Azure/durabletask repository. The same account had already been used in May to publish three poisoned versions of the durabletask Python SDK to PyPI, so this was strike two from the same stolen identity. The commit didn't poison a package this time. Instead, it planted configuration files inside the repo itself -- the kind of files that AI coding assistants and modern IDEs execute automatically when a project is opened.

Open an infected repo in Claude Code, Gemini CLI, Cursor or VS Code, and a credential-harvesting payload runs immediately. It grabs tokens for GitHub, cloud platforms and developer tooling, then uses those stolen credentials to commit itself into every other repository the victim can write to. That's the worm part -- it spreads on its own, no human required.

GitHub's automated abuse detection caught it and disabled all 73 repositories in two sweeps over roughly 105 seconds. Microsoft has since reviewed and restored them. But the takedown itself caused collateral damage -- Azure/functions-action went dark, and every CI/CD workflow referencing it broke on the spot.

The three waves

Miasma has been active since June 1st, and it's evolving fast. It's a variant of the 'Mini Shai-Hulud' worm that was publicly released in mid-May, and it has already used three distinct attack vectors:

Wave	Date	Vector
1	June 1	Malicious npm packages with preinstall hooks
2	June 3	Malicious binding.gyp files that execute during npm install ('Phantom Gyp')
3	June 3-5	Malicious commits to GitHub repos; payload fires when repo is opened in an AI tool or IDE

Read that closely. Waves 1 and 2 still required an install step, but wave 3 only requires curiosity. Can you even measure the extent of that exposure?

Why DBAs should care

Think about what's sitting in your scripts folder right now. If you're like most working DBAs, you've got clones of community tooling -- dbatools, the First Responder Kit, Ola Hallengren's maintenance solution, plus a pile of your own repos. And increasingly, you're opening those folders in VS Code, or pointing an AI assistant like Claude Code or Copilot at them to refactor a script or troubleshoot a job.

Now think about what's next to those scripts. Connection strings. Saved credentials for dbatools sessions. SQL logins in config files. Azure service principal secrets. A harvested credential from a developer workstation is bad; a harvested credential from a DBA workstation is the keys to the data layer. A worm won't know the difference between a developer's GitHub token and your sysadmin-equivalent service account -- and it doesn't care. It takes everything it can reach.

I should say, this isn't a 'dbatools is compromised' post. None of the SQL Server community projects were among the 73 disabled repos. But the attack pattern is now public, and the worm's ancestor was published openly for anyone to adapt. For years the trust model has been simple -- clone it from GitHub, it's from a reputable org, it's fine. That model just took a direct hit. If Microsoft's own Azure org can host a poisoned commit for two weeks, any repo can.

The mechanics, briefly

Modern IDEs and AI coding tools support automation hooks, driven by configuration files inside the project. They run when a project opens -- VS Code tasks with folder-open triggers, Claude Code hooks, and similar mechanisms in other tools. These features exist for legitimate reasons (auto-build, environment setup), but they mean a repository is no longer just passive text. It can carry instructions that your tooling obeys the moment you open it.

In this campaign, the malicious commit added exactly those kinds of configuration files. Researchers also observed the payload establishing persistence through VS Code tasks and Claude Code hooks, and exfiltrating stolen data through channels like GitHub 'dead drop' repos.

What to do about it

1. Turn off automatic task execution in VS Code

This single setting closes the folder-open execution vector in VS Code. It's prompt-based by default in recent versions, but verify it -- and set it explicitly via settings.json:

"task.allowAutomaticTasks": "off"

2. Inspect before you open

Before opening any freshly cloned repo in an IDE or AI tool, look at it with something dumb first -- plain file explorer, notepad, a directory listing. The files that matter are the automation hooks. A quick PowerShell sweep of your scripts directory:

Get-ChildItem -Path 'C:\Scripts' -Recurse -Force |
    Where-Object { $_.Name -in ('tasks.json','settings.json','binding.gyp') `
        -or $_.FullName -like '*\.claude\*' `
        -or $_.FullName -like '*\.vscode\*' } |
    Select-Object FullName, LastWriteTime |
    Sort-Object LastWriteTime -Descending

You're not looking for these files to never exist. The .vscode folders are everywhere and almost always benign. You're looking for the files you didn't put there, or those with a LastWriteTime that doesn't match when you last touched the project.

3. Get the secrets out of the scripts folder

Maybe this incident is the push you needed. No connection strings, passwords or service principal secrets in repos or alongside them. Use Windows Credential Manager, Azure Key Vault, dbatools' Export-DbaCredential patterns -- or one of the gazillion different password managers out there to keep your passwords secure. Or at least out of the path that a folder-scanning payload could walk.

4. If you opened a Microsoft repo recently, assume exposure

The window of concern runs roughly May 20 through June 5. If you -- or any scheduled job or build server you own -- pulled or even just opened anything from the affected orgs in that window, you should consider rotating the credentials that machine could reach. GitHub tokens, cloud secrets, and yes, any SQL logins whose passwords were stored locally. Check your cloud environments for service principals you didn't create and outbound traffic you can't explain. The fact that this check has become a standard step in Cloud/AI security really should not be missed.

5. Pin your community tooling

Remember that scripts folder full of dbatools, the First Responder Kit and Ola's maintenance solution? This is where the trust-model problem becomes a daily-habit problem. Clone a specific release tag, not main. Review the diff when you update. The convenience of 'git pull and go' is exactly the behavior this worm is engineered to exploit.

The bigger picture

I wrote before about least privilege for AI agents -- the idea that an AI assistant should only be able to touch what it genuinely needs. Miasma is the other side of that same coin. The AI tooling isn't the villain here. The worm exploited automation features, and AI assistants happen to be the newest and most eagerly adopted automation there is. New actors, but the lesson is the same. Every tool that can act on your behalf is a tool an attacker can act through. Scope it down, watch what it opens, and trust none of them by default -- not even the ones from a trusted org.

GitHub caught this one in 105 seconds. The next one might not trip the alarms as fast. Spend the ten minutes on the settings and the secrets cleanup now, while it's a news story and not an incident report with your name on it.

More to Read

StepSecurity: Miasma Worm Hits Microsoft Again
The Register: GitHub nukes 70+ Microsoft repos amid suspected worm attack
The Hacker News: Miasma Worm Hits 73 Microsoft GitHub Repositories
Redmondmag: Supply Chain Attack Hits Microsoft GitHub Repos, AI Coding Tools