WordPress 7.0 Put an AI Agent Behind Your Login. Here Is What That Means.
By Stu 5 min read
WordPress 7.0, released in May 2026, shipped an entire AI and agent stack into core. Most of the coverage framed it as a feature. It is a feature. It is also the largest new attack surface WordPress has added in years, and on some hosts it is switched on before you have touched anything. This post is what actually changed, why it matters for security, and the specific things to check on your own sites.
What landed in core
Four pieces, and they build on each other.
The WP AI Client is a provider-agnostic PHP client that lets code talk to OpenAI, Gemini, Anthropic and others through one interface. The Connectors API stores the credentials for those providers so an admin can paste in a key once. The Abilities API is a registry where plugins declare discrete, machine-readable capabilities: "create a draft", "list users", that sort of thing. And the MCP Adapter exposes those abilities to Model Context Protocol clients, the same protocol Claude Desktop, Cursor and VS Code speak.
Put those together and the picture is clear. An external AI agent can connect to your WordPress site, ask it what abilities it exposes, and invoke them. Authentication is via Application Passwords over HTTP. That is not a side effect. That is the design.
Why this is a security story, not just a feature story
The core problem is that an ability does not know who is calling it. When a plugin registers an ability, it attaches a permission callback, the same pattern the REST API has always used. That callback is the entire access-control surface, and it runs the same way whether the request came from a logged-in editor clicking a button in wp-admin or from a remote agent connecting over the network.
There is no sandbox. An ability written on the assumption that only a human already looking at the screen would ever trigger it is now reachable by an automated agent that is not. If that callback is weak, missing, or assumes context that no longer holds, the ability is exposed to anything with a valid Application Password.
The working rule is simple. Treat every registered ability as if it can be invoked remotely by an untrusted agent, because it can.
Three specific things to check
Your provider API keys are probably sitting unencrypted in the database. The Connectors API stores them there in plain form. If your database is ever dumped, through a backup that travels, an injection flaw in some unrelated plugin, or a compromised host, those keys go with it. A leaked provider key is a bill and a data-exposure problem on someone else's platform, charged to you. Define keys as constants in wp-config.php or pull them from environment variables instead, so they never touch the database.
Some hosts have already wired this up for you. SiteGround, for one, pre-configured its own AI Agent plugin as the default connector across its estate, which means the connector was live before the admin had read a word about any of it. Do not assume a clean slate. On any managed host, check whether an AI connector, an agent plugin, or the MCP adapter is already active.
There are no cost controls in core. An ability that calls a paid provider will keep calling it for as long as something keeps invoking it. A compromised credential or a runaway automation can burn through provider credit with nothing in WordPress to stop it. Set spending limits and alerts in the provider's own dashboard, and watch for unexpected usage the way you watch for unexpected traffic.
If you are not using any of this
The safest configuration for a site with no AI workflow is to have none of it reachable. Turn off the MCP adapter so no abilities are exposed. Disable Application Passwords, which removes the credential an agent would authenticate with in the first place. Do not add provider keys to the Connectors dashboard. You lose nothing you were using, and you close the surface entirely. You can always re-enable it deliberately, for a specific job, with a dedicated least-privilege user, when you actually have a reason to.
If you are using it
Give each agent its own dedicated WordPress user, never your administrator account. Scope that user to the lowest role that does the job. Name each Application Password for what it is, so an audit six months from now tells you what it was for. And review those passwords regularly, revoking anything you no longer recognise. An agent credential you forgot about is exactly the kind of thing that is still valid long after the project that created it ended.
Where this fits
The Protect My WP handbook now covers the AI and MCP attack surface in Chapter 14, from auditing what your site exposes through to keeping provider keys out of the database and scoping agent users properly. Chapter 3 covers the Application Password hygiene the whole thing depends on. The AI stack in WordPress 7.0 is genuinely useful for the right workflow. It is also remotely reachable by design, and it deserves the same care you would give any other account with a key to the building.
Get the book for £19.
Get the free WordPress Security Checklist
The security checks I'd run through on any WordPress site, delivered straight to your inbox.
Want to go deeper?
The first chapter of Protect My WP is free. Start with the foreword, then read Chapter 1 on hosting and server security. There is also a shorter guide that walks the same ground faster if you want the shape of the book first.