The problem is shaped differently at fleet scale
- Constant background attack traffic that must be handled without a person reading it.
- Customers who share a server, or a provider, and must never see each other.
- Control panels that put hundreds of sites, and hundreds of logs, on one host.
- Abuse reports that arrive from outside before anything inside noticed.
- Onboarding that has to be one command, because nobody will do more per server.
Which site, on which server
On a panel server the agent finds the sites the panel hosts and reads each site's own access log, the Plesk per-domain logs, the cPanel domlogs, DirectAdmin's, alongside nginx and Apache. A scanner probing one customer's WordPress, or a login flood against one store, is reported against that site, not as an anonymous event on the host, and the source address is blocked on a server set to Automatic. The panel's own login and privileged-action logs are read too, so a brute-forced panel account or an unexpected administrative action is a finding of its own. File changes in web roots are reported per site, and WordPress core, plugin and theme integrity is checked where WordPress is what runs.
What your abuse desk would otherwise hear about first
SecAI reads configuration, sending nothing, for the exposures that turn a customer server into somebody else's problem: a mail server relaying for anyone, a resolver answering recursive queries from the internet, a Tor relay or onion service, a database or cache port reachable from outside, services that keep failing, passwordless sudo rules, backups that quietly stopped, certificates that expired on live sites. Each is a finding with the evidence and, where one exists, a proposed fix that waits for approval.
Customers stay separate
Each customer is its own organisation: its own servers, findings, users and alert settings, scoped from the agent's enrolment token to every query. As the provider you see a fleet view across your customers, agent health, risk scores, incident counts, and you open a customer's dashboard through an explicit grant that is time-limited and recorded, rather than through a shared login. Website monitor health and per-server vulnerability detail stay inside each customer's organisation.
Under your brand
The reseller console creates client organisations, invites their owners, assigns each a plan tier within your own entitlement, and sets the brand: name, logo, primary colour and a custom domain through Cloudflare for SaaS. On your domain SecAI's own marketing pages are never served, the install command names your domain, and alert email carries your name. Assigning a plan does not create a billing relationship between SecAI and your customer; you keep it.
One command per server
Enrolment produces one install command per server, verified by SHA-256 and an Ed25519 signature before anything is installed, and the agent reports within a minute. It recognises the firewall the server already runs, fail2ban, CrowdSec, CSF, firewalld or iptables, and uses it rather than installing another. It needs root, so shared hosting accounts without root are out of scope; the server under them is not.
What it does not do
- It is not a web application firewall or a malware cleaner for hosted sites; a suspected web shell is quarantined in place on approval, never deleted.
- It does not stop volumetric DDoS at the host; that is your network's job, and the host reports what it saw.
- It does not aggregate compliance PDFs across customers; they are generated per organisation.