Safety — five gates on every write
Most WordPress AI integrations are a thin wrapper over the REST API: the agent calls, something happens, and you find out by looking. SiteHelm is built the other way round.
Every write passes the same five gates in the same order, whichever of the operations it is, and whichever agent asked. None of them can be switched off from the agent's side — the plugin owns the gate, not the caller.
A write called without a plan token does not write. It returns a plan: the current value, the proposed value, and a token. Applying it is a second, deliberate call carrying that token.
The token is bound to the arguments it was issued for. Change one
of them and the token is stale — the plugin answers
StalePlan rather than applying a change you never saw.
Every one of the writes in the catalogue declares preview required. There is no operation that skips this.
SiteHelm authenticates as a real WordPress user through an Application Password, and every operation asks WordPress for a named capability against the specific object before it does anything.
An editor account gets an editor’s reach. There is no service account, no bypass, and no god-mode key: revoke the Application Password and the agent is out, immediately and completely.
Before a change lands, the prior state is snapshotted. After it lands, SiteHelm reads the site back and compares what it found against what the plan promised.
A write that lands but disagrees with its own promise is reported as
VerificationFailed, with completedSteps
saying how far it got. That is a different answer from success, and
the plugin will not round it up.
Supported covers writes that create rather than overwrite, where there is no prior state to keep.
A destructive operation must declare required.
Blast radius, not difficulty. A site-wide design token change is high risk even though it is a small edit.
There are exactly eleven ways SiteHelm says no. It is a closed set, and every one of them carries an operator-facing message and, where one exists, the remedy.
Check the Application Password, and that it is sent over HTTPS
Use an account with the required role
Activate Elementor, ACF, or Meta Box
Update the plugin
Correct the arguments; the message names the offending key
Re-read to get a current identifier
Re-read and retry
Take a fresh preview
Retry with a fresh plan
Inspect the site; completedSteps says how far it got
Fix by hand; the message says what is missing
A message written for the person reading it, and nothing written for an attacker: no a stack trace, a filesystem path, a SQL fragment, a database error string, an authorization header, and no a resolved IP address.
No eval, no snippet store, no theme-file editor. There is no path from an agent to executing code.
No query passthrough. Every read and write goes through a typed operation with a schema.
No arbitrary file writes, and no WP-CLI passthrough.
Nothing is destroyed without a snapshot that can put it back.
The audit ledger records what changed, when, by whom, and whether
the snapshot behind it can still restore the previous state. It is
readable from the plugin’s own Activity screen and through
audit-list, so the agent can check its own work.
Rollback is one control on that screen. There is also a global write pause, per-module and per-operation switches, and a revoke that ends a connection outright — none of which an agent can reach.
79 operations, and the controls that govern them, are all in the free plugin. Safety is not a paid tier.
Synthetic rows, drawn to show the shape of the log.
SiteHelm