Agent vs agentless security scanning: which is right for your fleet?
Every vulnerability scanner is either agent-based, agentless, or hybrid. The architectural choice has knock-on effects on coverage, operational burden, and trust model. This post explains the real trade-offs — and why agentless wins for most homelab and small-fleet operators.
What "agent" and "agentless" actually mean
An agent-based scanner installs a long-running process on every host being scanned. The agent reads local state (installed packages, running services, kernel version) and reports back to a central server. CrowdStrike Falcon, Wazuh, Tenable Nessus Agent, and Pareto Security are agent-based.
An agentless scanner reaches into the host from outside — typically over SSH, sometimes over a cloud-provider API (AWS Inspector reads EC2 instance state from the AWS control plane). Lynis runs as a script you invoke, but its single-host reporting model is closer to agentless than agent-based — there's no daemon. Noxen is agentless over SSH.
Hybrid scanners support both modes. Tenable Nessus, Qualys, and most enterprise platforms are hybrid — agents for granular always-on monitoring, agentless for transient or hard-to-instrument hosts.
What an agent gives you (and what it costs)
Agents win on three dimensions:
- Real-time visibility. A daemon can react to events — new process, new file, new connection — within seconds. Agentless scans run on a schedule.
- Deeper kernel-level data. Agents can read eBPF programs, ETW events on Windows, system calls, and process trees. SSH-driven scans can only see what's exposed through user-land tooling.
- Offline operation. An agent on a laptop can keep collecting and report when the network comes back.
The cost is operational:
- Install on every host. 50 hosts means 50 installs. Forget one, you have a blind spot you don't know about.
- Update on every host. The agent itself is software. It has CVEs. It needs patches. Agent-update infrastructure is its own engineering surface.
- Resource cost on every host. An agent uses CPU and memory all the time, even when nothing's happening. For a Raspberry Pi running Pi-hole this is a non-trivial fraction of the host's capacity.
- Trust expansion. An agent runs as root (or equivalent privilege) so it can read package state. That's a new privileged binary on every box, a new code path that gets execution every minute, a new vendor whose code-signing infrastructure your security depends on.
The infamous CrowdStrike Falcon outage in July 2024 — the one where a config push bricked 8.5 million Windows hosts globally — is the agent-architecture risk made manifest. An agentless scanner cannot brick the hosts it's scanning, because it has no code running on them.
What agentless gives you (and what it costs)
Agentless wins on:
- Zero install on the host. If you can SSH to it, you can scan it. New host? Just add it to the scanner's host list. Decommissioning? Just remove the entry. Nothing ever lingers on the box itself.
- No agent CVEs. The most secure agent is the one that doesn't exist. An agentless scanner is one less privileged binary on every host.
- Trust unchanged. The scanner uses your existing SSH keys and the access rights they already have. No new RBAC scope, no new vendor with kernel access.
- Lower resource cost. The host runs nothing between scans. A scan reads package inventory in 1–10 seconds and the host returns to idle.
The cost is in coverage:
- Snapshot, not stream. A scan tells you the host's state at the moment of the scan. Drift between scans is invisible.
- SSH-reachable only. Hosts behind a firewall, on a separate network, or off-grid don't get scanned. For homelabs this is rarely a problem; for distributed-fleet deployments it can be.
- User-land visibility only. The scanner sees
what
dpkg,systemctl, and/etc/os-releasesee. Kernel-level rootkits hiding from those tools also hide from the scanner.
The trade-off, summarised
| Agent | Agentless | |
|---|---|---|
| Coverage | Real-time, kernel-deep | Snapshot, user-land |
| Per-host install | Yes, every host | No |
| Per-host update | Yes, every host | No |
| Resource cost | Continuous | Per-scan only |
| Trust expansion | New privileged binary | Reuses SSH keys |
| Failure blast radius | Can brick hosts | Cannot |
| Best for | Always-on detection | Periodic posture checks |
Which one is right for a homelab?
For a fleet of 5–50 homelab hosts, agentless almost always wins:
- You already have SSH access — that's how you log in to fix things.
- Your hosts are heterogeneous (a Pi, a NUC, a NAS, a VPS) — finding agents that work across all of them is painful.
- You don't need real-time eBPF-level visibility for the threats you actually face (mostly: drifted configs and unpatched packages).
- You don't want to add a new privileged binary to every box just to know what version of openssl you're running.
Pareto Security is a popular endpoint scanner and a worthy tool — but its architecture installs an agent on every device. For a homelab where you'd prefer not to run yet another always-on service on every Pi, an agentless scanner like Noxen is a better fit.
When you might want both
For real-time intrusion detection (process spawn, file change, network anomaly) you genuinely need an agent. The right combination for a serious homelab is:
- Agentless CVE/posture scanner for the weekly "what's drifted, what's vulnerable" question. (Noxen fits here.)
- Agent-based IDS/HIDS for the live "something just happened" question. (Wazuh, OSSEC, Falco fit here.)
Most homelabs only need the first. The second is only worth its operational cost if you're running things you wouldn't be embarrassed to defend in court.
What Noxen does
Noxen is a Mac-native agentless scanner. You add
hosts via your existing ~/.ssh/config, and the app
reads package inventory + runs network probes on every enrolled
host nightly. No agent on any of your boxes. CVE matching against
a signed feed sourced from VulnCheck NVD++ and OSV.
$79 one-time at launch.