Sentinel Host agent: requirements and operations

Supported platforms, network and privilege requirements of the Sentinel Host agent, the data it collects, how it protects the performance of each machine, and how the fleet stays tidy.

The WASViking Sentinel Host is the agent of Infrastructure Defense. It runs as a system service on each machine, reports a security posture inventory over mutual TLS, and runs the changes you approve in Resolve. This page covers what it needs, what it collects and how it behaves on a busy host.

Supported platforms

The install command comes from the install page of an activation key and carries the key, so it registers the host and starts the service in one step. The setup guide walks through it.

Network

The agent connects out to the WASViking cloud on port 443 and does not listen for inbound connections.

Mutual TLS cannot pass through a device that re-signs TLS traffic, so these domains must be excluded from TLS inspection. Endpoint protection exclusions lists the domains, folders and processes to exclude, product by product. A site with no route to the internet relays its agents through a Sentinel Gateway.

Privileges

The agent runs as LocalSystem on Windows and as root on Linux and macOS. It needs those rights to read the security configuration of the machine and to install the updates and changes a job names. A host can refuse scripts in its local configuration.

What the agent collects

The inventory covers the operating system and kernel, installed packages, running services and listening ports, pending updates, and security configuration such as the firewall state and the SSH hardening options. It also carries the machine facts an operator expects on an asset record: naming (FQDN, DNS hostname, and on Windows the NetBIOS name), IPv4 and IPv6 addresses, manufacturer and model, processor and total memory, fixed volumes with free space, and the local account names as the operating system reports them.

The agent reads posture only. It does not open user files or content, and account names are collected without any profile data or per-user activity.

Performance and resource protection

Performance and resource protection is part of the host policy. It states how much of a host the agent may take and when it must step aside: a share of the CPU of the machine (a hard cap through the systemd control group on Linux and through a job object on Windows, a scheduling priority on macOS), the inventory and check-in cadence, reduced scheduling priority for the agent and every subprocess it spawns, and a daily reduced activity window in the host's own local time. Three presets cover the usual cases: conservative for critical production, balanced for the fleet at large, performance for development and test; custom exposes every number.

Beyond the static limit, the agent looks at the host before every scheduled assessment and before every patch job. A host above the CPU or memory thresholds of the policy, or under critical load, is left alone. The assessment waits and looks again every ten minutes, up to the policy maximum, then runs anyway at reduced priority so coverage does not lapse in silence. A patch job goes back to the cloud as deferred, is offered again a quarter of an hour later, and fails visibly, with the numbers in the note, if the host does not calm down inside the maximum wait. A busy reading is confirmed on two more looks a few seconds apart before anything is held, so a short spike does not postpone work on its own.

Each asset page shows what its agent reports: the profile revision it applies, how the platform enforces it, the load it measured at its last check-in and any work on hold. Agents from release 0.1.34 apply the profile; older agents follow its inventory cadence only. From release 0.1.53 the agent measures the load at every check-in and confirms a busy reading before holding work; earlier releases show the reading of their last assessment or job.

Fleet hygiene

Fleet hygiene keeps the agent list honest without anyone tidying it. The monitored hosts allowance counts assets that reported, not enrollment attempts. An installer that cannot reach the cloud stops before registering and names the product in the way; an enrollment that registered but did not send its first inventory raises one alert with the check to run and the exclusions to apply; a token left unused expires; and when a machine finally reports, the earlier enrollments of the same hostname that did not complete are retired on their own.

The Sentinel Hosts screen flags what needs attention (never reported, token never used, duplicate hostname, silent for a week), offers a one-click removal of the incomplete enrollments of a hostname, and lets you set the housekeeping windows: how long a silent host is kept, how long a token lives unused, and how soon a missing first inventory is announced.

Updates

Enrolled agents update with one click from the console. On a site with a Sentinel Gateway, each agent release is downloaded once and served to every host of the site from a verified store.