Software inventory module

One estate, servers included

The Machine Agent ships with an optional inventory module, off by default. Enabling it lets the agent report this server's inventory — which applications run and how much they are actually used, plus hardware, installed packages, logged-in users, and network facts — into the same governed estate that VerOps Scout feeds from desktops and laptops. A server's nginx and a designer's photoshop.exe land in the same Products grid, the same utilization analytics, and the same dashboards.

As of agent v0.2.0 the module implements the VerOps Scout v0.3 inventory contract (report schema v2): secure enrollment with per-device credentials, central collection policy, and the full collector set — reporting as a server (agentKind=server).

As of agent v0.3.0 it additionally reports OS update posture, in parity with VerOps Scout v0.4 — identical field names and types and identical bucketing, so a mixed fleet of servers and workstations is measured the same way. Like every other collector it is remotely switchable and has its own refresh cadence (default every 6 hours). It reads cached package metadata and local logs only: no network metadata refresh, no installs, no extra privileges. See Update posture.

Enrollment and credentials

The inventory module reports on different endpoints with different auth from the core agent — this is a security boundary, not an accident. The machine connection key cannot authenticate inventory. Preferred setup: mint an enrollment token under Inventory → Agents → "Deploy Scout" and put it in the config; on first start the module exchanges it at POST /api/v1.0/inventory/enroll for a private, revocable device key, persisted in a state file:

Platform	Inventory state file (device credential)
Linux	/etc/verops/machine-agent-inventory-state.toml
Windows	%ProgramData%\VerOps\MachineAgent\inventory-state.toml

Auth precedence, first available wins: device key (X-Device-Key) > enrollment token > ingest api_key (X-Api-Key, ta_live_…). See Enrollment and device credentials for the enrollment model, including revocation.

The Machine Agent still supports api_key. VerOps Scout dropped it in v0.6.0 and now refuses to start if its config names one — the Machine Agent did not change, and stripping api_key out of a working machine-agent config will stop that server reporting inventory. The platform tells the two products apart by an X-Agent-Kind header (machine-agent here, scout there) and applies the restriction only to Scout. An enrollment token is still the better credential on a server, for the same reason it is on a workstation: it is limited-use, and what it yields is revocable per device.

Configuration

[inventory]
enabled = true
enrollment_token = "sce_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # preferred
group = "Servers"              # optional enroll hint: auto-assign to a Group
use_central_config = true      # Groups/Rulesets + policy drive tracking
# state_path = ""              # override the state-file location
# api_key = "ta_live_..."      # org-wide ingest key instead of a token; still
                               # supported here (Scout no longer accepts it)

[inventory.modules]            # local defaults; the central policy wins per-field
hardware = true                # CPU/RAM/disks/GPU/BIOS/chassis
installed_software = true      # dpkg/rpm/registry package list
users = true                   # logged-in users (RDP/SSH sessions)
network = true                 # interfaces/MACs/IPs/gateway/DNS (feeds presence)
patch_posture = true           # OS update posture (v0.3.0; 6h refresh, server-tunable)
                               # cached metadata and logs ONLY - never a network
                               # refresh, never installs, no extra privileges

[inventory.tags]               # free-form tags upserted onto this host's entity
datacenter = "fra1"
rack = "r12"

Environment overrides exist for the secrets (AGENT_INVENTORY_ENROLLMENT_TOKEN, AGENT_INVENTORY_STATE_PATH). Tags set by a human in the VerOps UI always win over agent-pushed tags; the sys: prefix is reserved.

What it reports

Section	On a server
Processes / usage	Running applications and their activity, driven by the same central Groups/Rulesets as Scout
Hardware	CPU, RAM, disks, chassis (reports as a server / VM), BIOS
Installed software	Installed packages via dpkg / rpm / the Windows registry
Users	Who is RDP'd or SSH'd in — the logged-in sessions on the box
Network	Interfaces, IPs, gateway, DNS — host identity is the stable machine id (/etc/machine-id / MachineGuid) plus the DMI serial
Patch posture (v0.3.0)	Package manager, upgradable and security-upgradable counts, reboot-required and last package activity on Linux; build (including UBR), last update installed, pending reboot, Windows Update service state and hotfix count on Windows

Which sections are collected, and the cadence, follow the central collection policy (Inventory → Policy) exactly as for Scout — applied on the next poll, no reinstall.

Its own channel

Endpoint	Purpose
POST /api/v1.0/inventory/enroll	One-time token → device-key exchange (agentKind=server).
POST /api/v1.0/inventory/report	The inventory report (schema v2) — full at heartbeat, delta on change.
POST /api/v1.0/inventory/agent-config	Pull the effective tracking config and collection policy.

Different key: The machine connection key cannot authenticate the inventory endpoints — the module needs its own credential: an enrollment token (preferred) or an ingest key.

Activity model on a server

Because a server has no interactive foreground, its activity tops out at level 2: CPU-active (2), network-active (1), idle (0). It cannot report the foreground-focus signal (level 3) that Scout captures on a workstation. Everything downstream — normalized products, weighted usage, utilization tiers — is otherwise identical. See Machine Agent vs Scout for the full comparison.