Governance concepts

Other MCP-for-WordPress plugins sell how many tools they expose. This one sells control. You add reach as you build trust, not all at once, and every call is checked and logged before it runs. Six ideas hold that together.

Least privilege by design

The agent connects as a real WordPress user through OAuth or an Application Password, never an admin-equivalent key, and it can only do what that user can do. Over OAuth the connection takes the capabilities of whichever account approves it in the browser, so approve while logged in as the account you want the agent to be. Approving as an administrator gives the agent administrator reach, and the consent screen warns you when that is what you are about to do. With an Application Password you pick the account up front, so generate it on a dedicated low-privilege user.

Off by default

Nothing is exposed until you enable it, and updates never silently widen access. On a fresh install every ability is off.

Two-layer capability gating

A connection only sees the plugin’s own tools that its user can call, and every call re-checks that capability before it runs. Discovery and execution are gated separately, so an agent cannot call a tool it was somehow shown. Since 1.7.8, bridged tools from other plugins list for anyone who can edit posts, and the source plugin still decides each call. Sites can raise that floor with the aafm_bridge_discovery_capability filter.

Honest audit log

Every call is recorded, denied attempts included, with the principal and the argument keys and the identifiers it touched, never free-text content. For a failed call to another plugin’s bridged ability it also keeps that plugin’s error code, never its message. It lives in your own database and can be cleared from the admin.

Since 1.5.0 the log is an audit trail of governance as well as of calls. Every ability you switch on or off and every setting you change lands there too. Each row carries an event type, plus a detail column that names what changed and links to the object’s edit screen. So the log now answers a second question: who gave the agent this reach, and when. Before that release, enabling an ability was written with no audit trail at all.

What gets logged

Every ability call, whether it started, succeeded, errored, or was denied, with the acting user, the ability name, the argument keys, and a short note of the identifiers each call touched. Free-text argument content is never stored, so the log stays useful without hoarding sensitive content. Alongside the calls, every ability toggle and setting change, including switching read-only mode or the high-risk lock. Since 1.7.2 every MCP request that reaches WordPress is recorded too, so a sign-in with no calls after it means the request never arrived. Filter the log by successes, errors, or denials, and export what you are looking at as a CSV, filter and all.

Bounded by construction

There is no arbitrary option or meta access and no code execution. Uploads are checked by their real bytes against an image allow-list, whether the image arrives as inline data or, since 1.7.4, is fetched from an HTTPS URL by the upload media from URL ability. That ability is off until you enable it, refuses private, loopback, and link-local addresses, follows no redirects, and caps the size. It is the only outbound fetch the plugin will make on a call’s behalf. A created user gets the site default role, never admin, and the last administrator can never be removed. Anything destructive is off by default and capability-gated, and deletes go to Trash where the ability supports it.

A refusal, not a silent no-op

Elementor, Divi, Beaver Builder, and Avada keep their layout outside the normal post content. Before 1.7.4 a write aimed at one of those pages would report success and change nothing you could see on the front end, which is the worst kind of failure: the log said done, the page said otherwise.

Since 1.7.4 the plugin checks who owns a page before it writes, and refuses the call with an error naming the builder responsible. It covers update post, update page, update content item, replace in post, and restore revision, and a site-wide replace skips those posts and counts them separately rather than pretending it changed them.

This is a guard, not an integration. The plugin gains no ability to read or edit Elementor, Divi, or Beaver Builder layouts, and it does not claim to. Avada is the one exception, and only because it has two abilities of its own that read Fusion Builder markup and replace text without disturbing the shortcode tree. OptimizePress is not covered yet.

No data leaves your site

The plugin contacts no AI provider and no external service, and there is no telemetry. Your AI client connects in. The one time the plugin reaches out is the media upload from a URL added in 1.7.4, which fetches the single address passed to that one call, only when you have switched that ability on, and never your content or credentials.

Built on open standards

WordPress 6.9 ships the Abilities API, and the official MCP Adapter comes bundled with this plugin, so there is nothing else to install. Agent Abilities for MCP registers a curated, governed set of abilities on top of them rather than inventing its own protocol or transport, so there is no bespoke server to trust and the plugin inherits the standard’s behavior. What it adds is the governance layer described above.

Next steps

• Safety controls: optional guards you can switch on.
• FAQ: admin access, data handling, and how this differs from the REST API.