Data Collection & Required Privileges
A security-review reference for how the Hermes agent gathers data on Windows and Linux, which service account it runs under on each platform, and the operating-system privileges collection actually requires. For what is collected and the query API, see Inventory and Built-in Collectors.
Data-collection methodology#
Hermes is an agent that runs locally on each managed endpoint. It collects inventory in discrete modules, each streamed to the server over the agent's outbound gRPC channel as it completes. The agent connects outbound to the server's agent gateway (default port 8444) — there is no inbound listener on the endpoint. How it reads the data differs by operating system.
On Windows
Collectors read from local Windows subsystems — no third-party tooling is installed on the endpoint:
| Source | Used for |
|---|---|
| WMI (Windows Management Instrumentation) | OS, computer system, BIOS/enclosure, processors, physical memory, disks, network adapters, TPM, services, hotfixes, optional features, local groups |
| Registry (HKLM) | Installed software (the Uninstall keys), server-OS product type, pending-restart detection |
| DISM | Windows optional features and roles |
| Performance counters | Live CPU / memory / disk metrics |
Windows Update Agent + wsusscn2.cab | Offline (air-gap-friendly) missing-update scanning — see Windows Update Management |
On Linux
Yes — Hermes has a native Linux agent (a systemd service). Linux collection reads standard kernel/pseudo-filesystem paths and shells out to common system utilities. Windows-only sources (WMI, the registry, DISM, Windows Update/WSUS) do not apply and those modules are simply not collected on Linux.
| Area | Source on Linux |
|---|---|
| OS identity / kernel | /etc/os-release, /proc/version |
| Processors | /proc/cpuinfo |
| Memory | /proc/meminfo; per-DIMM slot detail via dmidecode -t memory |
| Hardware / BIOS / chassis / UUID | /sys/class/dmi/id/; dmidecode for SMBIOS detail |
| Storage & volumes | lsblk, df, /sys/block/; disk SMART health via smartctl |
| Network | ip (link/addr), /sys/class/net/ |
| Installed packages | dpkg-query (Debian/Ubuntu), rpm -qa (RHEL/Fedora), pacman -Q (Arch) |
| Services | systemctl (systemd units) |
| Boot security | /sys/firmware/efi (UEFI), /proc/cmdline, DMI |
| Shares | Samba configuration and NFS exports (/etc/exports) |
| Local groups | /etc/group (with /etc/sudoers to flag privileged groups) |
How the agent runs on each OS#
| Windows | Linux | |
|---|---|---|
| Runs as | Windows Service HermesAgent | systemd unit hermes-agent.service |
| Service account | LocalSystem (NT AUTHORITY\SYSTEM) | root by default |
| Startup | Automatic at boot | Enabled at boot (systemctl enable) |
| Install | MSI installer | install.sh (must be run as root) |
| Data directory | %ProgramData%\Hermes | /var/lib/hermes |
On Linux the shipped hermes-agent.service unit runs the agent as root
(the User=/Group= lines are present but commented out in the unit template).
The agent hardens its own data directory: %ProgramData%\Hermes is ACL-restricted to
LocalSystem + Administrators on Windows, and /var/lib/hermes is set to 0700
on Linux.
Privileges required for collection#
Windows
The agent runs as LocalSystem, which has the access needed to read every built-in collector's data (WMI, HKLM registry, DISM, performance counters, and the Windows Update Agent for offline scans). No separate service account or domain account has to be provisioned for inventory collection.
Linux
The agent is installed and runs as root. Full inventory collection is designed around that: some sources are world-readable, but a few require root. If you were to run the agent as a non-root user, those root-only items would be unavailable while the rest would still be collected.
| Collection item | Privilege |
|---|---|
/etc/os-release, /proc/*, /sys/class/dmi/id/, /etc/group | None (world-readable) |
Packages (dpkg-query / rpm / pacman), df, ip | None (standard user) |
Per-DIMM memory detail (dmidecode) | Root — SMBIOS access |
Disk SMART health (smartctl) | Root — direct device access |
Privileged systemctl operations | Root / sudo |
Without root on Linux, per-DIMM SMBIOS memory detail (dmidecode) and disk SMART health
(smartctl) are unavailable — the agent falls back to /proc/meminfo for memory totals —
and privileged systemctl actions are denied. The shipped install runs as root so all of
this is collected.
Deployments & remote commands#
The same service account that collects inventory also runs software deployments and remote commands — LocalSystem on Windows and root on Linux — which is why those run with full local privilege. On Windows, deployment steps can optionally execute under specified user credentials (a "run as" account) instead of LocalSystem. The gateway only accepts these operations from authenticated, authorized server requests over the mutually-authenticated gRPC channel; see Certificates & PKI.