Agent Abilities for MCP is a plugin about WordPress MCP security, so when we find a gap in our own code, the honest thing is to fix it and say so out loud. Version 1.3.0 does both. It turns OAuth off by default on new installs, and it closes a set of real weaknesses in the way the plugin gates access to your site. A plugin that sells governance has no business shipping the same weaknesses it warns everyone else about, so we went looking. This is what we found.
Why a governance plugin is publishing its own security gaps
The pitch of this plugin is that an AI agent connected to your WordPress site is off by default, least privilege, and fully audited. That claim only means something if the code behind it holds up under pressure. Quietly patching a security issue and hoping nobody notices would contradict the entire point. If you are trusting us to be the gate between an agent and your content, you deserve to see the gate get fixed in the open. So the release notes name each issue plainly, and this post walks through them in the same spirit. You can read our security model for the standing policy, and if you ever spot something we missed, please report a vulnerability.
OAuth is now off by default on new installs
New installs of 1.3.0 ship with OAuth turned off. Previously it was on, which meant a fresh install exposed an authorization surface before the site owner had decided they wanted one. That is the wrong default for a plugin whose whole argument is that nothing should be reachable until you choose to reach for it.
If your site already had OAuth on, updating does not touch that. It stays on, and your existing connections keep working exactly as they did. We do not flip a live setting out from under you. The new default only applies where there is nothing to break, which is a brand new install with no connections yet.
Warning an administrator before they approve a client
The OAuth consent grant had a phishing problem. A malicious client could walk an administrator through an approval flow and get a connection authorized under an administrator account, which is the most privileged approval you could hand out. The fix is a warning. The consent screen now tells you clearly when the account about to approve a connection is an administrator, so a high privilege grant is a deliberate act rather than something you click through on autopilot. Least privilege starts at the moment of connection, and this puts the decision back in front of the person making it.
A REST API lockdown no longer silently cuts your OAuth connections
Some hardening setups lock down the WordPress REST API. That is a reasonable thing to do, but it used to cut off your OAuth connections without saying anything, and a connection that stops working with no explanation is its own kind of security problem, because you cannot reason about a system that fails quietly. The settings screen now warns you before a REST API lockdown would sever those connections, so you can make the call with the consequence in view.
Making sure the capability gate is actually still running
The capability gate is the core of the plugin. It filters which abilities an agent can even see, and then re-checks the caller’s capability again on every single call, so discovery and execution are two independent checks rather than one. We found a case where the gate could quietly stop enforcing if another copy of the adapter loaded first and won. The plugin now verifies that the running adapter still applies the filter, and it confirms this by watching for a real call rather than matching a string that might just look right. If the check that keeps an agent in bounds can be displaced without anyone noticing, it is not doing its job, so it now confirms it is still in place.
Least privilege in practice: update-user now requires edit_users
The update-user ability did not require the edit_users capability. In practice that meant an agent could change its own account in ways that went beyond the capabilities that account actually held, which is exactly the escalation least privilege is supposed to prevent. It now requires edit_users, so editing a user is gated behind the capability WordPress already uses for editing users. The rule is deliberately dull: an ability should never let an agent reach past the permissions of the account it connected as.
Bridged abilities are treated as destructive until proven safe
The Abilities Bridge lets abilities registered by other plugins flow through the same governed pipeline. A bridged ability that arrives with no destructive annotation used to be assumed safe. We flipped that assumption. With no explicit signal, a bridged ability is now treated as destructive rather than harmless, because the safe default when you do not know is to be careful. To make that visible, the Abilities Bridge directory now shows each bridged ability’s effective permission, not just its name, so you can see what a third party ability can actually reach before you allow it.
What transparent patching says about how we build
None of these changes alter the governance model, they enforce it. It stays off by default, least privilege, two independent capability checks, and an audit log that records denials as well as successes. If you want the full picture, here is how the off-by-default governance model works, and the safety controls cover the rest of what you can turn on.
Updating to 1.3.0 is the short version of everything above. If you run the plugin, this is a good one to take.