How the threat data is made
The Threat Observatory is built from one thing: addresses SecAI blocked on customers’ servers, where the agent confirmed the block was applied. Everything published is a count. The attacker’s address is used to count distinct attackers and then discarded, and no customer identifier is stored or served at any point.
Where the numbers come from
Each SecAI agent watches its own server’s logs and kernel tables. When something crosses a threshold (repeated failed SSH logins, a scanner walking paths, a flood), the platform issues a block, the agent applies it with whatever firewall the server has, and reports back that it ran. Only a block the agent confirmed is counted. One that was proposed, refused, or failed is not an attack that was stopped, and is not in these figures.
An hourly job reads those confirmed blocks, groups them by day and by attack category, counts events, distinct source addresses and how many servers each group was seen on, and writes the counts to two tables. The public endpoint reads only those two tables. There is no code path from a public request to a customer record; a test proves it by deleting the customer tables and checking the endpoint still answers.
What is thrown away
- The attacker’s address. Counted to work out how many distinct attackers there were, then dropped. It is not in the published tables and not in the endpoint’s output.
- Every customer identifier. No hostname, no domain, no organisation, no server id, no username, no path, no log line, no payload. Servers are counted, never named.
- Anything about who was attacked. The published data can say that a category was seen on several servers. It cannot say which, and it cannot be worked backwards to a customer.
The minimum group size
A group, meaning a day or a category, is published only when it has at least 25 events and was seen on at least 3 servers. Anything smaller is not written at all, so a request cannot ask for it.
The reason is the size of the fleet. These figures come from 10 servers. On a fleet this size a thin group is not a statistic, it is a customer, and the floor is what keeps the two apart. Both numbers are configuration rather than code, so they can be raised without a deploy.
Where the record starts, and why it is not longer
Nothing before 1 September 2026 is aggregated, although SecAI holds blocks from months earlier. SecAI’s own blocking behaviour changed in early September, when blocks began expiring and an unblock loop arrived, and the months either side of that are not comparable. One of them holds eighty-five blocks where the next holds fourteen thousand.
A chart across that boundary would be a chart of SecAI’s release history presented as attacker behaviour. Starting the record after it is the honest way to show a trend, and it is why this page says so rather than quietly picking the flattering window.
Four things it does not measure
Each of these appears on other vendors’ threat pages. SecAI does not have honest data for them yet, and an estimate dressed as a measurement is worse than a gap.
| Not published | Why not |
|---|---|
| Attacking countries | About six per cent of blocked addresses have ever been geolocated, and they were looked up because somebody opened that finding. A chart from that sample describes SecAI’s operators, not the attackers. |
| Source networks (ASNs) | The same sample, the same problem. |
| Targeted ports and services | Not recorded on a block. Inferring a port from the kind of attack would be inventing the number. |
| Time to first attack on a new server | The obvious query returns a median of zero hours and it is wrong: it measures when SecAI started watching, not when the server came online. The claim needs a server watched from its first hour, and SecAI does not have one yet. |
Each of the four is a data problem rather than a policy one. If systematic enrichment or a watched-from-hour-zero server arrives, the measurement arrives with it, and this page will say when it did.
How often it is rebuilt
Hourly. The aggregate is rebuilt from scratch each time rather than added to, so a missed run costs nothing and a correction takes effect on the next pass. The Observatory page carries the time of the last rebuild.
Read next
See what your own server looks like
One read-only command, no account. It reports what an attacker would find, and changes nothing.