WordPress 7.0 put AI API keys in the admin. Treat that as an operations policy, not a feature toggle.

WordPress 7.0 turns AI provider keys into site-level operational credentials. Before enabling a connector, decide who owns the key, who may spend against it and which plugins may use it.

On May 20, 2026, WordPress 7.0 "Armstrong" shipped with AI provider configuration inside wp-admin. That is useful, but the real change is operational: an AI connector key is now a site-level credential that can spend money, route data and widen plugin trust. Treat it like SMTP, payment and backup credentials, not like a harmless toggle.

TL;DR

Table of contents

What WordPress 7.0 actually changed

WordPress 7.0 added two pieces that matter here. The first is the AI Client, a provider-agnostic PHP API exposed through wp_ai_client_prompt(). The second is the Connectors API and Settings > Connectors screen, which gives administrators one place to configure external service connections. The 7.0 Field Guide groups these under the release's AI building blocks.

That sounds like WordPress "added AI." More precisely: WordPress added shared infrastructure that plugins can use. Changeset 61700 is the source I would keep pinned for this nuance. It says no AI providers are bundled out of the box and that WordPress will not send prompts or data externally without explicit configuration and explicit calling code.

The initial featured providers are Anthropic, Google and OpenAI, but their implementations are separate plugins on WordPress.org: AI Provider for Anthropic, AI Provider for Google and AI Provider for OpenAI. Installing WordPress 7.0 and installing a provider plugin are separate operational decisions.

That distinction matters for site owners who read headlines about AI in core. If you do nothing, nothing useful or risky happens by itself. If you install a provider plugin, configure a key and install code that calls the AI Client, the site now has a route to an external model provider. That is where policy starts.

For the broader release context, my earlier WordPress 7.0 overview covers what business owners will notice outside this credential question. Here I am focusing on the security and operations layer.

Why a connector key is an operations asset

A connector key is not just a secret string. It is three things at once.

First, it is a billing route. The provider account behind the key pays for requests, and WordPress core 7.0 does not ship a monthly spend cap, token budget or per-plugin cost dashboard. The WordPress AI GitHub issue about usage safeguards and cost awareness shows the need was recognized, but that should not be read as a core 7.0 budget feature.

Second, it is a data route. WordPress core does not decide what a plugin puts into a prompt. A plugin might send a post title, an image attachment, a draft paragraph, a WooCommerce product description, a form submission or a chunk of private page content. The AI Client provides the pipe; the calling plugin decides the water.

Third, it is a plugin trust boundary. The AI Client deliberately lets plugin developers avoid handling credentials directly, which is clean from an API design perspective. In practice, that also means enabling a connector makes the configured provider path available to installed WordPress code that calls the AI Client.

This is why the right question is not "should this site enable the AI feature?" A better question is: who owns the provider account, which plugins may use it, what data may leave the site and who gets the invoice when a bulk action suddenly generates 40,000 prompts?

Storage priority and the plaintext database problem

For api_key connectors, WordPress checks for credentials in this order: environment variable, PHP constant, then database setting saved through the admin screen. The Connectors dev note gives ANTHROPIC_API_KEY as an environment variable example, define( 'ANTHROPIC_API_KEY', 'sk-...' ); as a constant example and connectors_ai_anthropic_api_key as a database setting example.

That order is good for operations. In production, I would rather manage keys through deployment or hosting configuration than through wp-admin. An environment variable or PHP constant can override a database-pasted key, survive a database restore and keep the source of truth outside the content database.

But do not confuse that with sandboxing. In a Make/Core discussion under the Connectors API dev note, Greg Ziolkowski explains that the key is a site setting and every plugin can access it. He also notes that environment variables and constants are accessible to third-party code installed on the site. In other words: env vars and constants improve operational control. They do not make untrusted plugins safe.

The database path needs special care. Database-stored connector keys are masked in the UI, but the Connectors dev note says they are not encrypted. Trac #64789 describes AI provider keys as plaintext option values and keeps the security audit open under Future Release. Trac #64793 fixed a specific wp-admin/options.php masking issue for 7.0, but masking is still display protection, not encryption.

Practical consequence: if a live key is saved in the database, assume it can travel with database dumps, staging refreshes, local developer copies, backup archives and support exports unless you scrub it. Your staging script should know about connectors_*_api_key, not just OPENAI_API_KEY.

The plugin trust boundary

The trust boundary in WordPress is installed PHP code. That was true before AI, but AI connectors give the boundary a new kind of consequence: an installed plugin can potentially trigger external model calls through the site-level credential path.

This links directly to the older WordPress security problem: plugins are the largest practical attack surface on most sites. I wrote about that separately in WordPress plugins are your biggest security risk. AI does not replace that risk. It adds a new outcome when a plugin is sloppy, over-broad or compromised.

The subtle risk is not only key theft. A compromised plugin may not need to read or exfiltrate the raw key. It can spend against the configured provider account by making AI Client calls, and it can send sensitive prompt content if the plugin has access to that content in WordPress. That is a smaller step than stealing a key and using it elsewhere.

Agencies should therefore treat AI-capable plugins like payment gateways or SMTP plugins. Before approval, ask what triggers the call, which roles can trigger it, whether it runs in cron or bulk actions, which content fields it sends, whether it supports feature detection and whether it fails closed when no provider is configured.

The same logic applies to vendor lock-in and platform intermediaries. My post on the Cloudflare WordPress plugin security model covered how a plugin can become a bridge into infrastructure control. AI connectors are a different bridge, but the review habit is the same: the plugin is not just UI. It is a route into another account.

Controls WordPress 7.0 gives you

WordPress 7.0 does provide useful brakes. They are real. They are also incomplete.

The strongest global brake is this:

define( 'WP_AI_SUPPORT', false );

After changeset 62239, if WP_AI_SUPPORT is explicitly false, wp_supports_ai() returns before the wp_supports_ai filter runs. A plugin cannot simply re-enable AI support through that filter. For managed fleets and clients without an approved AI policy, this is the default I would choose.

For more granular control, the AI Client dev note documents wp_ai_client_prevent_prompt. That filter can stop specific prompt execution. When it prevents a prompt, no AI call is attempted, support checks return false and generation methods return WP_Error.

Feature detection is another important control point for plugin quality. Methods like is_supported_for_text_generation() and is_supported_for_image_generation() check whether a requested capability is available without making API calls or incurring cost. A plugin that assumes "WordPress 7.0 means AI is available" is not ready for production.

What these controls do not give you: per-plugin approvals in core, monthly spend caps, per-client budgets, a central audit trail, encrypted key storage or consent records. WP_AI_SUPPORT=false is a kill switch. wp_ai_client_prevent_prompt is a gate. Feature detection is an availability check. None of them is a complete operations policy.

What the separate AI plugin does not prove

The canonical AI plugin is worth watching because it is where practical governance ideas are already appearing. Its 1.0.0 release added Request Logging and Connector Approvals as experiments, and the Make/AI update describes them as observability and governance tooling.

That is useful signal. It is not a WordPress 7.0 core guarantee.

This distinction is easy to lose in client conversations. A site owner may hear "WordPress has connector approvals" and assume every 7.0 site has per-plugin approval before connector use. That is not what the core sources say. Core shipped the AI Client, Connectors infrastructure and the brakes described above. The companion AI plugin explores logging and approval flows as plugin functionality.

My practical read: if you need WordPress-side observability or connector approvals today, evaluate the AI plugin deliberately. Do not assume it is installed, enabled, stable enough for your risk profile or mandatory for every site. Experiments can be useful without being policy you can outsource.

A policy checklist before enabling connectors

Here is the minimum policy I would want before enabling a production connector on a client site.

Credential ownership. Decide who owns the provider account, who pays, who may create keys, who may rotate them and who can inspect provider-side usage logs. Avoid one agency-wide key across unrelated clients unless you have a strong accounting and incident-response reason.

Provider allowlist. Document approved providers and allowed capabilities. Text generation, image generation, web search, function calling and speech generation are not the same risk category. A plugin that can trigger web search or function calling deserves a stricter review than a manual alt-text helper.

Environment separation. Use separate keys or projects for local, staging and production. Production keys should not appear in staging after a database refresh. This is where a proper WordPress staging workflow stops being a convenience and starts being a control.

Key source standard. Prefer environment variables or PHP constants for production. Allow database-stored keys only for low-risk trials, local development or explicit client-controlled exceptions. Scrub connectors_*_api_key during database copies.

Plugin approval. Inventory plugins that call wp_ai_client_prompt, register connectors, expose prompt text through REST endpoints or enqueue the separate wp-ai-client JavaScript package. Require clear trigger points and role checks before approval.

Role and admin access. Treat manage_options as more sensitive once connector settings are live. Do not give Administrator access to editorial users just because it is easier than fixing roles properly.

Provider-side budget caps. Set hard caps, alerts and per-site or per-client projects in provider dashboards. WordPress 7.0 core is not your billing guardrail.

Logging and review. Review provider usage after enabling a connector, after installing a new AI-capable plugin, after adding an admin user and after major plugin updates. If you use the AI plugin's Request Logging experiment, treat it as extra visibility, not as the only source of truth.

Consent and privacy. Decide which data categories may be sent to providers: public posts, drafts, comments, form submissions, orders, customer notes, logs. For regulated sites, the default should be no personal, medical, financial or legal data in prompts unless explicitly approved.

Rotation and incident response. Write down the first hour of an incident: set WP_AI_SUPPORT=false if you need an immediate stop, revoke provider keys, remove database-stored connector keys, rotate env/constant keys, review provider usage, review recent plugin/admin changes and re-enable only after the policy gap is closed.

When I would leave AI disabled

For many business sites, the conservative default is simple: leave AI off until a real workflow needs it. A brochure site with no editorial team does not need a live OpenAI key in production because a future plugin might use it one day.

I would also leave it disabled for clients who cannot answer the ownership questions. If the client does not know who owns the provider account, who receives budget alerts or who can revoke the key on a Friday evening, the connector is not production-ready.

The same applies to sites with messy admin roles. If six people have Administrator access because nobody cleaned up permissions after a project handoff, fix that first. AI connector settings make broad admin access more consequential.

For agencies, the practical default is WP_AI_SUPPORT=false across unmanaged or policy-free sites, then opt in per site. That is not anti-AI. It is normal credential hygiene.

Key takeaways

  • WordPress 7.0 shipped AI infrastructure on May 20, 2026: a PHP AI Client and Settings > Connectors. Provider implementations for Anthropic, Google and OpenAI are separate plugins.
  • WordPress does not automatically send data to AI providers. Risk starts when a provider is configured and installed code calls the AI Client.
  • Database-stored connector keys are masked but not encrypted in 7.0. The options.php masking fix is useful, but it is not a secrets system.
  • Environment variables and PHP constants are better production defaults, but installed WordPress code can still use the configured AI path.
  • WP_AI_SUPPORT=false is the strongest global off switch; wp_ai_client_prevent_prompt is the practical hook for more granular prompt blocking.
  • Do not enable connectors until credential ownership, provider allowlists, environment separation, plugin approval, budgets, logging, privacy and rotation are written down.

Want fewer security surprises?

Staying safe is routine work: patching, monitoring, backups and defense-in-depth—done consistently.

Secure WordPress management

  1. Cloudflare just launched EmDash, and its plugin sandbox is the real story

    Cloudflare announced EmDash on April 1, 2026. It isn't a WordPress replacement yet, but the capability-based plugin sandbox is the most interesting rethink of plugin security I've seen in years.

    2027 words
  2. WordPress plugins are your biggest security risk: 331 vulnerabilities in one week

    In one week in March 2026, security researchers disclosed 331 new WordPress vulnerabilities, nearly all in plugins. This article breaks down the numbers, explains how plugin attacks actually work, and shows what you can do about it.

    1580 words
  3. What does it cost to outsource WordPress maintenance in 2026?

    Search for 'WordPress maintenance' and you'll find packages from €12 to over €200 per month. That's a huge gap for something everybody calls the same thing. This article explains where the difference actually comes from, and what you're paying for when you pay more.

    1803 words

Start typing to search, or browse the knowledge base and blog.