Should You Give a Plugin Your OpenAI or Anthropic API Key?

Why plugins are asking for this at all

Running your own AI provider key instead of the plugin vendor reselling AI access has a real, practical upside: you pay the AI provider's own per-request rate directly, with no markup, and you can see exactly what you're spending in your own OpenAI or Anthropic dashboard. That's a legitimate reason for the pattern to exist. It also means the decision to connect a key is now a real security question, not a formality — the key is a credential, and credentials deserve the same scrutiny you'd give any other one you're about to hand to a piece of third-party code running on your site.

The question that actually matters: where does the request go?

There are two fundamentally different architectures hiding behind an identical-looking "paste your API key here" field, and the difference matters enormously for who can see your data and your key:

• Direct: your WordPress server calls OpenAI's or Anthropic's API directly, using your key. The plugin vendor's own servers never see the request, the response, or your key in transit.
• Proxied: your request goes to the plugin vendor's own server first, which then calls the AI provider on your behalf. Your key and your data now pass through a third party's infrastructure, even if the vendor says they don't log it.

Neither pattern is automatically disqualifying — a proxy can be built responsibly, and a "direct" claim can still be untrue if you don't verify it. But you should be able to get a straight answer to "does my key or my request data ever touch your servers, or does my site talk to OpenAI/Anthropic directly?" A vendor that can't or won't answer that plainly is telling you something.

How the key is stored matters as much as where it's sent

This isn't a hypothetical concern. WordPress core itself added a built-in AI connector setting in version 7.1, and it stores the provider API key as an ordinary option in the wp_options table — in plaintext. An independent audit of live sites found dozens of API keys sitting in plaintext in exactly this way, and WordPress core's own Trac tracker has an open ticket specifically about auditing that storage approach. The takeaway isn't that WordPress core did something uniquely wrong — it's that plaintext storage in wp_options is the default outcome unless a plugin deliberately does something better, and plenty of plugins don't.

A plaintext key in the database means anyone with read access to a database export, a staging-site copy, a backup file, or a compromised admin account can read your key directly, no decryption required. Before connecting a key, it's worth asking (or checking the plugin's source, if it's open source) whether the key is stored as plain text, or whether it's encrypted at rest, kept out of the database entirely (an environment variable or a wp-config.php constant, which WordPress's own connector setting checks first, before falling back to the database), or handled through whatever secrets-management approach the plugin actually documents.

Set a spending limit at the source — this part is genuinely in your control

Regardless of how much you trust a given plugin, both major providers let you cap what a leaked or misused key can actually cost you, and this is worth doing the same day you generate the key, not after something goes wrong:

• OpenAI: you can set a monthly budget on a project or organization in your platform.openai.com settings. Note that OpenAI's monthly threshold historically just triggered an email and dashboard alert while billing continued — but as of mid-2026, a genuine hard spend cap is available at the organization or project level, so make sure you've selected the hard-cutoff option specifically, not just the alert.
• Anthropic: the Console (Settings → Plans & Billing → Spending Limits) supports a workspace-level monthly spend limit that's a true hard cap — once hit, further requests return an error rather than continuing to bill. You can also set alert thresholds (a common approach is 50%, 75%, and 90% of the limit) so you find out well before the ceiling.

A leaked key that's capped at, say, $20/month is an annoyance. An uncapped key on a compromised site can run up a bill with no ceiling at all before you notice.

What data actually leaves your site in each request

A well-scoped AI feature sends the AI provider only what it needs for that specific request — a single finding, a single log line, a specific question — not your whole site, database, or visitor data. This is worth confirming directly rather than assuming: ask what fields are included in a typical request payload, and whether that scope changes for different features in the same plugin. If a "explain this one alert" feature and a completely unrelated feature both send your entire post content or user table along with the request, that's broader than the stated purpose requires, and worth pushing back on.

If the site is ever compromised, the key is a separate problem

An exposed AI API key from a hacked WordPress site is a distinct risk from the WordPress compromise itself, and it's easy to forget in the middle of a cleanup. If you're going through a malware removal process or otherwise know a site's database or files were accessed by someone who shouldn't have had access, rotate any connected AI provider key as part of that cleanup — the same way you'd rotate database credentials or admin passwords. Both OpenAI and Anthropic let you revoke a specific key instantly from their dashboards and issue a new one; there's no reason to leave an old one live once you have any reason to suspect it was exposed.

A short checklist before you connect a key

• Confirmed whether requests go directly to the AI provider or through the plugin vendor's own servers first
• Checked how the key is stored — plaintext in the database, or something better
• Set a hard monthly spend limit at the provider level, not just an alert
• Confirmed what data is actually included in a typical request payload
• Know how to revoke and rotate the key if the site is ever compromised