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 granular permissions for SQL Server 2022 and Azure SQL to improve adherence with PoLP
- Revamped SQL Permission system for Principle of Least Privilege and external policies – internals
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:
New granular permissions for SQL Server 2022 and Azure SQL to improve adherence with PoLP


Leave a Reply
Want to join the discussion?Feel free to contribute!