Security monitoring from outside the house.
A monitor that lives inside the site it protects can be switched off by whoever compromises it. Walter Sentry installs nothing there at all.
Two assumptions that stopped being true
Most WordPress security tools are plugins. That means they live inside the attack surface they're supposed to watch, and the same access that lets an attacker install a backdoor lets them deactivate the thing that would report it. A scanner that can be turned off by what it's scanning for is a scanner with a hole in the middle of it.
The second assumption is that malware is a file. It used to be. Now the interesting attacks don't touch a single PHP file: a payment skimmer stored in a database row and injected at render time, or an administrator created by quietly raising the permissions on a real customer's existing account, so no new user ever appears. A file scanner walks straight past both.
A store that was compromised for months while name-brand security plugins ran the whole time and caught nothing. Every check Walter Sentry makes maps to something that breach taught me, which is a different design input than a feature list.
How it watches
It logs in the way a developer would: over SSH, running WordPress's own command line tooling from outside, then comparing what it finds against a known-good baseline.
Connects from outside
Every check is implementable over SSH and WordPress's own command line tooling, driven from Sentry's server. To be exact about it: running a WP-CLI command does boot WordPress on your machine for the length of that command, the same as any developer's shell session. What never happens is anything persistent. No plugin, no must-use plugin, no hooks registered, no file written into the attack surface. Nothing of Sentry's is left behind for an intruder to find and disable.
Fingerprints the whole surface
Files, database contents, user accounts and capabilities, scheduled tasks, configuration, and the site's public HTTP behaviour. Baselines record what pristine looked like, and every subsequent run is a comparison rather than a guess.
Reconciles what WordPress says against what's really stored
Anything WordPress's own listing APIs report gets checked against the raw storage underneath. A plugin directory on disk that wp plugin list doesn't mention, or an administrator the users screen won't show you, is itself a critical finding. Hiding from the interface is the tell.
Checks what a visitor actually gets
Plenty of compromises show nothing to a logged-in administrator and serve a redirect to everyone else. Sentry requests the site the way a stranger and a search engine crawler would, and treats a difference between those two answers as a finding in its own right.
The rules every check follows
These are enforced in review. A check that violates one doesn't ship, which is the only reason a rule like this means anything.
Outside looking in
If a check would require running code inside WordPress, it gets redesigned rather than shipped. The architecture is the product; conceding it for one convenient check would concede it entirely.
No name-based skip lists
A scanner that trusts a file because of where it sits is structurally blind, and attackers write into popular plugins precisely because everyone skips them. Files are hashed and verified against official checksums or an explicitly pinned hash. Never trusted by path.
Every finding explains itself
A finding carries a stable identifier, the rule version that produced it, where exactly it was found, and the surrounding evidence. You triage from the report instead of re-running the scan and hoping it happens again.
Severity is not confidence
How bad a thing would be and how sure we are it's real are two different questions, so they're reported as two different values. Collapsing them into one number is how scanners end up either crying wolf or staying quiet.
Rules are versioned
Baselines record which rule version wrote them, so when behaviour changes it can be traced to the exact change that caused it rather than argued about.
One site is an anecdote. A fleet is a pattern.
Watching a single site, you can tell whether it changed. Watching many, you can tell whether the change is interesting. A file that appears on one site in a week is a question. The same file appearing across four unrelated sites in the same week is a campaign, and it deserves a much faster answer.
So findings are not evaluated purely in isolation. What a compromise looked like on one site becomes the shape Sentry looks for everywhere else: the specific paths, the plugin nobody remembers installing, the account created three hours before the payload landed. A single site cannot teach you the difference between noise and a pattern. Enough of them can.
"If I wanted this site, how would I take it?"
Checklists describe attacks that already have names. The ones that hurt do not have names yet.
The generative half of this work is sitting down with a site and asking, seriously, how I would compromise it and then stay. Not which CVEs apply. Where would I hide so that a file scan misses me? What could I change that nobody audits? Which piece of this system does everyone trust without checking?
Those answers turn into checks, and they tend to be the good checks, because they come from the attacker's side of the problem rather than the vendor's. Hiding in a database row instead of a file. Elevating an existing customer rather than creating a suspicious new admin. Serving clean pages to logged-in staff and something else entirely to everyone arriving from a search engine. Every one of those started as "if it were me, that's what I'd do."
Every real incident ends the same way: the mechanism that made it possible gets written down as a check, with the evidence that would have caught it earlier. The tool is not a fixed feature set. It's an accumulating record of things that actually went wrong, which is why it keeps getting better at a job that keeps changing.
What it's like to have running
Silent on a clean night. That's the point of a baseline: once a site is fingerprinted, an ordinary week produces nothing, so the alert that does arrive is worth reading. Findings come with evidence attached, so the first question, "is this real," is usually answerable without opening an SSH session.
This is a service rather than a download. It runs on my infrastructure, against your site, on a schedule, and I look at what it produces. If a site is compromised, you get the map: what changed, when it changed, and which parts of the system it reached.
Worried about a site, or already sure?
Both are worth a conversation, and they're different conversations. Tell me which one you're having.