Agent vs agentless
There are three common ways to look at a server's security, and each sees something the others miss.
- An agent on the host runs all the time, sees events as they happen and between any scans, and can act locally. It is also one more piece of privileged software on every server.
- SSH-based (agentless) scanning: a central scanner logs in on a schedule, runs commands and reads files, then disconnects. Nothing stays installed, but the scanner holds credentials that can log in to every server, and anything that happens between two scans and is then tidied away is never seen.
- Cloud API posture tools read the provider's APIs: security groups, storage permissions, identities, instance settings. They see the cloud account's configuration and nothing inside the operating system.
An external port scan adds a fourth view, of what is exposed. These are not exclusive; the useful question is which gap matters most to you.
What an agent typically reads
On Linux almost everything an agent needs is exposed by the kernel and the standard system files. A typical agent reads:
- Logs: the authentication log or the systemd journal, and sometimes web server and application logs.
- /proc: the process table, each process's executable, command line and owner, and the kernel's network tables.
- File hashes: checksums of configuration and system files, compared over time to spot changes.
- Packages: the dpkg or rpm database, matched against vulnerability advisories.
- Network state: listening sockets and established connections, as ss shows them, and sometimes connection tracking.
- Configuration: the effective SSH daemon settings, firewall state, users, groups and sudo rules.
Some agents go deeper, with a kernel module, an eBPF program or the Linux audit subsystem, to see system calls as they happen. Deeper hooks see more and carry more risk: a misbehaving kernel module can take the server down, and anything tied to kernel internals has to keep pace with kernel updates. Neither design is wrong; know which one you are installing.
Why it needs root, and why that is a trust decision
Reading the authentication log, seeing every user's processes in full, checking /etc/shadow and changing firewall rules all need root or specific Linux capabilities. An agent that claims to watch those things without privilege is either not watching them or relying on something else to do the reading.
That makes the agent one of the most privileged programs on the server, with a network connection to someone else's platform: in effect, a remote administration channel. Every question worth asking follows from that.
Footprint
An agent costs CPU, memory, disk reads and network traffic, and the cost depends mostly on how much there is to scan: a server holding many websites does more integrity work than a quiet database host. Ask the vendor for measured figures with the method behind them, then measure on your own servers with ps, top or systemctl, looking at the peaks during scans as well as the average.
How updates are delivered, and why signing matters
Most agents update themselves, which gets fixes out quickly and is also a path straight into every server running the agent. Someone who could replace a vendor's release would get root on every customer at once; MITRE ATT&CK lists tampering with a software supply chain, including update mechanisms, as a technique in its own right.
HTTPS protects the download in transit; it does not prove the file is the one the vendor built. A signature does, when it is checked on your server against a public key the vendor publishes, before the new binary runs. Add a way to roll back a bad release, and a staged rollout that runs a release on a few servers before everyone gets it.
Questions to ask any vendor
- What exactly is collected, field by field, and what is never collected?
- What leaves the server, where does it go, and which third parties process it?
- What can the agent change on its own, and what needs a person to approve it?
- How are commands from the platform authenticated, so that only the vendor's platform can send them?
- How are updates delivered and verified on the server, and how do I roll one back?
- Does it open any inbound port?
- Which distributions, architectures and kernels are supported?
- How do I uninstall it completely, and what is left behind?
A vendor that answers these in public documentation, with the source of each answer, is easier to trust than one that answers on a sales call.
Limitations
- An attacker with root can stop the agent, change its configuration or feed it false information. The useful defence is a platform that notices when an agent goes silent or is stopped, and that records changes to the agent's own files.
- It only sees the host it runs on, and only on systems it supports. An unsupported distribution or architecture means no coverage at all.
- On a server that was compromised before the agent was installed, the baseline the agent records may already include the intrusion.
- It does not replace patching, key-only SSH or backups. It tells you what is happening; it does not configure the server correctly for you.
The SecAI agent, briefly
SecAI's agent is one statically linked binary run by systemd, on x86_64 Linux with systemd: current Debian and Ubuntu releases, Rocky Linux and AlmaLinux. It runs as root, reports every 60 seconds over outbound HTTPS, and opens no inbound port. Each release is verified by SHA-256 and an Ed25519 signature at install and at every update, commands from the platform are signed and verified on the server before anything runs, and it loads no kernel module and no eBPF program.
Its answers to the questions above are published: what it collects and what it never collects (database contents, password hashes, private keys, packet contents, shell sessions), what it may change, and how to remove it, from the dashboard or by hand.