Why plugin-level security is not enough at agency scale
A security plugin runs inside WordPress. That is a real boundary, not a criticism: it sees requests that reach WordPress, and it can be disabled by anyone who reaches the filesystem or the database.
At agency scale the boundary bites more often, because your exposure is the sum of every plugin on every site you maintain. One outdated plugin on one client site is enough, and the compromise that follows moves outside WordPress immediately: a webshell in uploads, a cron entry for persistence, credentials from wp-config reused against SSH.
Multiple sites on one server compound it. A compromise of the weakest site can reach the others through filesystem permissions, which is invisible from inside any individual WordPress install.
The reinfection problem, which is really a server problem
The pattern every WordPress agency knows: clean the site, and it is back within days. This is usually taken as a WordPress problem and it is almost always a server one.
Cleaning removes files in the WordPress directory. It does not remove the cron entry, the systemd timer, the added SSH key, the extra user account or the modified system binary that reinstalls the payload. All of those live outside the WordPress directory, which is exactly where a plugin does not look.
Monitoring the persistence paths is what turns a cleanup into a fix, and it is why the second compromise is the one that tells you the first cleanup was incomplete.
What this covers across your portfolio
- WordPress core, plugin and theme file integrity, where core has a knowable expected state so a modified core file is unambiguous. Pro plan and above.
- Webshells in any web-served directory on the server, AI-screened so ordinary plugin code is not constantly flagged. Pro plan and above.
- Persistence: cron entries, systemd units, authorized_keys, new accounts and privilege changes.
- SSH brute force against the server, blocked automatically, plus what happens after a successful login.
- Cryptominers and unexpected processes, the usual monetisation of a compromised hosting box.
- Outbound spam behaviour, which is how a compromise usually becomes a client emergency through a blacklisted IP.
- Site availability and TLS certificate expiry per site. Pro plan and above.
Where this sits next to your existing stack
It does not replace your WordPress security plugin and it does not replace a WAF. The plugin does application-layer work SecAI does not: request filtering in front of WordPress, login throttling, per-site user auditing. A WAF filters requests before they arrive.
It also does not clean or rewrite application files. If automatic malware cleanup of PHP is central to how you work, a hosting-oriented product does that specific job and SecAI deliberately does not, because silently editing a client site is a good way to break it.
What it adds is the layer none of those cover: the machine, every site on it, and the persistence that survives a cleanup.
Client separation and reporting
Each client can be a separate organisation with isolated data, with a fleet view across all of them for you. When a client asks whether their site data is mixed with another of your clients, the answer is no and you can show it.
Incident history per site and one-click PDF reports give you something concrete for a client review, which is easier to justify on a retainer than a general assurance that you keep things updated.