Somewhere on a small business owner's laptop this fall, an AI assistant is going to ask for a WordPress username and an application password so it can draft a post, update a product page or pull a list of recent comments. The request will look routine, and the plumbing behind it is now official WordPress infrastructure rather than a weekend plugin experiment.

The WordPress Abilities API gives plugins and core a standard way to declare discrete actions a site can perform, and the WordPress MCP Adapter translates those actions into the Model Context Protocol so AI clients can find and run them. The adapter signs in with an application password, and an application password carries the authority of the person who made it, which means the safety of the whole arrangement depends on which account you hand over and what you allow that account to expose.

What the Abilities API Actually Registers

The developer handbook describes the Abilities API as a way "to register and discover distinct units of functionality within a WordPress site," and it is available only on WordPress 6.9 and above, according to the official documentation. Each ability is a named action with defined inputs and outputs, along with what the handbook calls a permission callback, "an optional function that determines if the current user can execute a specific ability."

The word optional deserves attention from anyone installing third-party plugins that register abilities, because a plugin author decides how carefully each action checks who is calling it. By default, registered abilities are not exposed through the REST API at all, and where they are, the endpoint documentation says execution is restricted by that permission callback, with application passwords listed as the recommended method for external access.

Jason Adams, who represents the WordPress AI team, framed the API as a basic building block. "Abilities introduce a new functional primitive to WordPress, the need for which was hiding in plain sight," he wrote on the Make WordPress AI blog. "The more plugins that use Abilities, the more powerful WordPress becomes."

What changed in 7.0 and 7.1

WordPress 7.0, released May 20, 2026, added an AI Client in core and a Connectors screen under Settings for managing model providers, with Anthropic, Google and OpenAI as the three defaults, according to the 7.0 Field Guide, which also notes that the Abilities API is integrated directly into that client. WordPress 7.1 followed on August 19 with a new wp_ability_invoked action that fires each time an ability runs, plus filters for validating inputs and outputs, as a developer note explains.

That new action matters to site owners more than its name suggests, since it gives logging and security plugins a single place to record every time an agent does something. The abilities core itself ships remain mostly read-only, such as site information, user information and environment details.

How the MCP Adapter Connects an Agent

The adapter's GitHub repository describes it as a bridge that lets MCP clients "discover and invoke WordPress plugin, theme, and core abilities programmatically." It requires WordPress 6.9 or later, serves an HTTP endpoint at /wp-json/mcp/mcp-adapter-default-server, and pairs with a small proxy that turns a desktop AI client's local connection into REST calls to your site using a username and an application password.

Pascal Birchler, a core contributor, set out the security model when the project was announced in July 2025. "For security, the MCP adapter will leverage the built-in application password mechanism for authentication and the capabilities system for granular authorization," he wrote on Make WordPress AI.

The default server exposes only abilities a plugin has flagged as public, and anything without that flag stays reachable only through a custom MCP server that lists it explicitly, according to the repository's documentation. The current release is version 0.6.1, published in August, which means the project is still short of a 1.0 and still outside the WordPress.org plugin directory, although contributors said in a September 16 meeting summary that it was ready to be submitted there.

The Gap in the Middle: Application Passwords

Application passwords arrived in WordPress 5.6 in late 2020 as a way to authenticate API requests without handing out a real login, and the integration guide published then made a promise that still has not been kept. "In future versions, the expectation is to include the ability to scope a given application password to limit its access," George Stephanis wrote.

Nearly six years later, an application password still authenticates as the user who created it, with every capability that user's role carries. An administrator who generates one for an AI client has effectively given that client administrator reach over anything an exposed ability can touch, whatever the agent was meant to do.

The roadmap for WordPress 7.2, published September 18 and pointing to an early December release, lists a goal to "develop a model for agents to have auditable identities, appropriate permissions, and access that can be managed independently of human accounts." The same roadmap plans to explore write abilities in core, which will widen what a connected agent can change.

Why the Risk Is Not Theoretical

The OWASP Top 10 for large language model applications names this failure pattern directly. Its entry on excessive agency traces damage to "excessive functionality; excessive permissions; excessive autonomy," and advises limiting the permissions extensions receive "to the minimum necessary" while requiring a human to approve high-impact actions.

The tooling around MCP has already produced serious bugs. In July 2025, GitHub published an advisory for CVE-2025-6514, a critical flaw rated 9.6 in a widely used proxy package called mcp-remote that allowed OS command injection when a client connected to an untrusted server, fixed in version 0.1.16, as the advisory records. That package is separate from the Automattic proxy the WordPress adapter documents, yet the episode shows how much trust flows through small connector programs on a user's own machine.

WordPress itself is not getting quieter. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42 percent increase over 2024, with 91 percent in plugins and 46 percent not fixed in time for public disclosure, according to its 2026 security report, which also put the weighted median time to first exploit at five hours. We walked through what that window means for a solo operator in our guide to unattended maintenance and alert fatigue.

Oliver Sild, Patchstack's chief executive, was blunt about stored AI credentials when WordPress 7.0 added provider keys to the dashboard. "I don't think much can be done to be honest," he told The Repository in May, explaining that a vulnerability granting full control of a site exposes the keys however they are stored.

A Setup Checklist for Small Sites

Start with a dedicated user account for the agent, created with the lowest role that can do the job, which for drafting content is usually Author or Contributor rather than Editor, and never an administrator. Generate the application password under that account, name it after the client that will use it, and record the date so you know when to rotate it.

Run the first connection against a staging copy of the site, since a misread instruction on staging costs nothing. Most managed hosts offer one-click staging, and the WordPress 7.1 plugin breakage in August was a reminder of how quickly a production site can fall over when untested changes land.

Audit which abilities your plugins register and which are flagged public before you install the adapter, and prefer a custom MCP server that lists only the handful of actions you want the agent to use. The AI plugin's 1.3.0 release in August stopped registering custom abilities for MCP automatically, according to the release notes, so exposure now requires a deliberate opt-in.

Keep a person in the loop for anything destructive, publishing or deleting included, by configuring your AI client to ask before it calls those tools. Check the Last Used and Last IP fields that WordPress shows beside each application password on the user's profile, and revoke the password from that screen the moment a connection is no longer needed, as the administration handbook describes.

WordPress runs on 40.2 percent of all websites, according to W3Techs, so the agent identity model promised for 7.2 will shape how a large share of the web lets software act on its behalf. Until it ships, the separate low-privilege account is the only scoping a site owner controls.