The AI is the analysis layer, not the sensor
A language model cannot secure a server, and SecAI does not pretend it can. What it can do well is read a large amount of structured state quickly, notice which combinations matter, and explain them in plain language. The state it reads is collected by the agent on the server, on an interval, without the model involved. The audit is the moment those facts are handed to the model with one question: given this host, what deserves attention first?
That division of labour is why an audit finding carries evidence. The model is asked to cite what it saw, and the dashboard shows the artefact next to the finding: the configuration line, the package version, the listening socket. A finding without evidence is a guess, and a guess is not something a person should be asked to act on.
What an audit looks at
- Exposed services: what is listening, on which address, and whether it should be reachable from the internet at all.
- SSH: the effective daemon configuration (sshd -T), not the file on disk, because an Include or an earlier directive often makes the file misleading.
- Packages: what is installed, which versions carry known vulnerabilities, and which updates are pending.
- Accounts and privilege: local accounts and their shells, sudo grants, setuid binaries, SSH authorised keys.
- Persistence: cron entries, systemd units and other places a foothold is kept.
- Posture: firewall state, automatic updates, disk pressure, failed units, time synchronisation, backups.
- Web roots and control panels where they exist, for integrity and hygiene rather than application logic.
Explainable findings
Every finding is presented the same way: a severity, a category, a title, what was observed, the evidence, and a recommendation. Where the recommendation is a change SecAI can make, the finding offers it as a proposed action; where it is not, it tells you how to do it yourself. A proposed action from an audit goes through exactly the same policy as any other: the only actions an audit may propose are blocking an address, installing a package update and applying a hardening fix, and each of them waits for your approval, with the change verified and rolled back if it breaks a service.
Findings are ranked, and the ranking is the point. A server with forty observations and three that matter should read as three that matter. The risk score on the dashboard is derived from the open findings, and it says how old it is, so a score from a fortnight ago is never mistaken for today's.
Cadence, allowance and cost
Audits run automatically once a week on every monitored server, and on demand from the dashboard whenever you want a fresh view. Each plan includes a monthly allowance of audits, shown on the pricing page, and automatic audits count against it the same as manual ones, because an audit you received is an audit you received. A weekly cadence was chosen deliberately: daily audits across a fleet were the largest line in the platform's own AI bill and rarely changed the picture from one day to the next.
Useful audit questions
- Which exposed services deserve review?
- Are the SSH settings weaker than intended, once Include files and defaults are applied?
- Which configuration changes would reduce the most risk for the least disruption?
- Which installed packages create vulnerability exposure right now?
- Is there a change on this server that deserves investigation rather than a fix?
What leaves the server for an audit
An audit sends security data about the server to OpenAI in the United States: findings, package names and versions, and configuration state such as the effective SSH settings. It does not send the contents of your databases, application files or mail. The two cases in which any file text leaves the server, a changed persistence file and the first 200 bytes of a file the web-shell scanner flagged, are stated in the Trust Center, and the second of them is also screened by the model. If your organisation's data residency rules prohibit that processing, audits can stay off; monitoring, blocking and file integrity do not depend on them.
Limits worth knowing
- A finding can be wrong. The model works from evidence, and the evidence is shown, but a recommendation is a lead to check, not a verdict. The Terms of Service say this plainly.
- An audit is not a penetration test. It reads the host from the inside; it does not attack it from the outside.
- An audit does not make an organisation compliant. It produces evidence that a compliance programme can use.