One lightweight agent for continuous Linux server visibility

What the agent monitors

• Authentication: SSH events with the log line, the attempted username and the source; interactive sessions with user, source, method and key fingerprint.
• Processes: the process table on an interval, with executable path and command line for anything it finds suspicious, and the kernel's two views compared for hidden processes.
• Files: hashes of the system files that grant access and of web roots; for persistence files, the text before and after a change.
• Network: listening ports, outbound connections the server has not made before, and flood measurements from the connection tables and conntrack.
• Inventory: installed packages and versions for CVE matching, running services, cron entries, discovered websites.
• Posture: pending updates, firewall state, disks, failed units, certificate metadata, time synchronisation, backup status, the effective SSH configuration.
• Survival: while the server is being exhausted or cannot reach SecAI, per-second kernel counters and a record of anything it did about it, delivered when the link returns.

What the agent does not collect

Each of these is a property of the code, not a policy, and the Trust Center names the source for every one:

• The contents of databases, application files, uploads, mail or customer records. Files are hashed; the only file text that leaves the server is a changed persistence file and the first 200 bytes of a file the web-shell scanner flagged.
• Password hashes. /etc/shadow is read only to tell whether an account has an empty password.
• Private keys, packet contents, shell sessions, keystrokes, or process environments.

The full list, with sources

Permissions and action boundaries

Installation needs root (sudo), systemd, and the base tools every server has: curl, openssl, sha256sum, base64. Nothing else is installed alongside the agent. It runs as root because reading the authentication log, seeing every user's processes and changing firewall rules require it, and an agent that claims to do those things without privilege is not doing them.

What it may change is a short list, and each item is gated by the platform's policy: firewall rules through the tool the server already runs, service configuration for approved hardening fixes, package installs through the system package manager, service restarts, account enable and disable, quarantine and restore of a flagged file, and its own restart, upgrade and uninstall. Blocking an address is the only action that runs unasked, and only on a server set to Automatic. It never deletes or moves your files, never rewrites application code, never opens an inbound port and never loads a kernel module.

What runs on its own, and what waits

Network requirements

The agent makes outbound HTTPS connections to secai.techsteps.ae on port 443 and accepts no inbound connections; there is no port to open. After three consecutive failures to reach SecAI it opens a TCP connection to port 443 on 1.1.1.1 and 9.9.9.9, sends nothing, and uses the answer to tell "SecAI is unreachable" from "this server's link is down". When a package install is approved, the system package manager fetches from your distribution's mirrors as it normally would.

Installation, verification and updates

Enrolment produces one command: curl the install script for your enrolment token and pipe it to bash as root. The script is plain shell and can be read first. It downloads the release, checks its SHA-256 against the value baked into the script, verifies an Ed25519 signature over the binary with the release key printed in the Trust Center, and only then moves the file into place, writes the systemd unit, and starts the service. The platform refuses to serve a release whose signature does not verify.

Updates take the same path without a person: the agent checks once at start and about once a day, verifies size, hash and signature with the key compiled into it, installs atomically, and keeps the previous binary beside it as the rollback copy. Releases go to a canary channel, which includes SecAI's own production server, before they are promoted to stable.

An hour in the life of the agent

Performance

The agent is written in Rust and designed for low operational overhead on production servers: one static binary, collection from /proc and the kernel's own tables on an interval, metadata rather than contents, and a survival layer that asks systemd to keep the agent out of the OOM killer's way rather than to reserve resources. No public benchmark has been published yet, so no CPU or memory figure is claimed on this page; a measured figure per distribution, with the method, will be published when it exists.

Supported systems and uninstall

x86_64 Linux with systemd: current Debian and Ubuntu releases, and RHEL-compatible distributions including Rocky Linux and AlmaLinux. Firewall tools recognised: fail2ban, CrowdSec, iptables, ufw, firewalld and CSF. Control panels recognised: cPanel, Plesk and DirectAdmin. Shared hosting without root is out of scope.

Uninstall from the dashboard is picked up at the agent's next check-in, usually within a minute, and the agent then stops and removes itself; the manual commands are in the Trust Center. Only firewall rules it added on your behalf remain, in the tool that holds them, where you can remove them.

Trust Center