This is my first issue created, so I hope I didn't register it incorrectly. 

To make assigning access rights to the Zabbix Agent (C and Go version) easier on Windows, the installation package as well as the --install parameter should also "sid-enable" the service. I will use Zabbix Agent 2 as the example in this issue, but the same goes for the C version. 

When doing this, the service can now be identified as "NT Service\Zabbix Agent 2", a windows Virtual Account that will manage it's own password secretly and automatically. 

This is a feature used by multiple Microsoft products (MSSQL, SSAS, SSRS, Azure Monitoring Agent, IIS et.c.) to avoid having to give "Local System" access into monitored systems. The Virtual Account will have a unique SID per service and computer, so the agent on one server does not automatically gain access to, say, the databases on a different server. 

We can already do this manually after installation by running the following windows command:

sc sidtype "Zabbix Agent 2" unrestricted

After a service restart, you can verify it using:

sc qsidtype "Zabbix Agent 2"

With this configured, I can now delegate access to that specific service, without having to set up a domain service account. So, for example, in MSSQL I can add it as a login using this TSQL script:

CREATE LOGIN [NT SERVICE\Zabbix Agent 2] FROM WINDOWS
GO

And now it is possible to grant the necessary rights needed to monitor MSSQL using the sql plugin. 

DECLARE @zabbixagent nvarchar(128);
SET @zabbixagent = 'NT Service\Zabbix Agent 2';
GRANT SELECT ON OBJECT::msdb.dbo.sysjobs TO @zabbixagent;
GRANT SELECT ON OBJECT::msdb.dbo.sysjobservers TO @zabbixagent;
GRANT SELECT ON OBJECT::msdb.dbo.sysjobactivity TO @zabbixagent;
GRANT EXECUTE ON OBJECT::msdb.dbo.agent_datetime TO @zabbixagent;
GO

In the example of MSSQL, this would allow monitoring of SQL-instances where only windows integrated login is enabled while still not allowing access to every single local service on that computer.

As mentioned, we can already do this after the installation, and it's easily scriptable, but I think it should be the default as there are no real drawbacks and it makes it easier to securely monitor any systems that allow for integrated logons with local windows accounts without having to store credentials in Zabbix.

Here's some examples of how Microsoft themselves use Virtual Accounts for monitoring MSSQL. 

https://learn.microsoft.com/en-us/sql/relational-databases/security/using-service-sids-to-grant-permissions-to-services-in-sql-server?view=sql-server-ver16#examples

https://kevinholman.com/2016/08/25/sql-mp-run-as-accounts-no-longer-required/

I have used this method on many SCOM customers and with no complaints so far from the DBA:s or the SecOps, and we're using it on the customers we're migrating away from SCOM too.