Back to Blog
wordpress-7 ai-governance developers wp-ai-client agencies

WordPress 7.0: Which Plugins Are Calling Your API Key?

Axtolab —

You open your Anthropic billing dashboard on Monday morning and see $180 in charges from the weekend. Your staging site was offline, so it wasn’t that. Production is running 28 active plugins. Any one of them could have generated those calls.

Your next move is to open the WordPress admin and look for a log that shows which plugin made which AI request. That log doesn’t exist. Welcome to debugging AI spend on WordPress 7.0.

How the Shared API Key Works in WordPress 7.0

WordPress 7.0 introduces a centralised AI infrastructure that works through three layers: the Connectors screen, the AI Client function, and a single governance hook.

The Connectors Screen

Navigate to Settings > Connectors in your WordPress admin. You’ll find a configuration screen where you enter one API key per provider — Anthropic, Google, or OpenAI. That key is stored in the database and made available to every installed plugin on your site.

This replaces the old model where each AI plugin brought its own key management, its own SDK, and its own provider integration. From the plugin developer’s perspective, the shared infrastructure is a significant improvement. You call one function, get back a response, and never think about HTTP clients or authentication headers.

wp_ai_client_prompt()

This is the function at the centre of the architecture. Any plugin calls wp_ai_client_prompt() with a prompt string and optional parameters — model preference, max tokens, temperature. WordPress handles the provider routing, authentication, and request formatting.

There is no registration step. There is no approval gate. If your plugin is active and calls the function, it gets access to whichever API key is configured. The function is intentionally low-friction — it’s designed to make AI a platform utility, the same way $wpdb makes database access a platform utility.

For a developer shipping a single plugin, this is clean engineering. For an agency managing a client site with 30 active plugins, it means every plugin on that site has implicit authorisation to generate API charges on your client’s account.

Why This Design Was Chosen

The WordPress core AI team made a deliberate architectural choice. Bundling provider SDKs into individual plugins creates version conflicts, duplicated dependencies, and security patching headaches. A centralised client avoids all of that. The tradeoff is governance: when every plugin shares one credential, attribution becomes an infrastructure problem that someone has to solve.

What wp_ai_client_prevent_prompt Actually Gives You

WordPress 7.0 ships exactly one governance mechanism for AI calls: the wp_ai_client_prevent_prompt filter hook. Understanding what it does — and what it doesn’t — matters if you’re building tooling around WP 7.0’s AI stack.

It’s a Filter, Not a Budget System

The hook fires before every outbound AI request. If any callback returns true, the request is blocked. That’s the entire contract.

Here’s what a basic namespace-blocking implementation looks like:

add_filter( 'wp_ai_client_prevent_prompt', function ( $prevent, $args ) {
    $caller = $args['caller_namespace'] ?? '';
    $blocked = [ 'shady-seo-plugin', 'bulk-content-spinner' ];

    if ( in_array( $caller, $blocked, true ) ) {
        return true;
    }

    return $prevent;
}, 10, 2 );

This works. You can block specific plugin namespaces from making AI calls. But notice what’s missing: there’s no token counter, no cost accumulator, no daily or monthly ceiling. The filter receives the request context and returns a boolean. That’s it.

What Core Doesn’t Ship

The wp_ai_client_prevent_prompt hook is the correct interception point for governance logic. What WordPress 7.0 does not ship is any implementation that uses it for cost control:

  • No per-plugin token counter
  • No per-plugin monthly ceiling
  • No admin UI showing usage by plugin
  • No rate limiting per plugin namespace
  • No alerting when a plugin exceeds a threshold

If you want budget enforcement, you need to build the metering layer, the storage layer (a custom database table for call records), the admin dashboard, and the WP version compatibility work yourself. The hook gives you a place to stand. Everything else is on you.

The Attribution Problem in Practice

This is where the architecture creates real operational pain for agencies and developers managing production sites.

Provider Dashboards Don’t Help

Your OpenAI dashboard shows total token usage by day. Your Anthropic dashboard shows the same. Neither breaks usage down by the application-level caller that initiated the request. From the provider’s perspective, all calls come from one API key — they have no visibility into which WordPress plugin generated each request.

You can set up separate API keys per site, which helps with multi-site attribution. But within a single WordPress installation, every plugin’s calls are indistinguishable at the provider level.

The 30-Plugin Problem

A typical WooCommerce site managed by an agency runs 25 to 35 active plugins. Post-7.0, any of those plugins can add AI features in a routine update. A shipping plugin might start using AI to predict delivery windows. A review plugin might add AI-generated response suggestions. An inventory tool might use AI for demand forecasting.

None of these changes require the site owner to re-enter an API key or approve a new permission. The plugin updates, the AI feature activates, and the shared key handles the rest. You find out about it when your monthly API spend changes — or when a client asks why their bill doubled.

WP-Cron Is the Danger Zone

The highest-risk AI calls aren’t the ones triggered by a user clicking a button in the editor. Those are visible, interactive, and naturally rate-limited by human speed.

The calls that generate real spend are batch jobs running on wp_cron. A product description generator processing 500 SKUs overnight. A content audit scanning every published post. An SEO plugin re-evaluating meta descriptions across the site. These jobs run on schedule, with no interactive oversight, and the only feedback loop is your provider’s billing dashboard — checked days or weeks later.

The Manual Debugging Path

Today, if you need to trace which plugin is generating AI calls, your options are limited:

  1. Add error_log() calls inside the wp_ai_client_prevent_prompt filter to capture the caller namespace on every request
  2. Tail your debug.log and correlate timestamps with your provider dashboard
  3. Deactivate plugins one at a time and watch for usage changes over 24–48 hours

This is fragile, slow, and doesn’t scale. It also requires developer access to the server — not something every agency team member has, and not something you want to hand to a client asking why their invoice went up.

What Proper Governance Looks Like

The gap between WordPress 7.0’s AI infrastructure and what agencies need to manage client sites is well-defined. It’s not a philosophical disagreement about architecture — it’s a missing layer.

Per-Plugin Token Budgets

Every plugin namespace should have a configurable monthly token ceiling enforced at the Connector level. When the ceiling is hit, the wp_ai_client_prevent_prompt filter blocks further calls from that namespace. Hard stop, not a suggestion. The site owner or agency sets the budget, the enforcement layer respects it.

A Usage Dashboard

An admin screen that shows AI calls by plugin, by day, with token counts and estimated cost. Sortable, filterable, exportable. The same data you’d expect from any API management tool, applied at the WordPress plugin level.

Rate Limits and Monthly Ceilings

Beyond monthly budgets, per-plugin rate limits prevent runaway batch jobs. A plugin that suddenly fires 10,000 requests in an hour should hit a circuit breaker before it burns through a quarterly budget in a single cron run.

What’s Coming From Core

The WordPress core AI team has acknowledged the governance gap. The roadmap for WordPress 7.1, projected for August 2026, includes an observability dashboard with per-request logging, token counts, and cost estimates. That’s the right direction.

But WordPress 7.0 launches without it. Sites that enable AI between now and August are operating with the infrastructure layer but not the governance layer. For agencies managing client sites with real billing exposure, that’s a gap measured in months and dollars.

What We’re Building

The Axtolab AI Governance Plugin is designed to fill this gap ahead of 7.1. Per-plugin budget enforcement at the Connector level, an admin dashboard showing spend attribution by plugin and day, rate limits per plugin namespace, and hard monthly ceilings. Built on wp_ai_client_prevent_prompt — the hook WordPress core intended for exactly this purpose.

Get Ahead of the Gap

If you’re managing WordPress sites that will enable AI post-7.0, the governance layer isn’t optional — it’s the difference between controlled adoption and surprise invoices.

Join the waitlist at axtolab.com to get early access to the AI Governance Plugin. If you’re also managing external AI agent access to WordPress sites, take a look at the Agent Control Panel for broader permissions and access control.

Back to Blog