Why You Shouldn't Store LLM API keys in WordPress Database

WordPress 7.0 was released last week, featuring new LLM integration models that got our community talking. The AI Connectors framework adds a new settings page that lets you install and connect AI integrations to your site. The Abilities API at the backend makes AI interactions organic inside your WordPress site, with the benefit of producing content, generating images, and doing administrative tasks without an external connection or MCP.

However, not all is unicorns and rainbows with this new WordPress core integration. Oliver Sild, CEO and founder of Patchstack, pointed out on X that AI integrations into WordPress core, in conjunction with plugin vulnerabilities, could lead to a surge in attacks targeting those vulnerabilities. Why a surge? Because LLM API keys are a valuable commodity.

LLM API Keys Are “The New Gold”

In the Post Status community, Sild shared a link to a Reddit post about a small Japanese company facing possible bankruptcy after the unauthorized use of their Gemini API keys racked up a $128k bill. He also included a screenshot of Andrey Lukashenkov’s LinkedIn post declaring “AI tokens are the new gold.” Lukashenkov, Head of Revenue at Vulners, goes on to point out that “a single stolen Gemini API key is now worth more than a rack of compromised servers.” Anyone who has followed the rise of AI-assisted development and “vibe coding” will probably have heard the stories of huge AI bills from token usage. It’s trivially easy to do, especially with projects like OpenClaw. Sild said, “It doesn’t even matter how big the adoption of this will be on WordPress sites. Every site will be a target regardless, as you won’t know if it has a key until you exploit it.”

I agree, and it’s cause for concern. Much like the target audience of phishing texts and emails is not the majority of users who ignore and delete them, but a sliver of recipients that actually click the link, the target of widespread attacks won’t be the WordPress sites that have implemented the AI Connectors feature or generally practice good security policies.

Companies that don’t know or understand the risks will be the primary prey. It costs virtually nothing to deploy an army of robots that try to exploit known vulnerabilities to exfiltrate secure information. In the past, secure information on a WordPress site might have included some PII (personally identifiable information), sales data for a WooCommerce site, or API keys for premium plugins. Personal information might be valuable for identity theft, but never in the 20+ year history of WordPress has there been a treasure trove of secure data built into WordPress core.

A Pro Tip: Don’t Store Your API Keys in the WordPress Database

If you’re not planning on using the AI Connectors at all, you can easily disable that functionality from your wp-config.php by simply setting define( 'WP_AI_SUPPORT', false ). It’s a little bit more work to remove all functionality or the Connectors menu item, but there are already plugins available to do that for you.

But what should you do if you do want to use AI on your WordPress site?

Given that a security vulnerability that exposes the WordPress admin and runtime to an attacker who can execute arbitrary code could also expose the values of constants or environment variables exposed by WordPress itself, there is a quick way to securely store your API keys (for LLMs or otherwise) using Pantheon Secrets.

Pantheon Secrets are securely stored in a cryptographically secure vault. They can be saved as environment variables or fetched in the PHP runtime on Pantheon sites using the pantheon_get_secret() function. You can set secrets via Terminus or in the Pantheon admin dashboard. Most attacks are likely to target the WordPress database or filesystem for data exfiltration because those are the most common places where valuable data is stored.

AI Connector API keys can be stored in PHP constants with the {PROVIDER_ID}_API_KEY pattern, e.g. ANTHROPIC_API_KEY. Using Pantheon Secrets, you’d define that like this:

define( 'ANTHROPIC_API_KEY', pantheon_get_secret( 'my_anthropic_api_key' ) );

Other providers, like AWS, GCP, Azure and HashiCorp, have their own SDKs for pulling secrets securely from their platforms and could be used in a similar way. Using one of these options would require replicating a lot of the work that we put into the Pantheon Secrets SDK for those providers, but it is possible if you’re working on a site that’s not hosted on Pantheon’s infrastructure.

As I noted before, this still introduces some risk, and even turning off AI functionality entirely is not going to prevent optimistic attackers from trying to exploit security vulnerabilities in your plugins. It’s even more important to stay vigilant about security updates and vulnerabilities in the code that you run on your site. Pantheon’s read-only filesystem will prevent a lot of attacks that are based on the ability to write code to the filesystem and execute that. If you want to experiment with the new AI Connectors feature, not keeping those keys in the WordPress database seems like an achievable low bar.

If you want to try something experimental, I built out a plugin that uses a “lazy authentication handler.” Rather than storing an API key in an environment variable, a PHP constant, or the database, you just store it in Pantheon Secrets. WordPress’s AI Connectors will normally pass your API keys into the AI client at runtime and will then be available in PHP memory. The lazy handler in my plugin replaces that stored key with an object that doesn’t actually fetch the key itself until it’s invoked and then immediately forgets it. If someone can execute code on your site, they’d theoretically still be able to run pantheon_get_secret (assuming they know that function exists and what secret to get). Otherwise an attacker would need to actually time their code to interrupt an LLM request as it happens, since the key isn’t actually stored anywhere retrievable.  

If you want to check it out, the code is up on GitHub: jazzsequence/ai-connector-secure-layer. I’m hopeful that some more robust solutions for this problem will be coming in future WordPress releases.