"Read-Only" Monitoring Needs a Precise Boundary

Imagine the security reviewer asks one question before approving a collector across the fleet: "Can your server make this process execute a command?"

"It is read-only" is not an answer. A monitoring process may write its own state or temporary files while still having no server-controlled path that remediates the host. Those are different claims, and a useful architecture review has to separate them.

The question that matters is whether the monitoring data path contains an executor that can apply arbitrary changes to the systems it observes.

The boundary RootTrace actually implements

The RootTrace collector has no server-initiated remediation executor and no mode that applies arbitrary fixes. It collects configured diagnostics and sends their results outbound.

That does not mean the process never writes. The current code persists bounded collector state, writes short-lived temporary files holding Kubernetes client certificate material when a kubeconfig authenticates that way, and can run read-oriented helper commands such as ping, nvidia-smi, and openssl. An installer can also add an opt-in STIG audit-rule profile on RHEL-family systems. These operational writes and install-time changes are why the precise claim is "no remediation path," not "no write path."

Outbound only, which is a smaller thing than it sounds and a bigger one

The collector opens no inbound ports. Nothing on your hosts is listening for us, or for anyone who has learned to imitate us.

This matters more than the phrase suggests. An agent with a listening socket is a service on every machine in your fleet. It needs its own authentication, its own patch cadence, its own firewall rule, and it is reachable by anything that can route to the host. An agent that only makes short outbound HTTPS requests and closes them has none of that surface. There is nothing to scan and nothing to reach.

The practical version: you do not need an inbound firewall exception to run it. Outbound-only design reduces reachable surface, but it does not make a compromised collector harmless. A compromised process can still misuse whatever permissions and credentials it already has, which is why least privilege still matters.

The part that makes it checkable

Here is the thing that makes it verifiable.

The collector is Apache-2.0, and the source is public at github.com/byteaffinity/roottrace-collector.

More usefully, the collector ships as readable Python in the documented install methods. That lets an operator inspect the artifact on the host instead of auditing only an opaque native binary. Exact package-to-commit provenance should still be verified for the specific version you deploy.

That is the practical difference between publishing source and shipping readable source. You and your auditor can inspect the installed program, while still checking its package signature and release provenance.

Two smaller decisions in the same direction

Secrets are scrubbed on the host. Credential-shaped evidence is redacted before anything leaves the machine, not after it arrives. Redaction at the receiving end means the secret crossed the network and landed in someone else's storage before being cleaned up. Redaction at the source means it never left.

Cloud credentials are never read at all. Not read and discarded. Not read and redacted. The collector does not look.

What this buys during an approval review

It turns a vague trust conversation into a bounded one. The reviewer can inspect the installed Python, enumerate subprocess call sites, verify that the process opens no listener, and watch its outbound connections. The answer is not "trust our policy." It is a short list of behaviors the team can verify before the collector reaches production.

That does not make the collector harmless or eliminate the need for least privilege. It does make the risk legible enough to approve, reject, or constrain with evidence.

What to ask your current agent

Whatever you are running today, these questions separate architecture from policy:

1. Is remediation absent, disabled, or separately installed? Those are three different trust boundaries.
2. Does it listen on a port? If yes, it is a service on every host, and it inherits every obligation that implies.
3. Is the artifact on disk the source you can read? "Open source" and "ships as source" are different claims, and only the second is checkable on your own machine.
4. Where does redaction happen? If the answer is "on our servers," the secret made the trip.

Ask them of RootTrace too. The reason to publish the source and describe the architecture in this much detail is that it converts every one of those from a question you have to trust us on into one you can settle yourself in an afternoon.

Audit the boundary, then decide whether to run it

Start with the source, since that costs nothing and answers the questions that matter most:

git clone https://github.com/byteaffinity/roottrace-collector

Then grep it for the boundaries that matter. You will find subprocess calls, state-file writes, and the one tempfile call site that stages a Kubernetes client certificate and unlinks it again. Trace those and also look for inbound listeners, remote command handlers, configuration mutation, or a remediation executor. The claim should survive what the source actually does, not a search designed to return zero matches.

If you want the whole thing running, the server image is public and the free tier needs no vendor account or licence key:

docker pull public.ecr.aws/byteaffinity/roottrace/server:latest

The pull alone starts nothing. The quickstart is one paste-able block that writes the Compose file and your bootstrap token, then docker compose up -d. Budget more time for the image download than for writing the configuration.

Once a collector is running, ss -tnp on that host tells you every connection it holds, and you can check that against everything above.