Service accounts across OS families: least privilege for an agent's own background services

What it is

Each OS family gives an unattended process an identity that is not a person's login:

• Linux system users: created with useradd --system and a shell of /usr/sbin/nologin (or /bin/false). The nologin(8) man page documents it as a program that politely refuses login and prints the contents of /etc/nologin.txt if that file exists; the account still owns files and runs processes normally, it simply cannot start an interactive session.
• systemd DynamicUser=: rather than creating a persistent system user at all, a unit can set DynamicUser=yes in its [Service] section. systemd.exec(5) documents that systemd then allocates a UID/GID dynamically for the unit's runtime only, with no persistent account, home directory, or shell to secure; StateDirectory= still gives it persistent, correctly owned storage.
• Windows virtual accounts: identities of the form NT SERVICE\<servicename>, auto-managed by the OS with no password to store or rotate, documented by Microsoft as an option alongside the traditional Local System/Network Service/Local Service built-in accounts.
• Group managed service accounts (gMSA): an Active Directory-managed account whose password is generated and rotated automatically by AD and retrievable only by the specific machines authorized for it, documented in Microsoft's gMSA overview — the domain-joined equivalent of a virtual account for services that run on multiple machines or need domain access.
• macOS daemon users: launchd-managed daemons commonly run under dedicated system UIDs in the reserved low range rather than a real login user, configured through the daemon's launchd property list rather than through a shell login.

Why it matters

An agent that installs its own background service (a scheduler, a webhook listener, a sync daemon) inherits whatever account it is launched under. A service run as a normal admin or "the deploying user" account carries that account's full file access and, on Windows, its network credentials — far more than the service needs. Each of the mechanisms above exists specifically to avoid that: no interactive login, no long-lived hand-managed password, and often no persistent identity to clean up at all.

How to apply

• On Linux, prefer DynamicUser=yes (with StateDirectory= for data it must keep); fall back to a --system user with nologin when files outside systemd-managed directories need a stable UID.
• On Windows, a service created with sc.exe create or New-Service runs as LocalSystem unless told otherwise, so set NT SERVICE\<name> explicitly. A virtual account reaches the network as the computer account; use a gMSA when the service needs its own domain identity or runs on several hosts, rather than a shared domain account with a static password.
• On macOS, run background agents as a dedicated daemon user through launchd rather than as the interactively logged-in user.
• In every case, grant only the specific file, network and API permissions the service needs, not the permissions of whoever installed it.

Pitfalls

• Assuming nologin prevents the account from running processes at all — it only blocks interactive shell login; cron, systemd and su -s can still execute commands as that user.
• Leaving a gMSA's authorized-computer list broader than the machines that actually run the service.