Installing a security agent means running someone else's code as root on your production server. That is a real decision and it deserves specifics rather than reassurance. This is what the SecAI agent is, what it reads, what leaves your machine, and what it is not able to do.
If you are evaluating any agent, including this one, the questions below are the ones worth asking. A vendor who will not answer them concretely is telling you something.
Key Takeaways
- The agent is a single compiled Rust binary managed by systemd. There is no interpreter runtime and no package tree to keep patched.
- It reads logs, process and listener state, package inventory, and file hashes for watched paths. It does not read your application data or database contents.
- Telemetry leaves the host as it is produced, which is what makes it trustworthy after a root compromise.
- It can block network sources automatically. Anything that changes server state requires human approval first.
- Stopping the agent produces an alert rather than silence, because absence of telemetry is itself a signal.
Table of Contents
- What gets installed
- What it reads
- What it sends, and what it does not
- What it can change on your server
- What it deliberately cannot do
- How to verify all of this yourself
What gets installed
One binary, compiled from Rust, at /usr/local/bin/security-agent, run as a systemd service. No Python or Node runtime, no dependency tree, nothing that needs its own patch schedule. The reason for that choice is straightforward: a security agent with a large dependency surface is itself an attack surface, and asking you to trust a supply chain is worse than asking you to trust one static binary.
It registers once against your organisation, receives a token, and from then on reports on an interval. Resource use should be negligible on any server worth monitoring, verify that yourself rather than believing it, with the commands at the end of this post.
What it reads
Specifically, and this list is the boundary:
Authentication and system logs. Failed and accepted logins, sudo invocations, service events. This is the source for brute force detection and the escalation signals discussed in detecting privilege escalation on a Linux server.
Web server access logs, where present. Request paths, status codes, and source addresses, which is what makes probing and application-layer flood detection possible, along with webshell activity as described in how to detect a webshell on a Linux server.
Process list and listening sockets. Which executables are running, from which paths, owned by which users, and which ports are bound to which interfaces. This is how new listeners and unexpected binaries get flagged.
Outbound connection metadata. Destination addresses and ports, and which process owns each connection. Metadata only, not payload contents.
Installed package inventory. Read from dpkg, rpm, or apk depending on distribution, then matched server-side against vulnerability data so the question answered is which CVEs affect these specific machines. The reasoning is in how to track CVEs for the packages installed on your Linux servers.
Hashes of files in watched paths. The static locations that matter on a server: /etc/sudoers and /etc/sudoers.d/, SSH configuration and authorized_keys, cron directories, systemd unit paths, /etc/ld.so.preload. Hashes and metadata, not file contents, except where a change needs to be shown in a diff.
What it does not read: your databases, your application source, user-uploaded content, or the contents of files outside watched paths. There is no reason for a security agent to read your customer data, and it does not.
What it sends, and what it does not
Telemetry goes to the platform over TLS as it is produced, not batched for later upload. That timing detail is the single most important property of the whole design, and it is worth explaining why.
If an attacker gains root, they can edit /var/log/auth.log, replace ps, truncate the web access log, and remove the traces of how they got in. What they cannot do is edit a record that already left the machine several seconds before they escalated. Local-only logging is trustworthy exactly to the extent that the host's integrity is intact, which is the thing in question during an incident. Off-host telemetry is what turns "the logs look clean" into a claim you can actually check.
What is sent: log lines matching detection-relevant patterns, process and listener inventories, connection metadata, package lists, file hashes for watched paths, and agent health. What is not sent: application data, database contents, file contents outside a watched-path diff, or environment variables.
Where it is stored and for how long is a fair question to ask of any vendor, and it interacts directly with data protection obligations, for UAE businesses that means the considerations in server security requirements for UAE NESA and PDPL compliance.
What it can change on your server
This splits into two categories, and the split is deliberate.
Automatic, because it is narrow and reversible: network blocking. When detection identifies a hostile source, the agent applies a firewall rule within seconds. The scope matches the offence, a web-layer event blocks that source at ports 80 and 443 rather than applying a blanket drop or an SSH jail, so a false positive does not sever your own access. Blocks carry escalating durations rather than being permanent, addresses you log in from are trusted automatically, every block records the specific event that caused it, and reversal is one action from the console. The design reasoning is in how automated IP blocking works and how it goes wrong.
Requires human approval: anything that changes server state. Package installation, configuration changes, service restarts. The platform's audit pipeline produces a proposed batch of commands, you read them, you approve or reject, and only then does the agent execute, recording what ran and what it returned.
That boundary exists for a specific reason. A wrong automatic block costs someone a few minutes of access. A wrong automatic configuration change costs you an outage that you caused yourself, at which point the security tool has become the incident. The asymmetry justifies treating the two cases differently, which is the same principle developed in why manual server monitoring fails at 3am.
What it deliberately cannot do
Being specific about limits is more useful than a feature list.
It cannot stop volumetric DDoS. The agent sits on your server and sees traffic only after it has crossed your network link. An application-layer flood from identifiable sources is something it can act on. Forty gigabits saturating your provider's edge is not, that bandwidth is consumed before any host-based rule applies, and mitigation has to happen upstream. Any vendor claiming otherwise about a host agent is describing something that cannot work. The distinction is set out in detecting DDoS: Layer 4 and Layer 7 floods on a Linux server.
It cannot fix bad architecture. A database exposed to the internet with a weak password will be reported clearly and repeatedly. It will not be fixed for you, and monitoring is not a substitute for the work in a practical Linux server hardening checklist for small teams.
It cannot recover from a full root compromise. Once an attacker has root, the correct response is to rebuild the machine. The agent's job is to make that a same-day event rather than a discovery six weeks later, and to preserve off-host evidence of what happened. What that triage looks like is in how to tell if your Linux server has been compromised.
It cannot replace judgement about what matters. It will tell you a service is exposed. Whether that is a staging replica with synthetic data or your production customer database is context only you have.
It is not an EDR for laptops. It is Linux-server-shaped by design. If you have employee endpoints to protect, that is a different product category, the comparison is in enterprise EDR vs a Linux agent for small teams.
It can be stopped by root, and that produces an alert. An attacker with root can kill any agent. What matters is whether that looks like an incident or like health. Absence of telemetry is treated as a finding, so going quiet is itself the signal.
How to verify all of this yourself
Do not take any of it on trust. On a staging server:
# what is running, and what it costs
systemctl status security-agent
ps -o pid,ppid,user,%cpu,%mem,rss,etime,cmd -C security-agent
# where the binary is and what it is
ls -l /usr/local/bin/security-agent
file /usr/local/bin/security-agent
sha256sum /usr/local/bin/security-agent
# what it has open, and where it connects
ls -l /proc/$(pgrep -o security-agent)/fd 2>/dev/null | head -30
ss -tupn | grep security-agent
That last command answers the question that matters most, exactly which destination the agent talks to, and that it is not talking to anything else. Watch resource use over a few days under normal load and decide from your own numbers rather than a datasheet.
If a security vendor cannot tell you what their agent reads, what it transmits, what it can change without asking, and what it cannot do at all, that is the answer to your evaluation. You can see how these pieces work together in the rest of the detection stack, and how it is priced per server on the pricing page.
For the category-level view rather than this one agent, see the full guide to Linux server security software.
Frequently Asked Questions
Does the agent read my application data or database? No. It reads logs, process and socket state, package inventory, and hashes of files in watched system paths. Application data and database contents are outside that boundary.
What happens if the platform is unreachable? Local detection and previously applied firewall rules continue to work. The platform records the server as offline, because silence should never look like health.
How much CPU and memory does it use? It should be negligible on any server worth monitoring. Verify it with the commands above on your own hardware rather than accepting a number.
Can I uninstall it cleanly? Yes, stop and disable the service, remove the binary and its unit file. Firewall rules it applied can be listed and removed; it does not leave anything embedded that survives that.
Does it need root?
Yes. Reading /var/log/auth.log, enumerating processes owned by other users, and modifying firewall rules all require it. Any agent claiming to do these things without privilege is not doing them.
What if the agent itself has a vulnerability? A fair concern for any agent. The mitigations here are a single static binary with no interpreter runtime and no dependency tree, a narrow scope of what it accepts from the platform, and a small enough surface to reason about, which is why it is written the way it is rather than as a script with a package manifest.