WordPress 7.0's AI Abilities API: The Plugin Security Surface It Just Opened

WordPress 7.0 shipped on 20 May. Most of the launch coverage led with real-time collaboration and the new admin design, both of which are real improvements and neither of which changes the security model. The change that does change the security model got less coverage, partly because it is plumbing and plumbing is not interesting until it leaks.

What 7.0 actually shipped, alongside the visible feature work, was a set of three new core layers that together turn WordPress into an AI-agentic platform. The Abilities API lets a plugin register an AI-powered task. The WP AI Client is the provider-agnostic interface that talks to OpenAI, Anthropic, Google, or any compatible model. The Connectors API is the bit that holds the credentials. A site administrator authorises a provider once. Every plugin that uses the standard interface inherits that connection.

Reviewing the launch notes this morning, the architectural decision is reasonable, and the developer ergonomics are good. The security model that comes with it is new. The plugin trust model WordPress has been operating under since 2003 was built before site administrators were configuring credentials with a meter on them.

What Actually Shipped on the 20th of May

Here is the practical version, drawn from the WordPress Core team's launch documentation and the Abilities API handbook published on developer.wordpress.org.

A plugin author calls wp_register_ability( 'plugin-slug/ability-name', $args ) inside the wp_abilities_api_init hook. The ability now exists as a discoverable, callable interface. From that point, any process inside WordPress, including the AI Client, can call that ability and pass it a request. The plugin does not need to ask the site administrator for OpenAI access. The site administrator has already given that access once, at the Connectors API layer, and the WP AI Client mediates the rest.

Three things follow from that.

The first: the average WordPress site runs between 20 and 30 plugins, depending on whose figures you take. Each of those plugins, once it adopts the WP AI Client interface, has the same path to whatever AI provider the site has connected. The connection is not per-plugin. It is platform-level.

The second: WordPress core does not, at the time of writing, include a per-plugin budget cap, a per-plugin rate limit, or a monthly ceiling on aggregate AI spend. Those controls have to come from somewhere else. Either the AI provider's billing dashboard, or a third-party plugin that wraps the Abilities API with its own quota layer, or the host. None of those are in core.

The third: an AI provider API key is not the same kind of secret as a database password. A database password gives an attacker the data on the site. An API key gives an attacker access to a metered service that bills back to a credit card. The economic incentive to steal it is different in kind from the incentive to steal anything WordPress used to hold.

Security researcher Joost de Valk flagged the concern publicly on launch day, predicting a coming rush to steal AI API keys from WordPress sites running the new infrastructure, in a piece Search Engine Journal covered later that week. He is not wrong. The conditions for that rush are now in place.

Why This Is a Different Kind of Security Surface

This matters because the defensive playbook for a normal WordPress plugin vulnerability does not quite cover it.

A normal plugin vulnerability ends in one of three outcomes for the attacker. Data exfiltration, content modification, or a foothold for lateral movement to other targets. The standard defences scale to all three. Server-level intrusion detection, file integrity monitoring, behavioural malware scanning, web application firewalls. They work because the attacker's incentive is in the attack itself, not in the cost the attack imposes on someone else's account.

The Abilities API moves part of that incentive off-site.

A plugin that quietly calls a registered ability ten thousand times in an hour does not necessarily look like an attack. It looks like a plugin doing its job. The web application firewall does not block it, because the request is internal to WordPress. The malware scanner does not flag it, because there is no malicious file. The intrusion detection layer does not see it, because nothing is being exfiltrated from the site. The damage shows up on the AI provider's billing dashboard the next morning, at a cost the site owner did not authorise and has no real way to dispute.

Consider a marketing consultancy in Galway running WordPress with an OpenAI key configured for their content-assistance plugin. One of their other plugins, perfectly legitimate eight months ago, has changed hands quietly. A new owner has shipped an innocuous-looking update that registers an additional ability under a sensible-looking name. The next morning, the OpenAI bill is four figures higher than yesterday. The plugin update itself is technically valid code. The harm is real. The standard defences caught nothing because nothing in the WordPress system was technically misbehaving.

The WordPress security baseline that an Irish business should expect from a host is not wrong. It is just sized for the previous threat model.

The Economic Incentive That Makes This Worse

Plugin supply chain attacks were already a real problem in 2025 and into 2026. The Patchstack State of WordPress Security report catalogued 11,334 ecosystem vulnerabilities last year, 91% of them in plugins, with a weighted median time from disclosure to first exploitation of about five hours. That data was published before the Abilities API was a factor.

What changes the calculus is not the number of vulnerabilities, which was already high enough. It is the value of a successful compromise.

Pre-7.0, a compromised plugin on a typical small business site got the attacker a list of customer records, the ability to inject SEO spam, a launchpad for further attacks. Real damage, but bounded by the site's own data and reach. Post-7.0, the same compromise gets the attacker access to a metered service that bills back to the site owner's payment method. Different incentive. The same plugin authors who were holding off on attacks because the return-on-effort was not worth it now have a clearer reason to revisit that calculation.

Industry estimates put the resale value of stolen AI API keys in the thousands of dollars depending on the tier of access, with some long-running operations using stolen keys to power botnets and phishing automation rather than reselling them directly. The point is not the precise figure. The point is that there is one, and that there was not one before.

The structural picture, in plain terms: 7.0 is a positive release, the Abilities API solves a real plugin-ecosystem problem, and the same release has made every WordPress site running an AI provider connection a more attractive target than it was on the 19th.

What Standard Managed Hosting Catches, and What It Misses

This is where the operations side of the conversation gets honest.

A reasonable managed WordPress host catches a lot. Server-level intrusion detection picks up active exploit traffic. Malware scanning catches known-bad files when they appear. Web application firewalls block the common payloads. Brute-force protection at the login layer absorbs the noise. Outbound traffic monitoring, where the host runs it, can flag anomalous traffic to previously unseen domains, which is the layer that catches a phone-home backdoor after activation.

Here is what none of that natively catches: a legitimately-installed plugin calling a legitimately-registered ability against a legitimately-authorised AI provider, at an illegitimate rate.

Outbound traffic to api.openai.com is not anomalous if the site is using OpenAI on purpose. The volume might be anomalous, but the destination is not. A web application firewall scoped to block obvious payloads does not have a rule for "this is a sensible request, just being made far too often." File integrity monitoring sees no new files. The malware scanner is looking at the wrong layer.

What does catch the over-budget scenario is observability at a different layer entirely. The AI provider's own billing dashboard, configured with a hard spending cap and budget alerts at 50, 80, and 100 percent of monthly limit. The provider's rate limits, set at the API key level, which constrain per-minute and per-hour throughput regardless of which plugin made the call. The host's outbound logging, which gives you the data trail to figure out which plugin was responsible after the fact.

Detection-and-response at the provider layer. Forensics at the hosting layer. Neither alone is enough. Together they make the worst case bounded.

What the Web60 Stack Does With This

For Web60 sites, the layers that matter for this specific class of attack are observability and rollback, not pre-installation plugin vetting. We do not pretend to audit every line of every plugin every customer chooses to use. Nobody hosting at scale honestly can.

What we run instead is the activation-side and post-update defence. Sites run on the WordOps stack with Nginx, Redis object caching, FastCGI page caching, and the access-log discipline that comes with it. Automatic malware scanning runs against current threat intelligence. Pre-update snapshots are taken automatically before any plugin or core update, so the rollback path from a compromised update to a clean production environment is one click rather than four hours of restoring from off-site backup. One-click staging environments let customers verify a plugin update against a copy of the production site before deploying it live. Automatic nightly backups give you a clean reference point if a forensic question shows up later.

The advice we are giving Web60 customers running 7.0 is straightforward. Set a hard spending cap at your AI provider before configuring the Connectors API. Add budget alerts at 50 and 80 percent of that cap. Audit which plugins on your site declare an ability under the new API, which the Plugins screen now exposes natively. Make sure your backup is verified, not just taken. Web60's all-inclusive €60/year platform on Irish-sovereign enterprise infrastructure is built around that posture, which is the same posture we would recommend to any site owner whether they hosted with us or not.

Strategic concession, since it bears stating clearly: if you are running fifty WooCommerce stores with a dedicated operations team and a developer on staff to maintain a plugin allow-list, premium enterprise managed WordPress providers genuinely suit that workload. They run plugin allow-lists, code-review pipelines, and the staffing to maintain them. For most Irish businesses that is not the workload, and not the budget. For those who do run at that scale, that is the honest call.

The Five Checks Worth Doing This Week

Here are five checks that are worth doing this week if you are running, or about to run, WordPress 7.0 with any AI provider connected.

1. Set a hard spending cap on your AI provider's account. OpenAI, Anthropic, and Google all let you configure a monthly budget ceiling that suspends API access when reached. This is the single most effective control. It bounds the worst case to a known number rather than an open invoice.

2. Configure budget alerts at 50 and 80 percent of the cap. Alerts give you the early warning that something is consuming faster than expected. The first time you get an unexpected 50-percent alert is the trigger to investigate which ability is doing it.

3. Audit which plugins on your site have registered an ability. The 7.0 Plugins screen exposes ability registrations natively. Any plugin you do not recognise as a deliberate AI integration is worth a closer look. Disable the ones you do not need.

4. Verify your backup strategy actually restores. Restore a recent backup to a staging environment and confirm it runs. A backup you have never restored is a hope, not a backup. This is the same rule as before 7.0, but the stakes for being wrong are higher now.

5. Rotate the AI provider key if anything looks off. Provider keys are designed to be revocable. If you see usage you cannot account for, regenerate the key on the provider dashboard, update the Connectors API setting in WordPress, and you have cut the exposure. The historical pattern of plugin vulnerability incidents says the response time matters more than getting the diagnosis perfect.

This is not a one-time job. Like plugin audits, the cadence is probably quarterly for most small business sites, with rotations triggered by any ownership change or anomalous billing alert.

One Limitation Worth Naming

The defences described above limit the worst case. They do not prevent it.

A plugin that registers a sensibly-named ability and calls it at a sensibly-paced rate, drawing down a meaningful but not alarming amount of the monthly budget over weeks, is not going to trigger an alert at 50 percent or rate-limit at the provider level. The damage is real but slow, and it looks like ordinary plugin behaviour because that is exactly what it is mimicking. The defences against that scenario are upstream of any host: provider-side observability, audit logging that captures which ability called what, and the kind of cost monitoring that catches a slow drift rather than a spike.

That is uncomfortable to read if you wanted the answer to be "the host handles it." It is closer to "the host catches the spike, you catch the drift." Worth knowing before the first month of bills lands.

The Quiet Lesson

Three years ago, sitting in our morning operations review, we watched a customer's site burn through an entire month's email-delivery budget in a single afternoon because a plugin was retrying a failed SMTP connection in a tight loop. We had not been monitoring outbound API spend at the time because it had never been a thing that mattered. We changed our defaults that week, added outbound rate-limiting to the standard stack, and have not had a repeat. The Abilities API is the same lesson applied to a service that is roughly ten times more expensive per call.

The right answer is not to refuse to adopt the new API. The plumbing solves a real problem in the WordPress plugin ecosystem and the day-to-day benefits are substantial. The right answer is to put the controls in place at the layer the controls actually live in, which is the AI provider, not the WordPress dashboard. Then run the hosting stack that lets you reconstruct what happened if anything does.

Get a spending cap configured at your provider, audit which plugins now hold an ability, and verify your backup. That is this week's homework.

Frequently Asked Questions

What is the WordPress 7.0 Abilities API?

The Abilities API is a new core feature in WordPress 7.0 that lets plugins register specific AI-powered tasks and call connected AI providers through a shared interface. Combined with the WP AI Client and the Connectors API, it lets a site admin authorise an AI provider once, and any plugin using the standard interface inherits that connection.

Why does the Abilities API create a security risk?

Because AI provider authentication is now shared at the platform level rather than configured per plugin, a compromised plugin can use the site's AI credentials without needing to ask for them again. WordPress core does not include a per-plugin budget cap, a rate limit, or a monthly ceiling on AI usage. The plugin trust model was built before sites held billable credentials of this kind.

Should I avoid using WordPress 7.0 AI features?

Not necessarily. The Abilities API is genuinely useful for small business sites, and the security risks are manageable with sensible operational practice. The practical responses are to set spending caps on the AI provider's account, audit which plugins use the WP AI Client, and watch for unusual API usage.

Can my hosting provider block compromised plugin requests to AI APIs?

Outbound traffic monitoring at the hosting layer can flag anomalous traffic to AI provider endpoints, and that is one of the layers a managed WordPress host should be running in 2026. The harder layer of defence sits with the AI provider, where you can set hard spending caps, IP allow-lists, and budget alerts that limit the worst-case damage.

Does Web60 support WordPress 7.0 AI features?

Yes. Web60 hosts run PHP 8.2 and above, which WordPress 7.0 requires, and the managed stack handles staged upgrades, pre-update snapshots, and rollback paths. Customers can run the Abilities API on Web60 the same as on any compliant host, with the additional benefit of outbound traffic logging and one-click restore if anything goes wrong after a plugin update.

What is the most important thing to do this week if I run WordPress 7.0?

Set a hard spending cap on whichever AI provider you have connected. Most providers allow you to configure a monthly budget ceiling that suspends API access when reached. That is the single most effective control against a compromised-plugin scenario, because it limits the worst case to a known maximum cost rather than an open-ended bill.

Sources