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, which picks up the toolbelt's abilities automatically because they carry the meta.mcp.public flag; and the Abilities Explorer in the official ai plugin, if you use it. 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. Enabled abilities are flagged meta.mcp.public, which is precisely what the adapter's default server exposes; 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. If you want an ability callable over REST but hidden from MCP, the agent_toolbelt_mcp_public filter does that per ability.

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 bugs or security issues that were fixed later, so treat it as a temporary measure.

WordPress.org only publishes checksums for plugins it distributes. Premium, custom, and single-file plugins have no official reference to compare against, so the ability reports them as skipped with a machine-readable reason — deliberately not as "clean", because no evidence is not a clean bill. Agents are told the same in the ability description.

Almost never, and never about you. The only HTTP requests it makes are health-check requests to your own site after a plugin update, and — only when you run verify-checksums — requests to WordPress.org's public checksums APIs carrying your WordPress version and locale (core scope) or a plugin's public slug and version (plugin scope). There is no telemetry, no phoning home, no external service.