The Windows Agent No Longer Has to Run as SYSTEM

September 24, 2026 · InfraScout Team

Until now, every Windows agent ran as NT AUTHORITY\SYSTEM. That is the simplest thing that works, and it is also the question every security review of InfraScout eventually asks: why does a tool that mostly reads need the most powerful account on the box?

It no longer has to. On domain-joined hosts the agent can now run as a group Managed Service Account (gMSA) — a domain account whose password Windows rotates on its own, and which holds far less on the host than LocalSystem. Everything the AI runs on that host runs as the gMSA too, so a PowerShell command that would need local administrator rights now fails instead of succeeding. The guide is Run the Windows Agent Under a gMSA.

One Account per Tier, Not One for Everything

A gMSA is a shared credential: every computer allowed to retrieve its password can run as it. That is exactly why the design is one gMSA per tier — domain controllers, member servers and clients each get their own, retrievable only by that tier's computers. A compromised workstation can reach the client tier's account and nothing above it.

The new New-InfraScoutGmsa.ps1 script does the Active Directory side for one tier per run. It is signed and published next to the rollout scripts, and by default it only reads: it prints a plan and every warning that applies, and changes nothing until you add -Apply.

.\New-InfraScoutGmsa.ps1 -AccountName gmsaISMember -HostGroup grpMemberServer -CreateHostGroup

It handles the parts that usually cost an afternoon. It checks the forest's KDS root key and tells you how long you have to wait if one is too new to use. It creates every account AES-only, so a domain hardened against RC4 does not end up with an account its own hosts refuse. It merges into an existing account's retrieval list rather than replacing it. And it refuses retrieval groups that could never be right, like Domain Users or Authenticated Users.

Migrate in Place, Roll Back Cleanly

You do not have to reinstall anything. An enrolled host moves over with one command, and it keeps its identity and certificate — no re-enrollment, no new agent record in the portal:

agent service set-account "CONTOSO\gmsaISMember$" --config "C:\ProgramData\InfraScout\agent-config.yaml"

Before it touches anything, the command checks that the account is actually usable on this host, and names the most common miss when it is not: the host was added to the retrieval group but not rebooted since. If the service will not come up under the new account, the migration unwinds itself and puts the host back on LocalSystem rather than leaving it offline.

New hosts go straight to the gMSA with one more parameter on the rollout script:

.\install-agent.ps1 -Key "bek_…" -ServiceAccount 'CONTOSO\gmsaISMember$' -GrantEventLogReaders

Going back is one command as well. set-account --local-system withdraws every grant the account held — file permissions, the service right, the logon right, and the local group memberships the installer added — not just the account name on the service.

The Agent Tells You What It Can Actually Read

Running with less privilege means some things stop working, and you should be able to see which. The agent already probed its capabilities rather than assuming them; under a gMSA that becomes the whole point.

A new eventlog_security capability says whether the agent's account can open the Security event log. Under LocalSystem it always can. Under a gMSA it can once the account joins Event Log Readers, and the portal shows a Security Log badge on the agent when it does. Performance counters and ETW tracing are probed the same way, and they need Performance Log Users, which is deliberately left as a separate choice because that group can do more than read.

Each agent's details now also show Runs As, the account the process is really running under, read from the process itself rather than from what the configuration claims. And because the capability is a filter like any other, the question answers itself in chat:

"Which domain controllers can't read the Security log?"

Read the Trade-Off First

A shared account has a cost that per-host SYSTEM does not. Because the agent's account may restart its own service (the auto-updater needs that), SYSTEM on one host in a tier can stop and start the InfraScout agent on every other host in that tier, and read their Security logs if the account holds Event Log Readers. The private keys stay out of reach. The guide spells this out before anything else, along with the alternative for hosts where that is not acceptable: give them a gMSA of their own.

There is one habit to learn, too. The gMSA can update the agent's own binary, so on a migrated host, elevated agent commands run from a copy you have verified against the release manifest, not from the install directory. The guide includes a script that does this.

Getting Started

The feature is opt-in and LocalSystem stays the default, so nothing changes until you choose it. Start with a pilot tier, a few member servers, and check that each one shows the gMSA under Runs As and the capabilities you expect before you widen the rollout. At fleet scale, manage the local groups and the Log on as a service right through Group Policy. The guide explains which settings replace a local grant and which add to it.

Questions or feedback? Reach us at info@infrascout.cloud.