New Permissions in SQL Server 2025

This article provides a brief overview of the new permissions introduced with SQL Server 2025 and the few adjustments to existing ones.

Overall, the changes are subtle – which is not surprising. The past couple of years have focused heavily on SQL Database in Fabric, Entra ID integration, and incremental improvements rather than major changes to the core permission model.

All newly introduced permissions are tied to new functionality. The underlying permission model itself remains unchanged since its last significant evolution in SQL Server 2022.

If you haven’t explored those changes yet, I recommend revisiting:

New Permissions in SQL Server 2025

The following permissions have been introduced:

Class Permission name Covering permission name Parent class Parent covering permission name
DATABASE CREATE EXTERNAL MODEL ALTER ANY EXTERNAL MODEL SERVER CONTROL SERVER
DATABASE ALTER ANY EXTERNAL MODEL CONTROL SERVER CONTROL SERVER
DATABASE ALTER ANY EXTERNAL MIRROR CONTROL SERVER CONTROL SERVER
DATABASE ALTER ANY INFORMATION PROTECTION CONTROL SERVER CONTROL SERVER
EXTERNAL MODEL VIEW DEFINITION CONTROL DATABASE VIEW PERFORMANCE DEFINITION
EXTERNAL MODEL ALTER CONTROL DATABASE ALTER ANY EXTERNAL MODEL
EXTERNAL MODEL TAKE OWNERSHIP CONTROL DATABASE CONTROL
EXTERNAL MODEL EXECUTE CONTROL DATABASE EXECUTE
EXTERNAL MODEL CONTROL DATABASE CONTROL

What’s worth noting here is consistency:

The distinction between reading metadata and modifying objects is applied cleanly.

We see:

  • VIEW DEFINITION → read metadata
  • ALTER → modification
  • CONTROL → full ownership

This aligns with the model introduced in SQL Server 2022 and continues to support a structured approach to Principle of Least Privilege (PoLP).

Important New Behavior: EXECUTE Covers AI Models

One detail that can easily be overlooked:

Anyone with EXECUTE permission at the database level can execute AI models (if they exist).

Those of you using a custom db_executor-role, keep that in mind.

If you grant:

GRANT EXECUTE TO db_executor;

You are now also granting access to external AI models. And there is no simple way to exclude those objects.

I really wish Microsoft would introduce object-type granularity. That would also help for view-based access.

There is at one small mitigating factor:
To actually use the model, REFERENCE permission on the associated credential is also required.

Did I say execution?

Technically, to use external models in SQL Server 2025 there is a function and hence it is a SELECT.

SELECT AI_GENERATE_EMBEDDINGS(N’Test’ USE MODEL MyAzureOpenAIModel);

Changes to Existing Permissions

There are a few minor adjustments to existing permissions:

VIEW PERFORMANCE DEFINITION and VIEW SECURITY DEFINITION cover additional objects.

For example: Availability Group metadata is now available with VIEW PERFORMANCE DEFINITION

These are incremental improvements and only noticeable in specific scenarios.

One more change, that was implemented with SQL Server 2025 CU1:

DBCC STACKDUMP now requires sysadmin-membership. Previously, ALTER SERVER STATE was sufficient.

This change slightly reverses progress toward least-privilege operations.

Instead of using targeted permissions such as:

  • VIEW SERVER SECURITY STATE
  • VIEW SERVER PERFORMANCE STATE
  • Extended Events permission

…you need full sysadmin-membership for certain (admittedly rare) troubleshooting scenarios.

As a result, the number of commands that require sysadmin, documented here: The challenges for least privilege: When sysadmin is still required in Microsoft SQL Server – grows by one more item.

The bigger issue is the boundary this removes:

How so?

Whoever initiates the stack dump will also need access to the file system to retrieve it.

In theory, this could be handled via separation of duties (a separate person with File-System access).

In practice, once someone is sysadmin, that same person can also enable xp_cmdshell, access the file directly, and move beyond SQL Server scope.

In other words, what started as a troubleshooting task within SQL Server can easily extend into the operating system layer.

That is why I would prefer a dedicated permission – something like:

GRANT CREATE DUMP TO Login

All in all, the changes are subtle. What matters, is how they play out in real environments. And that we shall see 🙂

Andreas

Links to concepts explained in this article:

Using Extended Events for Tracing SQL Server and Azure SQL DB in compliance with Principle of Least Privilege – Example role separation

New granular permissions for SQL Server 2022 and Azure SQL to improve adherence with PoLP

Principle of Least Privilege (POLP)

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *