garrett 1.0.0

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once and cleans up after it. To watch first, install with --mode report.

Version 1: the agent in Rust

Before version 1 the agent was Python. Version 1 is the same agent written in Rust: one program file of a few megabytes for each system, with nothing to install beside it. No Python, no runtime.

• It may not drift from the Python agent. The Python agent stays in the source as the reference. Its decisions are recorded as fixtures (the scorer, the containment chains, the automation marks, the system tools' output, the Linux sensor, a hundred scripted events through the watcher, acting at the event, cleanup and restore, the web-log watch) and the Rust agent must reproduce every one. The check workflow regenerates the fixtures from the Python code and fails if they differ.
• A machine stays enrolled. The same files in the same form, the same service protocol, the same commands. apt upgrade, or the installer again, is all there is to do. The service is unchanged.
• Run for real on each system. On hosted Linux, macOS and Windows machines the Rust agent ended every stand-in attack before it acted (a web server starting a download-and-run shell; a document program starting an encoded PowerShell), then cleaned up a staged implant with its startup entries and put everything back exactly on restore.

What is different on purpose

• A program ended at the event is cleaned up after as well. Before, cleanup followed only a stop made at a full look. The files in a temporary folder that the stopped program's own command line names go to quarantine with it.
• Where the kernel's process feed is open but silent, the agent notices and listens by file instead.
• Which programs listen inside containers is asked on a thread of its own, so looks and reports do not wait for it on a machine with many containers.
• On Windows, what only PowerShell can answer (signatures, Defender's history, the DNS cache, the Security log) is asked while a look is prepared, so a responder never waits behind it. A signature can arrive one look later.
• A report that does not reach the service is said once in the machine's own log.
• HTTPS. A service that made its own certificate is trusted by the pinned certificate in its join command, as before. Any other service must present a certificate from a public certificate authority: the list is Mozilla's, compiled in. The Python agent used the operating system's list, so a service behind a private authority that you had added to the system now needs the pinned form.

Measured

On one lab machine (Linux, containers, a Kubernetes cluster), with the same forty download-and-run chains started behind a listening program:

	Rust agent (1.0.0)	Python agent (0.5.0)
Shells ended	40 of 40	0 of 40 (the kernel feed was open but silent on that machine, the case the Rust agent now notices)
How long an ended shell lived, timed by the program that started it	4.9 to 11.2 ms, median 5.7 ms
The agent's memory	10 MB	36 MB
The agent's processor time in two minutes	0.7 s	0.6 s
Processor time of the system tools it runs for its looks	3.1 s	3.3 s

Rust did not make the agent lighter on the processor: most of the cost is the system's own socket listing, which either agent runs at each look. On hosted Linux and Windows machines, where both agents are told of a program start the same way, both report ending the same stand-in attacks after the same time (about 18 ms on Linux, 4 to 8 ms on Windows): that time is set by how soon the system reports a program, not by the agent's language.

Libraries

The Python agent used none. The Rust agent is built with six it names itself (regex, serde_json, sha2, libc, rustls, webpki-roots) and what those bring with them, all pinned by rust/Cargo.lock. NOTICES.md, in every bundle and package, lists each one with its version, its licence and its licence text.

Downloads

File	For
garrett_1.0.0_amd64.deb, garrett_1.0.0_arm64.deb	Debian and Ubuntu (the one-line installer adds the signed apt repository instead)
garrett-linux-x86_64.tar.gz, garrett-linux-aarch64.tar.gz	other Linux: statically linked, one file runs on any distribution
garrett-macos.tar.gz	macOS, Apple silicon and Intel in one file
garrett-windows.zip	64-bit Windows
garrett-service.tar.gz, garrett-service-windows.zip	the Sentinel service for a machine of your own (unchanged)

garrett-linux.tar.gz is now two files, one for each kind of processor; the one-line installer picks the right one. Not built: 32-bit systems, and Windows on ARM as its own program.

The program files were built from this tag on hosted machines by .github/workflows/release-build.yml, after the recorded-decision tests passed there. SHA256SUMS is signed with the key 6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45 (garrett.asc).

Not done, and known limits

• Code that runs inside a server without starting a program cannot be stopped by an agent that watches programs.
• On Windows and macOS a program start is noticed by asking for the list of running programs every few milliseconds, not by a kernel notice, so a program that lives less than that can be missed.
• Windows has no watch on startup places; a startup entry is found and switched off when the program it names is stopped.
• It has not yet run on a real fleet.

garrett 0.4.1

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once and cleans up after it. To watch first, install with --mode report.

There was no 0.4.0 release; this is the first of the 0.4 line.

New in 0.4.1: acting at the event

Until now the agent acted at its next look at the machine, so timing decided: one attack was caught and the next, a little quicker, got through. On Linux it now acts the moment the kernel reports a program start.

• Responders. Each report of a program start goes to its own responder, several at once, so many attacks are handled side by side. A hostile shell is frozen at once and, in kill mode, ended with anything it had already started, about a millisecond after it starts.
• Nothing waits on the agent. It listens; it does not stand in the way. If it stops, programs start exactly as before.
• Adaptive. The agent learns which commands each network-facing service normally starts, kept as marks, never as the commands. For ten minutes after a service is used for an attack, any other command it starts is ended on sight. Its normal work goes on. Nothing to configure.
• Containers and WSL. Where the kernel's process feed cannot be matched to processes, program starts are followed by a second kind of kernel notice. A web server inside a container is recognised by its name, so a shell it starts is ended as quickly as on the machine itself.
• Startup places are judged the instant one changes.

What it still cannot do

• It does not prevent a program from starting; it ends it about a millisecond later. A chain that finishes inside that first millisecond without touching the network can still finish; what it leaves is caught by the startup watch.
• Acting at the event is Linux only. On Windows and macOS the agent still acts at its next look.
• A program in a container that accepts connections and is not named like a web server listens in the container's own network, which the agent does not look into. A shell it starts is judged at the next look.
• What a responder acts on at the event is narrow on purpose: a shell or script interpreter started by a program that accepts network connections, with a download-and-run, reverse-shell or who-am-I command, or a command that service does not normally run while it is held. Everything else is judged at the next look.
• The adaptive hold starts with no knowledge: a service attacked before the agent has seen its normal commands has every shell command ended for ten minutes.

Install

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Your own service, Linux	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/service.sh | sudo sh
Your own service, Windows	elevated PowerShell: irm https://gary23w.github.io/agent-garrett-sentinel-service/service.ps1 | iex
Debian, Ubuntu by hand	garrett_0.4.1_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

Files

• garrett_0.4.1_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz, garrett-macos.tar.gz, garrett-windows.zip (with the official embeddable Python 3.13.9 from python.org inside)
• garrett-service.tar.gz, garrett-service-windows.zip: the service for your own machine (unchanged since 0.3.0)
• SHA256SUMS with its signature SHA256SUMS.asc, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

On a hosted Ubuntu machine, by the repository's verify workflow: a shell reached through a listening service and made to call back after 0, 10, 30, 70, 200 and 1000 ms of other work, six times each. 0 of 36 callbacks arrived, and the service that was reached kept serving. A 20 ms chain was ended before it reached the line that writes its startup entry. The kernel's process-start feed caught 20 of 20 shells that live about a millisecond. All earlier checks still pass on hosted Ubuntu, macOS and Windows Server.

By hand on a lab network inside WSL, with one agent on the root machine of nine containers: the same callback test through a service on the machine, 31 of 36 arrived with 0.3.1 and 0 of 24 with 0.4.1; a shell started by a PHP application inside its container ran to the end 22 of 24 times with the previous build and 0 of 24 with 0.4.1, with the application still serving. 300 program starts took the same time with the agent listening as with it stopped.

Not run: a real intrusion, a busy production machine (the cost of following every program start there is unmeasured), desktop editions of Windows, Macs outside the hosted image, a real fleet. The Windows bundles are not code-signed, so Windows will warn before running them.

garrett 0.3.1

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once and cleans up after it. To watch first, install with --mode report.

New in 0.3.1: what testing against staged intrusions found

0.3.0 was run against staged attack chains on a lab network. These are the gaps that turned up, each now closed:

• A chain that is over in milliseconds left no case, and its startup entries stayed. The agent now watches the startup places themselves (Linux and macOS). A cron job, startup service, login item or shell startup line that appears and runs a download-and-run or reverse-shell command, or starts a program kept in a temporary folder, becomes a case within seconds whoever wrote it. In kill mode it is switched off and the program it names is quarantined.
• A shell started by a service that is not named like a web server was not judged as a web shell. Any program that accepts network connections and then starts a shell is now judged the same way. Sign-in services, container runtimes and the like are excluded, since starting shells is their work.
• A dropped program that called itself a web server was never stopped or cleaned. A web server or system name now protects nothing that runs from a temporary folder.
• The packaged agent could not change anything under home folders, so shell startup lines and files dropped there were found and left. The service no longer makes home folders read-only for itself, and anything it still cannot change is listed in the case as left, not hidden.
• Cleaning could not reach inside containers. One agent on the root machine now cleans a container's files and startup entries through that container's own file system, and reads web server logs kept by Docker and by a Kubernetes node.

Also fixed: garrett restore run without root could not read back a quarantined file.

What it still cannot do

• It cannot stop a chain that finishes in milliseconds before it finishes. It records it and removes what it left, within seconds.
• Inside a container, or anywhere else with its own process numbering (WSL included), the kernel's process-start feed cannot be matched to processes, so there a new program is seen only at the agent's next look.
• The startup watch covers Linux and macOS, not Windows.
• A file cleaned inside a container can be restored only while that container is still running.
• Failed sign-in bursts on Linux (SSH) are not a case; sign-ins with valid stolen credentials look like ordinary work.

Install

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Your own service, Linux	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/service.sh | sudo sh
Your own service, Windows	elevated PowerShell: irm https://gary23w.github.io/agent-garrett-sentinel-service/service.ps1 | iex
Debian, Ubuntu by hand	garrett_0.3.1_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

Files

• garrett_0.3.1_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz, garrett-macos.tar.gz, garrett-windows.zip (with the official embeddable Python 3.13.9 from python.org inside)
• garrett-service.tar.gz, garrett-service-windows.zip: the service for your own machine (unchanged from 0.3.0)
• SHA256SUMS with its signature SHA256SUMS.asc, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

On a hosted Ubuntu machine, by the repository's verify workflow: the kernel's process-start feed caught 19 of 20 shells that live about a millisecond; an 18 ms chain behind a listening service was recorded as a case and the cron entry it left was switched off about two seconds later, then restored and left alone. All earlier checks still pass on hosted Ubuntu, macOS and Windows Server.

By hand, on a lab network of nine containers on one machine with a single agent on the root machine: a 16 ms chain's cron entry removed in about five seconds; a fake web server in a temporary folder ended and quarantined with its cron job and shell startup line; a chain inside the application container stopped and that container's files cleaned and restored; injection-shaped requests to a containerised shop reported from Docker's log.

Not run: a real intrusion, desktop editions of Windows, Macs outside the hosted image, a real fleet. The startup watch was not run on macOS. The Windows bundles are not code-signed, so Windows will warn before running them.

garrett 0.3.0

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once, and from this version also cleans up after it. To watch first, install with --mode report.

New in 0.3.0: cleaning up an infected machine

Stopping a program is not the end of an intrusion: whatever started it is usually still there to start it again. The moment the agent stops a program, it now also:

• moves the program's file to a quarantine folder, when it sits where intruders drop files (temporary folders, home folders, web roots; on Windows user profiles, ProgramData, Windows\Temp), and ends any other running copy of it;
• switches off what would start it again: systemd units, cron jobs, login items, LaunchDaemons and shell startup lines; on Windows Run values, scheduled tasks, services and Startup items;
• does the same for a startup entry that calls an address from the advisory list or one your fleet was attacked through, even when no file was dropped;
• lists sign-in keys, accounts and administrator rights changed since the program appeared, for you to review. It changes none of them.

Nothing is deleted, and one command undoes it: sudo garrett restore <case> puts back every file with its owner and permissions, every line and value, and re-enables every task and service. A system tool an intruder merely used (a shell, PowerShell, curl) is ended, never removed. Nothing is cleaned in report mode.

Turn it off with CLEAN=off in the configuration file (-Clean off on Windows, run --clean off by hand).

What it cannot do: know what was read or copied before the stop, remove accounts or keys, follow an intruder that renamed its file, or repair a file the intruder edited. Treat credentials that were on the machine as exposed. Removing garrett removes its quarantine folder with it; restore first what you want back.

Install

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Your own service, Linux	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/service.sh | sudo sh
Your own service, Windows	elevated PowerShell: irm https://gary23w.github.io/agent-garrett-sentinel-service/service.ps1 | iex
Debian, Ubuntu by hand	garrett_0.3.0_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

A service from 0.2.3 keeps working with 0.3.0 agents; update it (run the service one-liner again) to see what was cleaned with each case.

Files

• garrett_0.3.0_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz, garrett-macos.tar.gz, garrett-windows.zip (with the official embeddable Python 3.13.9 from python.org inside)
• garrett-service.tar.gz, garrett-service-windows.zip: the service for your own machine
• SHA256SUMS with its signature SHA256SUMS.asc, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

Run on hosted Ubuntu, macOS and Windows Server machines by the repository's verify workflow: the real cleaner against a harmless file with real startup entries pointing at it (cron and systemd on Ubuntu; a LaunchDaemon and a shell startup line on macOS; a Run value, a scheduled task, a service and a Startup item on Windows), each quarantined or switched off and then restored exactly. Also, as before: install from the public site, a stand-in attack ended and recorded, fleet blocking, the self-hosted service, and removal leaving nothing. By hand on Linux: the published package ending a staged implant, quarantining it with its cron job and startup service within about a second, and restoring all three byte for byte.

Not run: a real intrusion, desktop editions of Windows, Macs outside the hosted image, a real fleet. On Windows and macOS the cleaner was run directly, not through a full stop of a staged attack. The Windows bundles are not code-signed, so Windows will warn before running them.

garrett 0.2.3

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once. To watch first, install with --mode report.

New in 0.2.3: your own service in one line

A fleet needs a service for its machines to report to. This turns a machine of your own into one, free, with no account. It makes its keys and its own HTTPS certificate, starts, and prints the command that joins your other machines.

Machine that will be the service	Run
Linux (systemd)	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/service.sh | sudo sh
Windows	elevated PowerShell: irm https://gary23w.github.io/agent-garrett-sentinel-service/service.ps1 | iex

The join command carries the enrolment key and the SHA-256 of the service's certificate. A machine that joins with it talks to that certificate and no other, so no certificate authority and no domain name are needed. Joining machines need garrett 0.2.3, which the join command installs.

Also fixed: on Debian and Ubuntu, the one-line installer given --server, --mode or --label left the repository key unreadable to apt, so the install or later upgrades could fail. If you installed that way before, run sudo chmod 644 /usr/share/keyrings/garrett.gpg.

Install the agent

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Debian, Ubuntu by hand	garrett_0.2.3_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

Files

• garrett_0.2.3_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz: Linux without apt (sudo sh garrett/install.sh)
• garrett-macos.tar.gz: macOS (double-click Install garrett.command)
• garrett-windows.zip: Windows, with the official embeddable Python 3.13.9 from python.org inside
• garrett-service.tar.gz, garrett-service-windows.zip: the service for your own machine; the one-line installers above fetch these and the official Node.js v24.22.3 from nodejs.org, each checked against its SHA-256
• SHA256SUMS with its signature SHA256SUMS.asc, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

Run on hosted Ubuntu, macOS and Windows Server machines by the repository's verify workflow: the agent installed from the public site with no service, a stand-in attack ended and recorded, an address refused and let through again by fleet blocking, and removal leaving nothing. For the self-hosted service, on hosted Ubuntu and Windows Server: one line makes the machine a service, a machine joins with the printed key, its case reaches the service, a wrong certificate fingerprint is refused (Ubuntu), and removal leaves nothing.

Not run: desktop editions of Windows, Macs outside the hosted image, a real fleet, and a self-hosted service under a large fleet. The Windows bundles are not code-signed, so Windows will warn before running them.

garrett 0.2.2

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once. To watch first, install with --mode report.

Install

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Debian, Ubuntu by hand	garrett_0.2.2_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

Files

• garrett_0.2.2_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz: Linux without apt (sudo sh garrett/install.sh)
• garrett-macos.tar.gz: macOS (double-click Install garrett.command)
• garrett-windows.zip: Windows, with the official embeddable Python 3.13.9 from python.org inside
• SHA256SUMS with its signature SHA256SUMS.asc, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

Run on hosted Ubuntu, macOS and Windows Server machines by the repository's verify workflow: install from the public site with no service, a stand-in attack ended and recorded, an address refused and let through again by fleet blocking, and removal leaving nothing. On Windows that is this bundle installed as SYSTEM with its own Python. Also run: the Linux bundle install, the Kubernetes DaemonSet, and the service under a simulated fleet (numbers in the README under "Very large fleets").

Not run: desktop editions of Windows, Macs outside the hosted image, a real fleet. The Windows bundle is not code-signed, so Windows will warn before running it.

In 0.2.x

• Protects a machine by itself when no service is configured (garrett cases, trust, stop, release).
• Reporting built for very large fleets: revisions, a cached pulse, reporting intervals set by the service, jitter everywhere, patient enrolment.
• Fleet blocking, learned signal pairs, a coverage map, operator-added indicators.

In 0.2.2

• A paused program is written down, so a restarted or upgraded agent still holds it and carries out the decision on it.
• An agent its service removed, and one told to forget its service, lets go of what it paused instead of leaving it frozen.

garrett 0.2.1

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once. To watch first, install with --mode report.

Install

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Debian, Ubuntu by hand	garrett_0.2.1_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

Files

• garrett_0.2.1_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz: Linux without apt (sudo sh garrett/install.sh)
• garrett-macos.tar.gz: macOS (double-click Install garrett.command)
• garrett-windows.zip: Windows, with the official embeddable Python 3.13.9 from python.org inside
• SHA256SUMS with its signature SHA256SUMS.asc, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

Run on hosted Ubuntu, macOS and Windows Server machines by the repository's verify workflow: install from the public site with no service, a stand-in attack ended and recorded, an address refused and let through again by fleet blocking, and removal leaving nothing. On Windows that is this bundle installed as SYSTEM with its own Python. Also run: the Linux bundle install, the Kubernetes DaemonSet, and the service under a simulated fleet (numbers in the README under "Very large fleets").

Not run: desktop editions of Windows, Macs outside the hosted image, a real fleet. The Windows bundle is not code-signed, so Windows will warn before running it.

In 0.2.x

• Protects a machine by itself when no service is configured (garrett cases, trust, stop, release).
• Reporting built for very large fleets: revisions, a cached pulse, reporting intervals set by the service, jitter everywhere, patient enrolment.
• Fleet blocking, learned signal pairs, a coverage map, operator-added indicators.

garrett 0.2.0

garrett is the Sentinel agent as something you install in one step. Installed with nothing else, it protects the machine it is on; given a service address and an enrolment key, it joins your fleet.

The default mode ends a program judged hostile at once. To watch first, install with --mode report.

Install

Machine	How
Linux, macOS	curl -fsSL https://gary23w.github.io/agent-garrett-sentinel-service/install.sh | sudo sh
Windows	download garrett-windows.zip, unpack it, double-click Install garrett.cmd
Debian, Ubuntu by hand	garrett_0.2.0_all.deb, or the signed apt repository described in the README
Kubernetes	kubernetes-daemonset.yaml

Files

• garrett_0.2.0_all.deb: Debian and Ubuntu package
• garrett-linux.tar.gz: Linux without apt (sudo sh garrett/install.sh)
• garrett-macos.tar.gz: macOS (double-click Install garrett.command)
• garrett-windows.zip: Windows, with the official embeddable Python 3.13.9 from python.org inside
• SHA256SUMS, and garrett.asc, the key the apt repository is signed with (6857 EBCB BEF5 1040 C3F2 0107 3626 88BF C238 AB45)

What has and has not been run

Run: the apt install from the signed repository, the Linux bundle install, the Kubernetes DaemonSet, the Windows bundle's Python running the agent without administrator rights, and the service under a simulated fleet (numbers in the README under "Very large fleets").

Not run: the Windows install as SYSTEM, and anything on a Mac. The Windows bundle is not code-signed, so Windows will warn before running it.

New in 0.2.0

• Protects a machine by itself when no service is configured (garrett cases, trust, stop, release).
• Reporting built for very large fleets: revisions, a cached pulse, reporting intervals set by the service, jitter everywhere, patient enrolment.
• Fleet blocking, learned signal pairs, a coverage map, operator-added indicators.