WordPress 7.0 introduced a central place to configure AI providers such as Anthropic, Google, and OpenAI. Plugins can then use WordPress’s built-in AI Client instead of asking users to configure the same provider separately. It is a cleaner setup, but it also creates a shared security boundary. API keys saved through Settings > Connectors are stored unencrypted in the WordPress database by default. Encryption would improve that, but it would not protect the credential from malicious PHP code already running inside the site.

Quick answer: WordPress 7.0 does not encrypt database-stored AI Connector API keys by default. Encryption can protect a key if someone obtains a database dump or backup. It does not stop a compromised plugin from making requests through a connector that WordPress itself is configured to use.

What WordPress 7.0 AI Connectors actually do

WordPress 7.0 added two related pieces of infrastructure: the Connectors API for configuring external services and the AI Client for making AI requests through a consistent WordPress API.

Before this, an AI-powered SEO plugin, chatbot, and image tool might each ask for an API key and store it independently. WordPress can now hold the provider configuration centrally under Settings > Connectors. A compatible plugin can make a request through wp_ai_client_prompt(), and WordPress routes that request through a provider configured for the site.

The AI Client itself is provider-agnostic. WordPress core provides the connector infrastructure and request-routing API, while provider implementations for services such as Anthropic, Google, and OpenAI are installed as separate connector plugins.

That removes a lot of duplicated setup. It also means the credential is part of the site’s shared WordPress environment rather than something isolated inside one plugin.

Are WordPress AI API keys encrypted?

Not when they are stored in the WordPress database by default.

WordPress’s Connectors API developer documentation states that database-backed API keys are stored unencrypted and masked in the user interface.

For an API-key connector, WordPress checks for the credential in this order:

  1. Environment variable, such as OPENAI_API_KEY
  2. PHP constant
  3. WordPress database setting

For AI providers, a database-backed key uses a setting name such as connectors_ai_openai_api_key or connectors_ai_anthropic_api_key.

Core ticket #64789 tracks the wider security discussion around connector credentials. It is currently assigned to the Future Release milestone, with no WordPress version committed for core encryption.

There is a good reason to care about this beyond the usual concern about exposed passwords. An AI API key can carry immediate usage and billing value. In March 2026, The Register reported that a stolen Gemini API key generated more than $82,000 in unauthorized charges in 48 hours. That incident was unrelated to WordPress, but it shows what a leaked AI credential can be worth.

What API key encryption protects, and what it does not

Encrypting the database value would be useful. It protects against a different class of problem than a compromised WordPress plugin.

Where the key is storedProtected from a database-only leak?Stops malicious PHP from using the configured connector?
WordPress database, plaintextNoNo
WordPress database, encryptedYesNo
wp-config.php / PHP constantYesNo
Environment variableYesNo

The distinction is important. Moving a secret out of the database can protect it from leaked SQL dumps, copied staging databases, exposed backups, or read-only database access. Encrypting the database value provides similar protection at rest.

Neither creates a security boundary between WordPress and PHP code that is already executing inside WordPress.

Example: suppose a vulnerable plugin allows an attacker to execute PHP on the site. Encrypting the connector key means the attacker cannot simply read its plaintext value from the options table. But WordPress still has to be able to use that credential when a legitimate plugin sends an AI request. Malicious code running inside the same application can operate inside that same trust boundary.

This is why moving a key to wp-config.php is better described as protection from database exposure, not protection from a full WordPress compromise.

The separate WordPress AI plugin now includes an opt-in Key Encryption experiment. It uses bundled libsodium encryption to encrypt AI provider keys at rest and decrypts them transparently when WordPress reads them.

That is a useful improvement. It protects the stored value without claiming to solve the separate problem of malicious code already running on the site.

Who can change a WordPress AI Connector key?

There is another security question that is easy to miss if the discussion stops at encryption: who is allowed to replace the credential?

Database-backed connector credentials use WordPress’s settings infrastructure. A security review submitted to the #64789 discussion found that the settings could be changed through the REST settings endpoint by an account with the manage_options capability.

On a standard WordPress installation, manage_options is normally associated with administrators. But plugins, custom roles, automation tools, and integrations can change how capabilities are assigned, so it is worth checking rather than assuming.

WordPress core does not currently have a narrower manage_connectors capability specifically for these credentials. There is also no connector-specific audit event or built-in administrator notification when a database-backed key is replaced.

That creates a different type of risk from simply stealing the key.

Example: someone with sufficient access replaces the site’s OpenAI key with another valid OpenAI key. The site’s AI functionality may continue working normally because the provider has not changed. What changed is the account behind the credential, including where usage is billed and, depending on the provider and its logging configuration, where request activity may be visible.

This is why connector-key changes are worth treating as credential changes, not ordinary settings edits.

Can you limit which plugins use an AI Connector?

Not through WordPress core on a per-plugin basis today.

The core connector is a site-level configuration. A plugin built to use the WordPress AI Client can send requests through a compatible provider configured for that site.

The separate WordPress AI plugin adds an experimental control called Connector Approvals. When enabled, it identifies the plugin or theme making a request and blocks the request until an administrator approves that caller for the connector.

That gives site owners useful control over which installed components are allowed to use AI services. It does not replace key encryption, and it does not create a separate core capability for changing the connector credential itself.

What WordPress core has already fixed

One early credential-exposure issue was fixed before the final WordPress 7.0 release.

During development, connector API keys could appear in plaintext on the lesser-used wp-admin/options.php screen. That page read the database directly and bypassed the masking normally applied when WordPress retrieved a connector key.

WordPress fixed this under ticket #64793. Values matching the connector API-key setting pattern are now masked on that screen, and editing them there is disabled.

That fix prevents an administrator from seeing the raw credential through that particular screen. It does not encrypt the value stored in the database.

The broader work around credential storage and connector security remains tracked separately under #64789.

How to secure WordPress AI Connector API keys

You do not need to wait for a future WordPress release to reduce the risk. Start with the controls that have the biggest practical effect.

Do these first

  • Remove connector keys you are not using. Check Settings > Connectors on every site you manage. A test credential left behind after setup is still a live credential.
  • Keep WordPress, plugins, and themes patched. The storage discussion matters much less once an attacker can execute PHP inside the application. Remove abandoned plugins and themes and address known vulnerabilities quickly.
  • Review who has manage_options. Check administrator accounts, custom roles, automation tools, and integrations. This capability should not be handed out as a general-purpose permission.
  • Use provider-side usage controls. Configure the strongest billing alerts, budgets, limits, rate controls, or project restrictions your AI provider offers. A WordPress security control should not be the only thing standing between a leaked credential and unexpected API usage.

For sites that need stronger controls

  • Keep credentials outside the WordPress database. Environment variables or PHP constants prevent the key from being included in a normal database export. This is useful protection against database-only exposure, even though it does not stop malicious PHP already running on the site.
  • Consider the Key Encryption experiment. If you use the WordPress AI plugin, its experimental encryption feature protects database-backed AI credentials at rest.
  • Use Connector Approvals. The WordPress AI plugin can require explicit administrator approval before a plugin or theme is allowed to make requests through a configured connector.
  • Monitor connector setting changes. If these credentials matter to your business, monitor changes to relevant connectors_ai_*_api_key settings using WordPress option hooks or your existing security logging system. Record the actor and time, but never write the complete API key into an audit log.
  • Restrict AI prompt execution where needed. WordPress provides the wp_ai_client_prevent_prompt filter, which developers can use to prevent AI requests based on their own permission or application rules.

If you do not use WordPress AI features

You can disable AI support completely:

define( 'WP_AI_SUPPORT', false );

When this constant is set to false, wp_supports_ai() reports AI support as disabled. WordPress also provides the wp_supports_ai filter for cases where developers need request-specific control.

Where Securewp fits

SiteFort does not change how WordPress stores or authorizes AI Connector credentials. Provider-side controls, connector permissions, and careful credential handling still matter.

What SiteFort addresses is the WordPress security layer underneath that problem: reducing exposure to vulnerable and malicious code through hardening, firewall protection, vulnerability monitoring, malware scanning, login security, and activity logging. If an attacker cannot gain the WordPress access needed to execute malicious code in the first place, the credential-storage question becomes much less dangerous.

For agencies and teams managing multiple WordPress sites, Securewp Console provides a central place to monitor and manage SiteFort security across those installations.

Frequently asked questions

Are WordPress 7.0 AI API keys encrypted?

Not by default when the API key is saved in the WordPress database. WordPress masks the key in its normal administration interface, but the database-backed value itself is stored unencrypted. Core ticket #64789 tracks further work in this area.

Would encrypting WordPress AI API keys make them secure?

It would protect them from some important threats, including database dumps, copied backups, and other database-only exposure. It would not stop malicious PHP code already executing inside WordPress from using a connector that the application itself is allowed to use.

Is storing an AI API key in wp-config.php safer?

It is safer against database exposure because the credential is no longer stored in the WordPress options table or included in a normal database backup. It does not create a security boundary against malicious PHP code running inside WordPress.

Can any WordPress plugin use a configured AI Connector?

WordPress core treats connectors as site-level configuration rather than assigning the credential to one specific plugin. Compatible plugins can make requests through the AI Client using a configured provider. The separate WordPress AI plugin offers an experimental Connector Approvals feature for restricting connector use by plugin or theme.

Who can change a WordPress AI Connector API key?

Database-backed connector settings use WordPress’s settings permission model and are protected by the manage_options capability. WordPress core does not currently provide a separate connector-management capability or a connector-specific notification when a key is changed.

Does WordPress have encrypted AI Connector storage available now?

Not in WordPress core. The separate WordPress AI plugin includes an opt-in Key Encryption experiment that encrypts AI provider keys at rest using libsodium and decrypts them when WordPress needs to read them.

How do I disable AI support in WordPress 7.0?

Add define( 'WP_AI_SUPPORT', false ); to wp-config.php. Developers can also use the wp_supports_ai filter for more granular control.

Primary sources