What’s the issue?
SQL Server Agent proxies allow job steps to run under a specific Windows account rather than under the Agent service account. Each proxy maps to a credential, which in turn stores the Windows account and password used for the job step, and the proxy is then authorized for specific subsystems such as CmdExec, PowerShell, SSIS, ActiveX Script, and Analysis Services.
Proxies exist so that non-sysadmin principals can be granted the ability to run job steps in those subsystems, which otherwise require sysadmin membership. Access is granted per proxy to specific logins, fixed server roles, or msdb roles.
This finding identifies proxies whose underlying account is a member of the sysadmin fixed server role. The detection compares the credential identity behind each proxy in msdb.dbo.sysproxies and sys.credentials against sysadmin role membership.
Why is this a problem?
Anyone granted use of this proxy can run job steps under an account that can do anything on the server, which is a privilege escalation path. The proxy mechanism is specifically designed to let non-sysadmin users execute job steps, so a proxy backed by a sysadmin account hands full instance authority to principals who were deliberately not given it directly.
The escalation is straightforward to exercise and difficult to detect. A user with proxy access creates or modifies a job step in an authorized subsystem, the step runs under the sysadmin-level account, and the resulting code executes with full privileges. Nothing in the server-level role membership changes, so reviews that only examine sysadmin members will not reveal the exposure.
The subsystems involved make the impact broader than SQL Server alone. CmdExec and PowerShell steps run operating system commands under the proxy account, so if that account also holds local administrator rights on the host, the escalation extends from the database engine to the server itself.
What should you do about this?
Review proxies and their credentials by querying msdb.dbo.sysproxies joined to sys.credentials, then compare each credential identity against sysadmin membership in sys.server_role_members. Capture which subsystems each proxy is authorized for and which principals have been granted access through msdb.dbo.sysproxysubsystem and msdb.dbo.sysproxylogin.
Map each affected proxy to a credential for an account that is NOT in the sysadmin role, adhering to the principle of least privilege. Create a dedicated Windows account for the proxy, grant it only the specific file system, network, and database permissions the job steps actually require, and update the credential to use it with ALTER CREDENTIAL.
Review who has been granted access to each proxy at the same time, and remove any principals who no longer need it.