What a plugin can see, and where its view ends
A WordPress security plugin is PHP that runs when WordPress runs. Inside that boundary it does useful work: login rate limiting, core and plugin file comparison, user and role auditing, and a request filter in front of the application.
The boundary is the problem. The plugin only executes when a request reaches WordPress, it only sees what the PHP process is permitted to see, and it can be switched off by anyone who reaches the filesystem or the database. Compromises that begin with a stolen SSH key, a vulnerable system package, or another site on the same server never pass through WordPress at all.
This is not a criticism of plugins. It is a description of where they sit. Server-level monitoring runs as a system service outside WordPress, so it keeps observing when WordPress itself is the thing that has been compromised.
How a WordPress server is usually compromised
The initial vulnerability is often in WordPress: an outdated plugin, a weak administrator password, an unauthenticated file upload. What follows is where the damage happens, and almost none of it is visible from inside WordPress.
- A webshell is written into uploads or a theme directory, giving command execution that never touches wp-login.
- A cron entry or systemd unit is added for persistence, so cleaning the file changes nothing.
- Credentials from wp-config.php are reused against SSH and the database.
- A cryptominer is installed, which shows as CPU cost rather than as anything in WordPress.
- The server begins sending spam through PHP mail, and the IP is blacklisted before you notice.
- A second site on the same server is compromised through shared filesystem permissions.
What SecAI monitors on a WordPress server
- File integrity across WordPress core, plugins and themes (Pro plan and above), plus the sensitive system files outside the web root that a plugin never inspects.
- Webshells and suspicious PHP appearing in web-served directories, with an AI screening pass that is WordPress-aware, because a naive scanner flags legitimate plugin code constantly.
- SSH authentication and brute force against the server, with attacking addresses blocked automatically.
- Processes and resource patterns, which is how cryptominers and unexpected background jobs surface.
- Cron jobs and other persistence mechanisms, including entries added under other users.
- Installed OS packages matched to public CVE data: the PHP version, the web server, the database and everything else WordPress depends on.
- Website availability and TLS certificate expiry for the sites the server hosts. Pro plan and above.
Reinfection is a server problem, not a WordPress problem
The most common frustrating pattern is a site that is cleaned and then compromised again within days. Cleaning removes the visible symptom, usually modified files in the WordPress directory. It does not remove a cron entry, a modified system binary, an added SSH key or a second account.
That is why reinfection is a signal about the server rather than the site. Persistence lives outside the WordPress directory, which is precisely the area a plugin does not cover, and it is why a plugin-only cleanup can look successful and fail.
Using both, which is the sensible setup
Server monitoring does not replace a WordPress security plugin, and this page is not arguing that it should. A plugin does application-layer things SecAI does not: request filtering in front of WordPress, login throttling inside the application, and per-site user auditing.
The reasonable arrangement on a server that hosts WordPress is both: the plugin for the application layer, SecAI for the machine underneath and for every other site on it. SecAI also does not clean or rewrite your application files, which is a deliberate choice, so if automatic malware cleanup of PHP is what you need, a hosting-oriented product is a better fit for that specific job.
Agencies running many WordPress servers
If you maintain sites for clients, the per-site view is the wrong unit of work. One dashboard covers every server, with each one carrying its own risk score and open findings, separated by client organisation.
That turns "log into each server and look around" into reviewing what actually changed, which is the only version of this that survives contact with a busy week.