Back to Writing

Writing · 28 Jul 2026

What agentless auditing actually trades away, and why coverage is a finding, not a footnote

Agent-based fleet tooling installs something on every host: a daemon, a package, a scheduled job that phones home. Agentless auditing over SSH trades that away: one read-only pass, nothing left running, nothing to patch or babysit afterward. That's usually described as the whole benefit. It is a real benefit. It also comes with a cost that's easy to gloss over: an agentless audit's honesty depends entirely on which hosts it could actually reach.

The failure mode that hides inside a clean-looking report

A host that's down for maintenance, mid-patch, firewalled off from the auditing box, or just slow enough to time out gets silently dropped by naive tooling, and the resulting report still looks complete. A summary line reading “98% of hosts passing” means something very different depending on whether the missing 2% were checked and failed, or never checked at all. Those two situations should never produce the same-looking output, but with a tool that quietly skips what it can't reach, they do.

Coverage has to be a first-class result

The fix isn't a smarter retry loop: timeouts and flaky networks are a fact of life in a fleet of any size. The fix is refusing to let an unreachable host disappear from the report. Every host that couldn't be audited should appear in the output with a reason: auth failure, connection timeout, refused connection, host key mismatch. “Audited 340 of 344 hosts, here's why the other four weren't” is a fundamentally more honest statement than a report that only ever mentions the 340, and it turns coverage itself into something you can act on, instead of an invisible gap in the denominator.

The report format is also an attack surface

There's a second, less obvious risk in this class of tool: the report itself. Dump host data into a spreadsheet without thinking about it, and you're one hostname or interface description away from formula injection: a compromised or maliciously-named host puts something like =cmd|... into a field, and if that report gets opened in an application that evaluates formulas, the audit output becomes the payload. Every cell that could conceivably start with =, +, -, or @ needs to be written formula-safe by construction, not as an afterthought someone has to remember when a new field gets added.

Severity and a fix, not just a checkmark

The last piece is what the report is actually for. A pass/fail count against a checklist is easy to generate and easy to ignore. Ranking findings by severity, with a concrete recommended fix attached to each one, is what turns an audit from a compliance artifact into something an operator actually acts on the same week they receive it.

This is the shape Linux Fleet Audit is built around: unreachable hosts are logged with a reason instead of silently dropped, the run stays parallel and continues past individual host failures, every report cell is written formula-safe, and findings come ranked by severity with a fix attached, so the report can be trusted at a glance, including about what it didn't manage to check.

Back to Writing