Agent Toolbelt – Safe Site Operations for AI Agents

No. The defaults are the product: read-only and low-risk maintenance abilities are on, the destructive ones (update, rollback, toggle, database cleanup) are off, every call is audited, and the status strip at the top of the settings page confirms it at a glance. You only open the settings when you want to grant more (enable a high-risk ability), grant less (observe mode), or try an ability yourself on the Run tab.

No — the application password is only for agents that talk to the site over the network. An agent with shell access uses the built-in WP-CLI commands ( wp agent-toolbelt list , wp agent-toolbelt run <ability> , wp agent-toolbelt log ) with the same guardrails, dry-run/confirm flow, and audit logging. What the plugin adds for such an agent is exactly the point: guarded, previewable, logged operations instead of raw destructive shell commands.

“Safe” here means: previewed, confirmed, backed up, health-checked, and rolled back automatically if the site breaks — with an audit trail. That’s more protection than a human clicking “Update now” gets. It’s still a change to your site, which is why the ability ships disabled and you must enable it deliberately.

Several layers: the destructive abilities are off by default; if you enabled them, execution needs a fresh one-time confirm token from a prior dry-run of the same request (a single malicious instruction can’t do both steps blindly); every call needs an authenticated administrator — content on your pages can’t call anything by itself; the hourly rate budget stalls a stampede; and observe mode lets you cut all write access with one checkbox while you investigate. The honest part: if your agent has admin credentials and is fully compromised, no plugin can save you — the toolbelt’s job is to make the destructive path narrow, slow, and visible.

WordPress core’s temporary-backup mechanism skips plugins that live in a single file, so there would be no backup to roll back to. Rather than update without a safety net, the ability refuses and tells the agent to use wp-admin or WP-CLI instead.

Everything except the abilities that change plugin files or state: update-plugin, rollback-plugin, and toggle-plugin refuse on multisite with a clear reason instead of guessing at network-wide semantics. Since 1.4 the audit log also heals itself on multisite: if a subsite is missing its log table (network activation only creates it on the main site), the first write creates it.

No. Every ability requires a logged-in user with manage_options (updates also need update_plugins ). Anonymous REST calls get a 401, and the abilities don’t even appear in the listing for unauthorized users.

Two ways: untick abilities on the Settings → Agent Toolbelt page (they unregister instantly), or add define( 'AGENT_TOOLBELT_DISABLED', true ); to wp-config.php — the kill switch unregisters everything: abilities, REST exposure, and the WP-CLI command. There is also a softer option: observe mode (see below) keeps the abilities visible but read-only.

A read-only switch for the whole toolbelt. While it is on (checkbox on the settings page, or force it with define( 'AGENT_TOOLBELT_OBSERVE', true ); in wp-config.php), agents can still call read-only abilities and preview any operation with dry-run, but every real change is refused with the machine-readable reason observe_mode and a message telling the agent to ask you. Useful while you are getting to know a new agent, or any time you want eyes-only access without hiding the tools.

Not for long. Real executions are rate-limited per user with a fixed hourly budget: 5 high-risk and 30 total mutating executions per hour by default (the agent_toolbelt_rate_budgets filter changes the numbers; define( 'AGENT_TOOLBELT_NO_RATE_LIMIT', true ); disables the limit for supervised bulk-maintenance sessions). Over-budget calls are refused with the reason rate_budget and a retry_after_s hint, and land in the audit log as denied — so a stampeding agent both stalls and leaves a visible trail. Dry-runs and read-only abilities are never counted: diagnosis stays free.

Because it deletes content — revisions, trashed posts, spam, orphaned rows. That is exactly what you want from a cleanup, but a tool that can delete rows the moment the plugin activates would contradict what this plugin promises. So you enable it consciously, once, on the settings page. After that the usual guardrails apply: dry-run with exact per-category counts, a one-time confirm token bound to the same input, batched deletes through core functions, and an audit-log entry plus an email for every real execution.

Only well-defined garbage, by category — and you can pass a categories list to run any subset: post revisions; auto-drafts older than 7 days; trashed posts; spam and trashed comments; expired transients; and orphaned post/comment/term/user meta rows whose parent object no longer exists. It never touches published content, drafts, users, terms, or settings. Posts and comments are deleted through WordPress core functions ( wp_delete_post , wp_delete_comment ), so cleanup hooks fire and caches stay consistent.

If you are logged in as an administrator, that’s on purpose — administrators always see the normal site. Open a private/incognito window to see what visitors get. Otherwise, a static page cache is probably serving visitors a cached copy: purge the page cache (there’s an ability for that) and reload. Maintenance mode always auto-expires, so a forgotten “on” can never lock the site permanently.

Three doors, all showing exactly (and only) what you enabled: the WordPress REST API listing at wp-json/wp-abilities/v1/abilities ; the official MCP Adapter’s default server, where since 1.6.0 each enabled ability is a tool named agent-toolbelt-<ability> and the server instructions carry the calling rules; and the Abilities Explorer in the official ai plugin, if you use it. Every ability that has a Run-tab example publishes it to agents too: as JSON Schema examples in the MCP tool’s input schema, and as meta.example_input in the REST listing (WordPress publishes draft-04 schema keywords only there, so examples itself is stripped). The Connect your agent section on the settings page turns this into a copy-paste briefing with your site’s real URLs.

Yes, out of the box. Since 1.6.0 the adapter’s default server lists each enabled ability as its own tool ( agent-toolbelt-<ability> , with title, description, input schema and examples, and the readOnly/destructive/idempotent/openWorld hints) and sends the toolbelt’s calling conventions as the server instructions, so a client knows the dry-run and confirm-token rules before its first call. The abilities also stay reachable the way they were before, through the adapter’s discover-abilities / get-ability-info / execute-ability tools, because they carry meta.mcp.public (and meta.public ) — you will see them both ways; it is the same ability and the same guardrails. Disabled abilities are not registered at all, so no transport can see them. Every MCP call still runs through the same permission checks, dry-run defaults, confirm tokens, rate budget, and audit log as REST — the transport changes, the guardrails don’t. Two filters: agent_toolbelt_mcp_public keeps an ability callable over REST but hidden from MCP; agent_toolbelt_mcp_direct_tools (return false) keeps a site on the adapter’s three meta-tools only.

The debug log is the one file on a WordPress site that routinely catches secrets — API keys inside stack traces, database credentials in connection errors, customer emails in mailer failures. That’s why redaction is built in and cannot be turned off: provider API keys, JWTs and bearer tokens, database credentials, URL query secrets, auth cookies and nonces, absolute filesystem paths, emails, and IP addresses are all masked before the content leaves your site. Two honest caveats: redaction is best-effort pattern matching (a secret in a format nobody has seen before can slip through — the response says so), and the search filter deliberately matches the redacted text, so an agent cannot use it to probe whether a specific secret value appears in the log. If that residual risk is still too much for your site, untick the ability — like everything else, disabled means invisible.

No, deliberately. Rollback downloads the target version from WordPress.org, which only hosts what it distributes — for premium and custom plugins there is no trusted source to fetch an old version from, so the ability refuses with a clear reason ( versions_unavailable ) instead of improvising. The same honesty rule as checksum verification: no evidence is not a green light.

Same product logic as update-plugin and cleanup-database: an ability that can swap plugin versions or deactivate plugins the moment the plugin activates would contradict what this plugin promises. You enable them consciously, once, on the settings page — and after that every execution still needs a dry-run, a one-time confirm token, and passes the health-check-and-revert cycle. A rollback also carries an inherent risk the tool warns about every time: an older version may reintroduce