Does the agent read the files on my server?

It hashes the files it monitors and reports paths and hashes. File text leaves the server in exactly two cases: the before-and-after text of a changed persistence file (cron entries, sudoers, authorized_keys, systemd units), and the first 200 bytes of a file the web-shell scanner flags, sent for screening. Databases, application files, uploads and mail are never read.

Why does it run as root?

Reading authentication logs, seeing processes owned by every user and changing firewall rules all require root. An agent that claims to do those things without privilege is not doing them.

What can it change without asking me?

On a server set to Automatic, one thing: block an address identified as attacking the server, for 24 hours, with your own addresses exempt. In Awaiting Approval, nothing. Every other change waits for a person in both modes.

How do I check the binary I was given?

The install script is plain shell; read it first. It carries the SHA-256 of the release and verifies an Ed25519 signature with the release key published on this page before installing. sha256sum /usr/local/bin/security-agent afterwards should match the value in the script you ran.

Does an AI provider see my server data?

Yes, for the uses listed under Data flow: OpenAI receives findings, package versions and configuration state for audits, fix checks and screening, and the excerpt of a flagged file. No other AI provider is used.

How do I remove it completely?

Uninstall from the dashboard, or run the commands under Uninstall above. Only firewall rules it added on your behalf remain, in the tool that holds them, where you can remove them.

SecAI Trust Center | Security, Privacy and Agent Transparency

Agent identity

One binary, one systemd unit, no kernel modules.

Binary: /usr/local/bin/security-agent
Service: secai-agent (systemd, Restart=always). Start, stop and status use this name; the process itself is named security-agent.
Runs as: root. Reading authentication logs, seeing every user's processes and changing firewall rules all require it.
Build: Rust, statically linked, one file of a few megabytes. No kernel module, no eBPF program, no interpreter.
State on disk: /etc/securityemployee (identity and enrolment), /etc/securityemployee-agent (update and policy state), /var/lib/securityemployee (configuration snapshots kept for undo), /var/log/securityemployee-agent-update.log
Version: Semantic versioning. security-agent --version prints it; the dashboard shows it per server. Releases ship on a stable channel and a canary channel; SecAI's own production server runs the canary channel, so a release runs there before it is promoted to stable.

How the agent is verified

Nothing runs on your server that has not passed a signature check on your server.

The install script is plain shell and can be read before it is run. 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 below, and only then moves it into place. The platform refuses to serve a release whose signature does not verify, so an unsigned binary cannot be handed out even by mistake.

Updates follow the same path: the agent checks once at start and about once a day, downloads a manifest and binary, verifies size, hash and signature with the key compiled into it, installs atomically and keeps the previous binary beside it as the rollback copy. Every update attempt is written to the update log on the server.

Commands from SecAI are signed envelopes (Ed25519) that the agent verifies before acting, so a command can only come from the platform, and a replayed or altered one is dropped.

Release signing key: Ed25519, base64: Dn6GSNGh54w0SUCtSTEt8fLvquF7aT7CFcExhS/GlKU=
Update cadence: On start, then every 24 hours give or take an hour; a failed check is retried after 2, 5 and 15 minutes.
Rollback of a bad update: The previous binary stays at /usr/local/bin/security-agent.prev.
Policy signing key: The agent verifies its signed policy with a separate Ed25519 key; the public half is downloadable at https://secai.techsteps.ae/agent/pubkey.

Permissions and what the agent may do

Installed with sudo, runs as root, and every change it can make is listed here.

To install: root (sudo), systemd, and the base tools every server has: curl, openssl, sha256sum, base64. Nothing else is installed alongside the agent.
Reads: Authentication logs, /proc, the process table, listening sockets and connection tables (ss, conntrack), package databases (dpkg/apt, rpm/dnf/yum), cron directories, systemd units, the SSH daemon's effective configuration (sshd -T), /etc/passwd, /etc/group and /etc/shadow (see "Data not collected"), web server and control panel configuration for the sites it hosts, web roots for integrity checks, and the Docker socket read-only when it exists.
May change, when allowed by the policy below: Firewall rules through the tool the server already runs (fail2ban, CrowdSec, CSF, firewalld or iptables); service configuration for approved hardening fixes; package installs through the system package manager; service restarts; user account enable and disable; making a flagged file unreadable in place (quarantine) and restoring it; its own restart, upgrade and uninstall.
Never: Deletes or moves your files. Rewrites application code. Opens an inbound port. Loads a kernel module. Records keystrokes or shell sessions.

Data collected

Security metadata about the host, sent over TLS to SecAI. The exact categories, from the agent's telemetry payload:

Host identity: hostname, operating system, version and kernel, architecture, agent version, network interfaces and their addresses.
Resource metrics: CPU, memory, disk, uptime, network byte counters.
Inventory: installed package names and versions (for CVE matching), listening ports, running services, cron entries, discovered websites (hostname, port, TLS, where it was found).
Authentication: SSH authentication events with the log line, the attempted username and the source address; who is logged in interactively (user, source address, method and key fingerprint) and when the session opened and closed.
Processes: for a process the agent finds suspicious, its PID, executable path, command line and whether the binary was deleted while running.
Network: outbound connections the agent finds unusual (remote address, port, owning process); flood and connection-exhaustion measurements.
Files: paths and hashes of monitored system files and web roots. When a persistence file changes (cron entries, sudoers, an authorized_keys file, a systemd unit), the text before and after the change, within a small byte budget and never for binary files.
Accounts and privilege: local accounts (name, uid, gid, home, shell, whether the password is empty, which package created it), groups, sudo grants, SSH public-key fingerprints and comments, setuid binaries, capabilities.
Posture: pending updates, firewall state, disk usage, failed units, TLS certificate metadata for served sites, time synchronisation, backup status, hardening findings from the SSH configuration.
Suspected web shells: the file path, size, SHA-256, the matching rule and the first 200 bytes of the file, sent for automated screening.
Survival record: while the server is under resource exhaustion or cannot reach SecAI, per-second kernel counters (pressure, memory, forks, sockets, backlog) and a record of anything the agent did about it, delivered when the link returns.

Data not collected

What the agent is built not to read or send. Each of these is a property of the code, not a policy.

Contents of your databases, application files, uploads, mail or customer records. The agent hashes files it monitors; the only file text that ever leaves the server is the two exceptions above: a changed persistence file, and the first 200 bytes of a file the web-shell scanner flagged.
Password hashes. The agent reads /etc/shadow only to tell whether an account has an empty password, and sends that yes or no.
Private keys. The agent reports public-key fingerprints from authorized_keys; it does not read private key files.
Network packet contents. Connections are read from the kernel's tables, never captured.
Shell sessions, commands typed, or process environments.
Anything from a server other than the one it runs on.

Data flow

Server → SecAI → named processors, and nowhere else.

The agent makes outbound HTTPS connections to secai.techsteps.ae only, through Cloudflare, and accepts no inbound connections. When it has failed to reach SecAI three times in a row it opens a TCP connection to port 443 on 1.1.1.1 and on 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.

On the platform, telemetry is stored per organisation and turned into findings. Some processing leaves the platform, each with a named recipient:

OpenAI (United States): AI security audits, re-checks after a fix, the safety check before a one-click fix, screening of flagged files, and the in-app assistant. Receives security data about your servers: findings, package versions, configuration state, and the file excerpt described above.
OSV.dev (Google, United States): Vulnerability lookups for installed package names and versions.
TheIpAPI (United States / global): Country and network of an attacking address, so an alert can say where an attack came from. Addresses on your own servers are never sent.
Google Safe Browsing (United States): Whether a website you asked SecAI to monitor is flagged as dangerous.
Sentry (United States / global): Error reports from SecAI's own software, configured not to send personal data.
SecAI's own mail server: Alerts, reports and account email.
PayPal (United States / global): Subscription billing. SecAI never sees full card details.
Cloudflare (global): DNS, TLS termination at the edge and traffic delivery.

Data residency

SecAI platform infrastructure is UAE-hosted, supporting NESA and PDPL data residency expectations. The exception is AI processing: audits and the other OpenAI uses listed above are processed in the United States. The Privacy Policy has the full statement.

Since 24 September 2026 that exception can be turned off. AI processing is a switch on each organisation, and when it is off no request about that organisation reaches the United States at all. It disables all five uses listed above: AI security audits, the re-check after a fix, the safety check before a one-click fix, the screening of a flagged file, and the in-app assistant. Everything else works exactly as before, and the checks that do not need a model are unaffected.

A provider managing accounts on your behalf can set it for their whole book, and a client cannot turn it back on: the effective answer is the switch on the organisation and every provider above it. Turning it off is an ordinary setting; turning it back on where a provider has disabled it needs that provider.

One test in the codebase reads the source for every place a request to the AI provider is built and fails the build if one of them is not behind this switch. That is how the statement above is kept true as the product changes, rather than by remembering.

Encryption and credentials

In transit: TLS between the agent and SecAI and between your browser and SecAI, terminated at Cloudflare's edge and again at the origin.
Agent credentials: Each agent authenticates with a bearer token that the platform stores only as a SHA-256 digest, never in plaintext, and signs its requests.
Commands: Signed by the platform (Ed25519) and verified by the agent before anything runs.
Account passwords: Stored hashed. Payment card details are handled by PayPal and never stored by SecAI.
At rest: Contact us for the current at-rest encryption arrangement for platform storage; it is not stated here because this page only states what has been verified.

Tenant isolation

Every request to the platform carries an organisation identity taken from a verified session or agent credential, and every record is stored and queried under that organisation. An agent is bound to one organisation by the enrolment token it was installed with and is rate-limited by its own identity, never by its address.

A service provider managing client organisations sees only its own client tree, and opens a client's dashboard through an explicit, time-limited, recorded access grant rather than a shared login.

What runs automatically

One action, and only on a server you set to Automatic.

Each server runs in one of two modes that you choose at enrolment and can change any time. In Awaiting Approval, every action waits for a person, including blocking an address. In Automatic, the platform adds exactly one thing: blocking an address that has been identified as attacking the server. That block expires by itself after 24 hours, your own and trusted addresses are exempt, and a "Let me in" link lifts a block that catches you.

Nothing else runs on its own in either mode. Hardening fixes, package installs, service restarts, account changes and file quarantine wait for a person. Quarantine waits for a person even when a person asked for it. The undo actions, lifting a block, removing a hardening fix and restoring a quarantined file, never need approval and keep working while automation is paused, so the way back is always open.

Survival mode is separate and per server: Off, Record only, or Protect. Every server starts at Record, which acts on nothing. Under Protect, while the server itself is being exhausted or cannot reach SecAI, the agent may cap or throttle the one process group responsible, freeze it, or drop a flooding source at the host firewall. It never kills a process, never touches init, SSH, itself, a database, a web server, a control panel or a live login session, journals every action with the value it replaced, and undoes it when the episode ends or on its next start.

What waits for approval

A proposed action reaches you with the action itself, the reason SecAI proposed it, the server and resource it affects, the effect in plain words, and, where one exists, how it is undone. Approving it in the dashboard is the approval; a fix you click yourself is not queued for you to approve a second time.

Two switches sit above every mode: a pause that stops all automation while undo actions keep working, and a global safe mode that the platform switches on by itself when fixes are being rolled back repeatedly across your servers.

Rollback

Undo before do: every configuration change keeps a copy first.

A configuration change goes through one path: a copy of each file is written to disk, the change is applied, the configuration is validated before any reload, the service is reloaded, and the service and SecAI's own control channel are verified afterwards. A failure at any step restores the copy, reloads again if needed, and reports what happened. The copy stays under /var/lib/securityemployee/snapshots on your server and is uploaded nowhere.

Every applied change has an Undo in the dashboard by its own id. Undo refuses if the file has changed since SecAI wrote it, because a later edit is somebody's work. Quarantine and restore use the same store: the file is made unreadable in place, never deleted or moved.

When a change is rolled back, that kind of change on that server goes back to waiting for approval, and three rollbacks across your organisation's servers in an hour switch on safe mode for all of them and email you what was attempted and what broke.

Retention

Incident and security event history: Kept for the history period of your plan.
Audit reports: Kept for the life of the account unless you delete them.
Automatic blocks: Expire after 24 hours. The sightings that led to a block are pruned after 24 hours.
Configuration copies for undo: Kept on your server, pruned by age and count in step with the platform's record, so neither side offers an Undo the other cannot run.
Assistant conversations: 180 days from the last message, then deleted; one you escalated to a person is kept.
Account closure: Platform data deleted or anonymised within 90 days, except where retention is legally required.

Supported systems

Architecture: x86_64 Linux with systemd.
Distributions: Current Debian and Ubuntu releases; RHEL-compatible distributions including Rocky Linux and AlmaLinux.
Firewall tools recognised: fail2ban, CrowdSec, iptables, ufw, firewalld, CSF.
Control panels recognised: cPanel, Plesk, DirectAdmin. Web servers: nginx, Apache, Caddy, and sites published by Docker.
Out of scope: Shared hosting without root, and anything that is not Linux.

Independent verification

SecAI is assessed through StackAttest, which boots the platform in its own sandbox and audits what it finds; the passport below is the current result and is maintained by StackAttest, not by this page.

The agent is not open source. What it does is documented on this page and in the documentation, the install script is readable before it runs, and the assessment tool's design and limits are stated on its own page.

SecAI passport on StackAttest ↗

Vulnerability disclosure

If you believe you have found a security issue in SecAI, the agent or this website, report it through the Contact page and choose "Report a security issue" (https://secai.techsteps.ae/contact?type=security_report). Include what you found, how to reproduce it and, if you have one, a proof of concept. You will get a human acknowledgement, we will tell you when it is fixed, and we will credit you if you want to be credited.

Please do not test against servers you do not own, and please do not access or alter another customer's data; if you reach it by accident, stop and tell us.

Security contact: https://secai.techsteps.ae/contact?type=security_report
Machine-readable: /.well-known/security.txt

Performance

No public benchmark has been published yet, so this page does not state CPU or memory figures. What can be said from the design: one statically linked binary of a few megabytes, no kernel module, collection from /proc and the kernel's own tables on an interval, and a survival layer that asks systemd to keep the agent out of the OOM killer's way rather than to reserve resources. A measured figure per distribution, with the method, will be published here when it exists.

Uninstall

From the dashboard, Uninstall is picked up at the agent's next check-in, usually within a minute; the agent then stops and removes itself. By hand, on the server:

sudo systemctl disable --now secai-agent
sudo rm -f /usr/local/bin/security-agent /usr/local/bin/security-agent.prev
sudo rm -rf /etc/systemd/system/secai-agent.service /etc/systemd/system/secai-agent.service.d
sudo rm -rf /etc/securityemployee /etc/securityemployee-agent /var/lib/securityemployee
sudo rm -f /etc/logrotate.d/secai-agent /var/log/securityemployee-agent-update.log
sudo systemctl daemon-reload

Firewall rules the agent added through fail2ban, CrowdSec or your firewall remain listed in the dashboard and in the tool that holds them, and can be removed there. Nothing else is left behind.

Trust should start before installation.