What the agent sends, and what SecAI keeps

The cycle

Two loops run inside the agent. A heartbeat every 60 seconds says the agent is alive, which version it is and which operating system family it runs on; it is how the dashboard knows a server has gone quiet. A monitoring cycle every 60 seconds does the work: new authentication events since the last cycle, the process table, listening sockets and connections, file hashes, the package list, posture, and a loopback probe of each website on this server that you have asked SecAI to monitor, so an outage can be told apart from a network problem between the server and SecAI’s own checker.

Each collector runs inside a time budget, so a slow disk or a huge web root cannot stall the cycle, and a cycle that overruns is cut short rather than allowed to pile up; the agent’s own watchdog restarts it if a cycle ever hangs. Whatever a collector found rides on the next report. The same response that acknowledges a report carries any commands waiting for the agent, each a signed envelope it verifies with a key compiled into it; an unsigned, altered or replayed command is dropped.

The report

A report has 31 sections. The Trust Center lists the fields inside each; this is the shape, in the order a reader would group them:

Every section but the metrics is optional and empty when there is nothing to say; a quiet server’s report is small. A report above 512 KB is rejected, and SecAI opens a finding on that server saying so, because a rejected report is a blind spot and a blind spot should be visible. The usual cause is a very large number of cron or web files reported at once.

From agent 0.3.10, package_sources names, for each Debian or Ubuntu package built from a source package with a different name or version, the source it was built from, so SecAI can ask OSV.dev about the source package.

Each report carries the time the agent created it as well as the time SecAI received it, so a server whose clock is wrong, or whose link was down and is catching up, is read correctly rather than as a burst of events that all happened at once.

Written only when it changes

A report says what is true now; most of it is the same as a minute ago. SecAI keeps the current state of each inventory, the installed packages, the network adapters, the listening ports and services, the accounts, keys and setuid binaries, the posture and the sudo grants, and writes a row only when the report differs from what is stored. A package list that has not changed is not written again. Absence is a change too: an item that stops being reported is pruned from the inventory, on the server’s own clock rather than SecAI’s, so a server that was offline for a week is not emptied by the gap.

That is why the dashboard can show when something last changed rather than when it was last reported, and why a thousand quiet servers cost a database almost nothing.

What never leaves the server

• File contents. Monitored files are hashed. The two exceptions are stated on the Trust Center: the before-and-after text of a changed persistence file, and the first 200 bytes of a file the web-shell scanner flagged.
• Password hashes, private keys, packet contents, shell sessions, process environments. Not read, so not sent.
• Backup archive names and contents. The backup check reports the newest archive’s size, age and count per destination, never a filename, because a filename can carry a customer’s name. That a destination is configured is reported; no credential, endpoint, bucket or path is ever read.
• Configuration copies for undo. Every change the agent makes keeps a copy of the file it changed on your server, under its own state directory, and that copy is uploaded nowhere.
• Anything from another server. The agent reads only the host it runs on.

How SecAI knows a report is genuine

Each agent authenticates with its own bearer token, issued at enrolment and stored by the platform only as a SHA-256 digest, and signs its requests. A report is accepted for one server and one organisation, the ones the token was issued for, and an agent is rate-limited by its own identity rather than by its address. The release the agent runs was itself verified on your server before it was installed: a SHA-256 baked into the install script and an Ed25519 signature checked with a key published on the Trust Center.

How long each record is kept

Retention is enforced by a scheduled job, not by housekeeping, and each horizon is configuration rather than code. These are the defaults in force:

Two clocks are easy to confuse. The retention above is how long SecAI stores a record. The history window of your plan is how far back the dashboard shows findings, and it can be shorter than the storage. A replaced agent’s row is removed only once another agent has served that server for 30 days, never on age alone, because an idle agent can come back.

Where it is processed

Reports arrive over TLS through Cloudflare’s edge and are stored and processed on SecAI’s platform in the United Arab Emirates. Notification email is delivered through a provider in the European Union. AI processing, where a customer has it switched on, happens in the United States with the uses the Trust Center lists; it can be switched off per organisation, and a provider can switch it off for every client beneath it. Error reports from SecAI’s own software carry no request bodies, query strings, cookies or database parameters.

What is not stated here

The agent’s own CPU and memory use. No benchmark has been published yet, so neither this page nor the Trust Center states a figure. What can be said from the design is on the Trust Center: one statically linked binary, no kernel module, collection from /proc and the kernel’s own tables on an interval. A measured figure per distribution, with the method, will be published when it exists.

Questions people ask

Read next