The Zonitix Agent (Mac / Win / Linux)

A small agent that runs on a workforce machine and reports its own inventory and security posture to your instance on a schedule. Each build carries a Zonitix release signature that your instance checks before hosting it.

It is the reporting layer that keeps the device inventory current — instead of a serial number typed in once, each machine reports its own truth every check-in.

Availability By Platform

Three Platform Layers

Supported Operating Systems

The Zonitix platform is browser-based — your team uses it from any operating system, with nothing to install. Only the optional agent has OS requirements; a machine without it can still have a record in the device inventory, created by an administrator through the API.

What The macOS Agent Reports

Each check-in carries a fixed, inspectable set of inventory and posture fields — the complete list is below. The agent applies no hardening setting and runs no command unless an admin starts it: a hardening profile the machine is in scope for, or a queued remote command (both described below). It updates itself only to a version your administrator has adopted. There is no running-process list, no keystroke or screen capture, and no location tracking.

One limit: if the system’s update tool does not answer within a minute, the agent reports no pending updates, not “unknown”.

It is not an Apple MDM: it installs no Apple configuration profiles and it never wipes a device. What an admin can ask it to do is a short, fixed list — lock the screen, restart, install OS updates, rename the computer, or uninstall itself — covered under Remote commands below.

What The Linux Agent Reports

The Linux agent collects a deliberately smaller set than macOS: machine facts, installed packages, pending updates and a focused security posture. It does not yet collect SSH/remote-access, local-admin accounts, or uptime — those are planned. A security probe that can’t run reports nothing rather than a false value, so your instance can tell “unknown” from “off”. Two limits: the firewall check looks at ufw and firewalld only, so a machine protected another way reads as off, and with neither apt nor dnf on the machine the pending-update check reads “none”. The Linux and Windows software lists are capped at 2,000 entries each, like the macOS one.

What The Windows Agent Reports

A focused set: machine facts, installed software, pending Windows Updates and three posture signals. It does not yet collect TPM state, local-admin accounts, or remote-access (RDP) status. One limit: if Windows returns an error when BitLocker or Microsoft Defender is read, the agent reports that one as off, not as “unknown”.

If the drive is already BitLocker-encrypted, the agent also escrows its recovery key to your instance over the signed channel, where it is stored encrypted at rest.

Enrollment & Check-In

In plain terms: the first time the agent runs it registers the machine with your instance and creates its own identity key, whose private half never leaves that machine. After that it checks in every 15 minutes by default, proves each report came from that machine, and picks up any settings or commands waiting for it. The three steps, with the calls the agent makes, are under Technical detail below, and the byte-level specification is on Fleet Policy & Agent Signing.

What The User Sees

On macOS, a menu-bar item whose icon reflects health. Its dropdown shows this Mac (model, chip, macOS, serial, memory, disk), available software updates with an Install action, and a fleet section (which instance it reports to, last check-in, device ID, and whether the signing key is held in the Secure Enclave). If the daemon is doing the work, the menu-bar app is just a viewer — closing it stops nothing.

On Linux there is no GUI. The agent is a headless systemd service: an admin checks its status, follows its log, and can print exactly what it would report at any time, with the service commands listed under Technical detail below.

On Windows, a background service does the work, with a system-tray app and a status panel (model, OS, device ID, last check-in, reporting-to host, health). An admin manages the service through the Windows Service Manager and reads its logs; the tray app is just a viewer.

Endpoint Hardening (Enforcement)

Reading posture is the default. Add controls to a profile in Devices → Profiles and the agent enforces them on the devices in that profile’s scope, using native tooling as root or SYSTEM — no MDM required — and corrects drift on each check-in. Several of these settings are mapped to SOC 2 and HITRUST controls; the Compliance coverage view on the Profiles page shows which. It is opt-in per control: no hardening setting is applied to a device no profile covers. The agent never changes two things: SSH settings on Linux, which it only writes to the machine’s own log, and Windows BitLocker, whose state it reports. Disabling a profile stops the agent applying it; settings already applied stay as they are.

Enforcement changes device configuration only when an admin puts the device in a profile’s scope. It is not MDM — no Apple configuration profiles and no device wipe (those are the separate Apple MDM below).

Apple MDM (Preview)

Separate from the agent, Zonitix runs a managed Apple MDM — built on the open-source NanoMDM engine — for the controls only Apple MDM provides: enrollment, configuration profiles, and remote lock/wipe. Unlike your instance, it is one Zonitix-hosted service shared across customers, with each customer’s devices in a separate tenant.

Deploying The Agent

Every platform enrolls with your instance’s reusable enrollment token. You don’t generate it: the Linux and Windows install commands in Devices → Add devices carry it, and a Mac receives it from a device-management profile or from a package built for your instance. It is one token for all three platforms. It expires after 90 days and your instance replaces it automatically in the last 14 days before expiry, leaving the old one valid until it lapses so installers already handed out keep working. An admin can also rotate it by hand in Devices → Settings if it leaks: that revokes the old token at once for every platform. The one-line Linux and Windows install commands keep working, because they download the install script fresh each time and it carries the current token; an install script or installer that was saved or pushed through another tool earlier carries the old token and must be fetched again. Already-enrolled devices are unaffected. The agent presents the token once at enrollment, then authenticates every heartbeat with its own key. A machine enrolling for the first time lands as Pending approval — visible, but not trusted until an admin approves it, on its Inventory row or in the device’s detail view. Step by step: the enroll a device guide. The install command for each platform is under Technical detail below.

Who Does What

The agent is a shared responsibility: you deploy and govern it, Zonitix hosts the control plane and verifies everything cryptographically. Agent reports go to your single-tenant instance only; the one thing that reaches us is a count of devices per agent version, in the licence check-in. Apple MDM, if you use it, is the exception: it runs on the shared Zonitix MDM service described above.

Operating The Fleet

Remote Commands

An admin who can manage devices can queue a command from a device’s detail view, or for many devices at once from the inventory. The agent picks it up at its next check-in, so a command is never instant and an offline machine waits. Every command is audited, each device keeps a command history, and a command can be cancelled while it is still queued. All five can be queued for macOS, Linux and Windows; on a Mac, Lock screen is the exception described below.

The wait has a limit. A command still queued after 7 days is marked expired, which is audited, and has to be queued again. Retiring a device, rejecting its enrollment or deleting it cancels everything queued for it, which is audited too, and so does re-enrolling the machine, so a rebuilt computer never runs a command meant for its previous life. One bulk request takes at most 500 devices; the dashboard sends a larger selection in batches. The written reason for a destructive command must be at least 3 characters; anything past 500 is cut off.

The agent has no wipe command on any platform. Erasing a Mac is an Apple MDM action, described under MDM & Device Operations.

Removing The Agent By Hand

The remote uninstall needs the machine to check in. For one that is offline, off the network or being retired, Devices → Settings has an Uninstall section per platform, whose Uninstall the agent card gives a command to copy and run on the machine itself. The machine stops reporting as soon as it runs. This removes software only: retire the device record separately (see Device lifecycle).

Device Lifecycle

Retiring a device and uninstalling its agent are separate. Uninstall removes the software from a machine; retire tells your instance to stop trusting a device, whether or not the agent is still on it.

New-Hire Computers (Reservations)

In plain terms: when onboarding starts for someone whose hardware checklist includes a laptop or desktop, Zonitix holds a place for that computer in the inventory, owned by the new hire, before the machine exists on the network. When the real machine enrolls, the placeholder becomes the managed device. Monitors, keyboards and other accessories are not reserved; they stay ticks on the onboarding checklist.

The audit actions written for a reservation, and the routes behind the suggestion, are under Technical detail below.

Software Inventory

Devices → Software lists every application the agents report across the fleet, grouped by title with its versions and the number of devices that have each. What an agent lists is the Applications folder on a Mac, the programs registered with Windows, and the dpkg or rpm packages on Linux, up to 2,000 per device. Open a title to see which devices have it, search the list, or export it as CSV (the export is audited). A smart device group can also target devices by installed application, so a profile or rollout can be scoped to “every machine with this app”. It is an inventory: the agent reports what is installed and does not install or remove applications.

Alerts, Trends And Compliance Rules

Set in Devices → Settings. Alerts go by email to everyone who can manage devices, one message per alert type per check rather than one per device, and a condition that stays true is reported once, not repeatedly. If email is not set up, alerts are still recorded in the dashboard.

If something here is not working as you expect, start with When something goes wrong.

The Three Steps Of A Check-In

The calls behind Enrollment & Check-In above. The byte-level specification is on Fleet Policy & Agent Signing.

Install Commands By Platform

The commands behind Deploying The Agent above. Substitute your own instance’s API address for https://<your-instance>-api.zonitix.com.

Service Commands And File Locations

For Three Platform Layers, What The User Sees, Check Status and Removing The Agent By Hand above.

Remote Command Audit Actions

For Remote Commands above. A command still queued after 7 days is audited as DEVICE_COMMAND_EXPIRED. Everything cancelled for a device that is retired, rejected, deleted or enrolled again is audited as DEVICE_COMMAND_CANCELLED.

Reservation Audit Actions And Routes

For New-Hire Computers (Reservations) above.

Routes, under /api/v1/user-management: GET /devices/reservations/suggestions (view_devices) returns the devices waiting for an answer and the count of open reservations. POST /devices/:id/link-reservation with { reservationId } and POST /devices/:id/dismiss-reservation-suggestion need manage_devices. Linking answers 400 without a reservationId or when the device has not enrolled, 404 for an unknown device, and 409 when the reservation is no longer open.