Agent Management is where you deploy the SITEY endpoint agent, prove each host’s identity, and keep the fleet healthy. The agent is a small Python service that runs on Windows and Linux hosts inside your network. It checks in on a schedule, sends inventory snapshots of what is actually installed, and executes the remediation jobs your team has approved. This module is the control surface for all of it: download packages, see who is online, label critical machines, and manage agent versions.
The problem
Without an agent on the host, you only know what a scanner can see from the outside. Credentialed scanning means distributing service credentials to every subnet and hoping nobody copies them. The asset list drifts: a server is reimaged, picks up the same DHCP address, and now two rows claim the same machine. Somebody disables a service by hand and no record of it exists anywhere.
Then come the questions nobody can answer quickly. Is that host offline, or is it busy installing a 900 MB cumulative update? Which machines are still running last quarter’s agent build? Did the patch actually land, or did the job die halfway and never report back? Teams end up maintaining a spreadsheet next to the security tool, and the spreadsheet is wrong within a week.
How it works
- Download a pre-configured package
The Agents page offers a Windows and a Linux download. Your backend URL is written into the package’s config.json at download time, so there is nothing to type during installation. The Windows package is a ZIP with a PowerShell install script that copies the agent, registers it to start at boot under the system account, and restarts it if it stops.
LimitationBuilding a single-file installer instead of the ZIP package requires the optional MSI and NSIS packaging tools to be installed on the server.
The Linux package installs a systemd unit with Restart=always, so the agent comes back after a reboot or a crash.
- Each agent gets its own secret
On first run the agent registers and receives a unique secret; the server stores only a hash of it. Every later call, check-in, inventory, job pickup, must prove that specific secret. If a host re-registers (config restored, installer run twice), the existing row is updated instead of a duplicate being created, and the request is rejected with a 403 unless it can prove the original secret. A machine whose row was soft-deleted is revived rather than silently orphaned. The agent rotates its own secret on a seven-day cycle.
- Check-in, and a liveness model that knows the difference between dead and busy
The agent checks in on an interval (600 seconds by default) with ±20% jitter so a large fleet does not arrive in one burst. Check-in runs on its own thread, separate from job execution, so a long-running patch does not make a healthy host look dead. Liveness combines three independent signals, the last check-in, the heartbeat of an in-flight job, and the open push connection:
State What it means online Fresh check-in or an open push connection busy Check-in is late, but an active job is still sending heartbeats stale A known agent with no fresh signal at all unreachable No agent, or no signal ever seen Only stale and unreachable count as real unreachability. A busy host keeps its work instead of having it parked.
- Inventory snapshots, stored as history
Roughly once a day (configurable), the agent collects a low-noise inventory.
On Windows that is installed software, installed updates and pending-reboot state, services, listening ports, runtimes such as .NET and Visual C++ redistributables, update policy including WSUS and Windows Update for Business settings, and security posture: Defender status, firewall profiles, Secure Boot, BitLocker and RDP configuration.
On Linux it is dpkg or rpm packages, pending updates from apt, yum or dnf, systemd services, listening ports, and posture: ufw, iptables or nftables, SELinux or AppArmor, and fail2ban.
Each collection is stored as a new snapshot, so you can list the history and diff any two of them, including the snapshots taken around a specific patch job.
- Job execution with leases and crash recovery
Approved jobs are delivered over a push connection with polling as a fallback. Each job is leased, heartbeated while it runs, and written to a local journal so an agent that is rebooted mid-job can recover and report its result instead of leaving the work in limbo. A separate read-only channel lets automated triage ask the host fixed, allowlisted questions, service state and listening ports on both platforms, and on Windows also registry values, firewall profiles, audit policy and local accounts, without running free-form shell commands.
- Fleet version control
Every agent reports its build, and the agent list badges anything that does not match the server’s current version. An administrator publishes a new version from the server, behind a separate publishing password. The server only offers an agent a build that is newer than the one it reported, and the agent verifies the package’s SHA-256 against the manifest before installing it, refusing the package outright if the hash is missing or does not match. On Windows hosts you can additionally enable an HMAC signature on the manifest, using a key that never travels over the network, so a tampered update cannot be forced onto those agents.
What you can do
Download Windows and Linux agent packages with your backend URL already embedded.
See agents, agentless discovered hosts and domain assets in one list, with search, OS/status/type filters, sorting and pagination.
Open any host and read its full profile: hostname, primary and secondary IPs, MAC addresses, OS build, architecture, last check-in and agent build.
Browse installed software, services, listening ports, pending updates and security posture per host, plus runtimes and update policy on Windows hosts.
Compare two inventory snapshots to see exactly what changed on a machine, including around a specific job.
Mark a host as exempt from autonomous action, set its criticality (normal, high, critical) with a written reason, and label it as test, staging or production, an administrator-only change that is written to the autonomy audit log.
Spot hosts whose agent build is behind, and publish a new agent version from the server behind a separate publishing password.
See at a glance whether a host reports that it can take a restore point before risky work, and whether it has a known scan-access problem.
Leave threaded comments with reactions on a host, so context lives next to the asset instead of in chat.
Deactivate agents individually or in bulk while keeping their vulnerability and scan history; permanent deletion is a separate, explicitly confirmed, administrator-only step.
Who it is for
Get a deployable package and a single page that answers what is installed on this machine and when did it last talk to us.
Get host-level evidence, services, ports, posture, running builds, attached to the findings they are triaging.
Get an identity model they can defend: per-host secrets, rotation, and gates that stop one leaked installer secret from letting somebody overwrite another machine’s record.
Get a defensible answer to auditors about which assets are monitored, which are deliberately exempt from automation, and why.
Why it matters
Agent coverage is the difference between guessing and knowing.
A network scan tells you a port is open; an agent tells you the exact package version, whether the fix is already installed, and whether the machine is waiting on a reboot. That collapses the triage conversation from days of back-and-forth with server owners into a snapshot you can read in seconds.
It also removes a standing risk. Credentialed scanning pushes privileged accounts into every corner of the network; a per-host agent with its own rotating secret and an allowlisted read-only query channel does the same reconnaissance without that exposure. And because inventory is versioned, the question “what changed on this box last Tuesday?” has an answer instead of a theory. Which is the difference between an informed decision and a war room.
Finally, it makes automation safe to switch on. The exemption flag, the criticality label and the test/staging/production tag are how you keep the domain controller and the billing server out of scope while the rest of the estate patches itself.
Works with
- Asset Inventory, agent-reported hosts join discovered hosts and domains in one asset picture
- Patch Management, the agent is what actually picks up, executes and reports approved patch jobs
- Autonomous Operations, liveness state, exemption flags and environment labels decide what automation may touch
- Group Management, group agents to scope scans, policies and rollouts
Frequently asked questions
Does the agent need internet access?
No. The agent talks only to the SITEY backend URL that was embedded in its package, which is a server inside your own infrastructure, and it downloads patch artifacts from that same server. Installing an operating system update still uses the update source the host already has, your WSUS server, your distribution mirror or the vendor, so that part of your network design does not change. No information about your hosts is sent anywhere outside your own server.
What stops someone from impersonating an agent?
Each agent holds its own secret, and the server keeps only the hash. Once a host has established its identity, its record can be updated only by a request that proves that host’s secret. A request that cannot prove it also cannot open a new record claiming a live host’s IP address. Registration and check-in endpoints are rate limited, and the agent rotates its secret on a weekly cycle.
What happens if a host is offline during a job?
Jobs are leased rather than fired and forgotten. If the agent stops heartbeating, the work is not silently marked done. When the agent comes back, it reads its local journal, recovers any job that was interrupted, and reports the outcome. A host that is slow because it is mid-install is classified as busy, not offline, so its work is not taken away from it.
Can I keep certain servers out of automated remediation?
Yes. An administrator can mark any host as exempt from autonomous action, record a reason, set its criticality, and label it as test, staging or production. Unrecognised labels are rejected rather than quietly defaulted, and the change is written to the autonomy audit log.
How do I upgrade agents across the fleet?
Publish the new version from the server, an administrator action protected by a separate publishing password. Agents learn about it on their next check-in and verify the package hash against the manifest before installing anything. The server only advertises a build that is newer than the one an agent reported. Updates move forward only, so validate a build before you publish it to the fleet.
Agent Management is part of every SITEY deployment. You install it in your own infrastructure, and the agents report to your server and nowhere else. See pricing to get the agent packages and start bringing your hosts under management.