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 tools its user can call, and every call re-checks that capability before it runs. Discovery and execution are gated separately, so an agent cannot even see a tool it has no right to call, and cannot call one it was somehow shown.

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. 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. 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, no remote URL fetch, and no code execution. Uploads are decoded from inline data and checked by their real bytes against an image allow-list, never fetched from a URL. 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.

No data leaves your site

The plugin contacts no AI provider and no external service. Your AI client connects in; the plugin never reaches out. There is no telemetry.

Built on open standards

WordPress 6.9 ships the Abilities API and the official MCP Adapter. 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.