Inspect
Read the site context and the value you plan to change. Choose a supported action for that site and transport.
Change controls
Review the edit before WordPress receives it.
Supported edits separate inspection, preview and execution. Keep the target clear and check the result after applying the change.
Self-hosted · MIT licensed · Bring your own AI client
A specific change gets a specific review.
In guarded mode, the core value-edit tools require an approved packet. Where supported, the change digest binds the target, payload and prior state.
Preview
See the previous and proposed value. Review the exact target and any applicable correction checks.
Approve and apply
Approve the change packet, then apply the matching request. Pass the preview’s state check to catch edits made in the meantime.
Verify
Read the stored result back, then capture desktop and mobile screenshots with checks for expected text, overflow, headings, and broken images.
Check requirements as well as permissions.
An authorized edit can still remove something you meant to preserve. Active correction rules add checks for supported sites and fields.
Keep the required wording
Turn a specific requirement into a check for a named site and field. Supported edits are checked against active rules before they write.
Keep exceptions where they belong
A rule for one page stays on that page. A client preference does not become a rule for every site you manage.
Know the boundary.
Choose the tool and verification needed for the job.
Saved values are not full-site backups
Supported option, metadata and content edits save prior values. Do not assume an arbitrary operation, plugin update or raw PHP call can be undone automatically.
Approval is not identity separation
Local packet approval does not require a different human by default. Restrict tool credentials and access according to your team’s needs.
Verify the rendered page
WPGuard captures desktop and mobile screenshots and checks measurable failures such as missing text, overflow, headings, and broken images. Use focused interaction or accessibility tests when the task requires them.
Privileged access remains privileged
Administrative tools and bypass configuration require care. Read the full limitations →
See what each token can reach.
Treat every token as a credential for a trusted operator. None is safe to hand to an untrusted caller.
Recon
Reads options, metadata, files and private history, including secrets other plugins store in the database. It also includes magic login, which creates a WordPress login link.
Mutate
Adds content and file writes, SQL, snippets and sandboxed PHP. The PHP wrapper catches errors. It does not limit what PHP can do.
Admin
Adds raw PHP, WP-CLI execution and correction rules. Code runs with the permissions of the account you configured for that site.
The companion plugin is its own door
Anyone with the site's Application Password or legacy key can call the plugin directly. Those calls skip token scopes, packet approval, correction checks and the snapshot ledger. Restrict network access to that route.
Deploy it with these settings.
Much of the protection comes from how you run the server.
Bind to loopback
The server defaults to 127.0.0.1. Do not expose the port publicly. Reach it locally, or through a tunnel, tailnet or TLS proxy you control.
Leave the bypass unset
WPGUARD_BYPASS_GUARD=1 skips packet approval. It is meant for development. Correction checks still run, but keep it off for real sites.
Rotate and protect secrets
Tokens are static shared secrets. Rotate them on a schedule and after any suspected leak. Treat Application Passwords, plugin keys and SSH keys as credentials to the site.
Guard the state directory
It holds snapshots, imported history, correction examples and registry details. Captured values can include passwords. Restrict access and protect its backups.
Watch outbound hooks
If you turn on the cloud report or notify webhooks, packet metadata such as site, target, summary and status leaves the machine. Snapshot content does not. Point hooks only at endpoints you trust.
Separate clients by instance
Scopes are tool-level, not per-client. To isolate clients, run separate instances with separate registries, state and credentials.
Risks we track in the open.
These are not solved. Plan for them.
Prompt injection through site content
Read tools return live content that an attacker could have written. WPGuard wraps it as untrusted and flags instruction-like text. Your AI client still has to treat it as data.
Edits between preview and apply
expected_etag catches many changes made after a preview. It is opt-in, and it is not a database transaction across every editor and tool.
Self-approval
Approver names are attestations. If you need a second person to approve, enforce that in your own workflow.
Report a vulnerability privately
Do not open a public issue. Use GitHub Security Advisories on the repository. Include steps to reproduce, the affected version and the impact. Read SECURITY.md →
Give your next WordPress task to your AI.
Connect one site. Inspect it. Preview one useful change.