Is it safe to let an AI agent manage your WordPress site?

What has to be true for it to be safe?

Yes — provided the safety lives in the server, not in the model's good judgment. Letting an AI agent manage a WordPress site is safe when destructive actions require human confirmation, changes can be previewed and reversed, everything is recorded, and the most dangerous capabilities stay off until an administrator turns them on. Cowboy MCP is built on the assumption that the model will sometimes be wrong.

This page takes the question seriously instead of using it as a setup for a pitch. It starts with what can actually go wrong, then walks through each guardrail — what it covers, how it works in the code, and just as importantly, what it does not cover.

What can go wrong when an AI manages your site?

The realistic failures are mundane, not cinematic. The agent misreads your intent and acts more broadly than you meant. You make a prompt mistake and the agent faithfully executes it at scale. An API key leaks and hands a stranger the same tools your agent has. Or a long session drifts and the agent edits the wrong thing. None of these need a vulnerability — just automation plus ambiguity.

Each failure deserves its own weight. "Clean up the old posts" can mean three posts to you and thirty to the model. A bulk price update with a mistyped number is executed as faithfully as a correct one. A leaked key matters more here than with most plugins, because authenticated requests execute with administrator capabilities — that is what real site management requires. And an agent that reads untrusted content — comments, form submissions, scraped pages — can be nudged by instructions planted in that content, a risk shared by every AI agent, on WordPress or anywhere else.

The guardrails below are designed around exactly these failures: confirmation and preview against misread intent, undo against mistakes that got through, hashed and revocable keys with rate limits against leaks, and a complete audit trail so nothing happens silently.

How do safe mode and dry runs work?

Safe mode is on by default: any tool flagged destructive — deletes, resets, bulk overwrites — refuses to run until the call is resent with an explicit confirm: true, and the refusal includes a preview of what would have happened. A dry run is available separately: every non-read-only tool accepts a dry_run parameter that reports the intended change without executing anything.

Two honest limits. First, safe mode keys on each tool's destructive flag, so ordinary writes — creating a draft, updating a field — run without a confirmation prompt. That is deliberate: they are previewable, journaled, and most MCP clients ask you to approve every tool call on their side anyway. Second, for most tools the dry-run preview is a statement of intent — the tool, the target, and the exact parameters — not a simulated diff of the outcome. The plugin and theme install and update tools go further and resolve the real plan, including versions and download source, before you commit.

WP-CLI gets its own gate: under safe mode, any command outside a short list of known-safe prefixes requires confirmation, whatever its destructive flag says.

What gets logged, and can you audit it?

Every tool call, error, and authentication event is written to an audit log in your own database — timestamp, which key made the call, the tool, its arguments, the result, and the client IP. You can filter it by tool, key, event, and date range on the Logs tab in wp-admin, and entries are pruned automatically after 30 days.

Arguments are redacted before they are written: fields whose names look like passwords, tokens, or keys are masked, and bearer tokens are scrubbed out of free-text values. Failed authentication attempts are logged too, so a stranger probing your endpoint leaves a trail. The practical limit is retention — 30 days is the window, so if a dispute needs older history, export it before the prune. Everything stays on your server: the log lives in your database, and the only other copy is your server's own PHP error log, which is used if you opt into request logging or if a database write fails.

Can you undo what the AI did?

Usually — and the honest word is "usually". Every change made through a journaled tool is captured as a full before-state snapshot in an undo journal, so one bad edit rolls back from the Activity tab without touching anything else. For operations the journal cannot invert, one-click database checkpoints restore your site's database tables to an earlier point.

The journal covers the changes agents actually make: posts and pages, options, files, terms, comments, media, users, plugin and theme switches, WooCommerce products, orders, and coupons, and ACF field values. Checkpoints back it up where the journal can't reach — one runs automatically before any mutating WP-CLI command and before plugin and theme updates, both on by default — and if that automatic checkpoint fails, the failure is written to the audit log but does not block the command. Updates also take a file backup and run a post-update health check that restores the previous version automatically if the site breaks.

The limits, plainly: some actions have no inverse — a sent test email, a cache flush, an arbitrary WP-CLI command, a bulk stock update — and the journal records them as not-undoable rather than silently skipping them, so the ledger stays complete. Journal entries are kept for seven days by default. And checkpoints restore database tables, not your uploads or code files.

How are API keys protected?

A key is generated once, shown once, and stored only as a one-way hash — the plain key cannot be recovered from your database afterward, by you or by an attacker who dumps it. Each key can be revoked individually from the settings page, and requests are capped at 120 per minute per key by default, with a stricter per-IP throttle underneath.

That per-IP throttle — 30 requests a minute — applies to every request including failed authentication, which bounds brute-force guessing. A truthful caveat from the code itself: the rate limiter is transient-based and approximate under heavy concurrency, so treat it as a brake on runaway agents, not a hard security boundary. The deeper truth is that a valid key acts with administrator capabilities inside the plugin's guardrails, so handle it like an admin password: give each client its own key — the Claude and ChatGPT guides show where — revoke on any suspicion, and read the audit log to see exactly what a key did.

What stays locked unless a human opens it?

The most dangerous capabilities are off until an administrator opts in. Without power mode, the plugin blocks schema-destroying SQL (DROP, TRUNCATE, ALTER), refuses eval, shell, and database-reset commands in WP-CLI, confines file writes to wp-content, protects critical options like the site URL and user roles from writes, and rejects outbound requests to private and internal network addresses.

Power mode is a checkbox in wp-admin, and it cannot be switched on through the API — the plugin's own settings sit on a list of options that are never writable via MCP, so an agent cannot grant itself more power. Even with power mode on, some lines never move: the plugin's API keys and settings stay locked, queries touching password and session data are refused, credential fields stay redacted in logs and output, the last administrator account cannot be deleted, and safe-mode confirmation is unaffected.

Why does self-hosted matter for privacy?

Because the endpoint runs inside your own WordPress install, there is no relay in the path and no vendor database holding your credentials. Your AI client talks directly to your server, keys live there as hashes, and the audit trail stays local. The plugin sends no telemetry and phones home to no one.

The only outbound connections are to WordPress.org, when your agent installs or updates plugins and themes, plus any HTTP requests you explicitly ask for — and those are validated first: http and https only, with private, loopback, and cloud-metadata addresses rejected. The contrast with relayed setups is factual, not rhetorical: when MCP traffic passes through hosted infrastructure, your requests and content transit systems someone else operates, which matters under GDPR and client contracts. The WordPress MCP guide compares the architectures in full.

FAQ