Why we don’t hold your API keys (and why every other AI WordPress plugin should worry about that)

I want to write the post I wish someone had written for me when I started this. Three things in particular: the architecture matters more than I thought, the consequences keep widening once you see them, and a lot of WordPress AI plugins built in 2024-2025 are sitting on top of an architecture that’s about to look obviously wrong. Some of those plugins will be fine; their authors will adapt. Some of them won’t, and their customers won’t quite understand why their service got worse one month and gone the next.

Here’s the version of all this I have now.

The old shape

For most of 2024 and into 2025, the standard “AI plugin for WordPress” architecture went like this:

1. The plugin author sets up a service that holds an Anthropic / OpenAI / Google API key. The user installs the plugin and connects it to the author’s service.
2. (Or, in the BYOK variant: the user pastes their own key into a settings field, and the plugin stores it in the WP database. The plugin proxies the request through the author’s service, which sees the key on the way through.)
3. The plugin proxies user requests to the model provider, billing the user a subscription that wraps the inference cost plus margin.
4. The plugin’s “value” is the system prompts and UX wrapped around the model.

This worked, well enough that the category became a real one. Until WordPress 7.0.

What 7.0 changed

WordPress 7.0 (May 2026) shipped three Core APIs that, taken together, removed the architectural floor underneath that whole shape:

• Connectors API. Site admins configure their AI provider once at Settings → Connectors. Every plugin using WP AI Client inherits the configuration.
• WP AI Client. A provider-agnostic PHP API for calling the model. wp_ai_client_prompt() routes through the active Connector.
• Abilities API. A standardized way for plugins to register callable functions for the site’s AI agent.

The shorter version: WordPress now does the boring infrastructure work that AI plugins used to charge for. Configure once, use everywhere. This is the same pattern WordPress used for SMTP a decade ago: wp_mail() is the abstraction, the user picks an SMTP plugin once, every form plugin that calls wp_mail inherits it. Email plugins didn’t disappear; they just stopped having to be everyone’s mailer-of-record.

The two consequences

Consequence one: the plugin author no longer needs to hold keys.

DesignSetGo Apps doesn’t. Apps that need AI features call dsgo.ai.prompt(), which calls wp_ai_client_prompt() underneath, which routes through whatever Connector the site admin configured. We don’t see a key. We don’t store a key. We don’t proxy a request through any of our own infrastructure. The site admin pays the provider directly; we charge a subscription for orchestration (the harness: system prompts, tools, validators, registry).

This makes our margin structurally cleaner: roughly 98% of subscription revenue, because we never touch metered cost. That isn’t clever pricing on our part. It’s what falls out of building on top of WP 7.0 instead of around it. We didn’t have to be smart; we had to read the dev notes and align ourselves with the platform.

Consequence two: the proxy architecture is now legally exposed.

The original shape (“plugin author proxies user requests through their own service, charging a subscription markup”) has a problem most authors hand-waved past. Anthropic’s commercial terms of service explicitly prohibit reselling API access. OpenAI’s terms have similar language. Google’s are stricter than either. The plugin author who set up a proxy was running an architecture that:

• Looked, technically, a lot like reselling API access.
• Made the plugin author the merchant of record for inference, with whatever VAT/sales tax/payment-processor implications that brings.
• Required the plugin author to absorb the financial risk when a user’s bill spiked unexpectedly (a runaway prompt, a malicious crawler, a customer’s bot loop).
• Made the plugin author the support contact when the model returned bad output, even though the model wasn’t theirs.

Most plugin authors hand-waved this and hoped it never became a problem. Anthropic, OpenAI, and Google mostly didn’t enforce, because the plugin authors weren’t material to revenue. As long as the upstream providers were focused on capturing direct enterprise customers, a few WordPress plugins reselling API access were not worth a lawyer’s time.

After 7.0, the architectural justification for the proxy goes away. The user can run their own Connector. They don’t need a proxy. The plugin author’s only reason to keep the proxy is the subscription revenue it generates, which is now exposed as exactly what it always was: a commercial markup on resold API access. The legal exposure didn’t change; what changed is that the commercial necessity disappeared. Which makes enforcement, when it comes, harder to dispute. “We had to proxy because there was no alternative” was always thin; “we had to proxy because we wanted to charge a markup” is thinner.

I don’t know when, or whether, Anthropic or OpenAI will tighten enforcement on this. I do know that “the upstream provider could decide our entire revenue model violates their ToS” is a structurally bad place for a plugin author to be, and the architecture that puts you there got cheaper to avoid the day 7.0 shipped.

What we did instead

DSGo Apps is built on top of wp_ai_client_prompt(). Specifically:

• The bridge surfaces dsgo.ai.prompt() as a method any DSGo App can call.
• Behind the bridge, the plugin calls wp_ai_client_prompt() with the app’s prompt.
• WP AI Client routes the call through the site admin’s configured Connector.
• The response comes back to the bridge, which returns it to the app.

We don’t see the prompt. We don’t see the response. We don’t store either. (That last part is by design; we wanted to be able to truthfully say “we don’t have it” if anyone asks.)

What we charge for is the harness: the system prompts, the tools, the validator that catches bad model output, the autofix that retries with corrections, the critic that flags hallucinations, the registry of vetted tool definitions. None of that touches the API call itself. All of it is value layered over an inference call the user is already making.

The economics work because we’re not paying for inference. The user’s subscription is pure margin minus the operational cost of running a SaaS, which is small. Our customer-acquisition costs are real, our development costs are real, our support costs are real, but inference is not a line item, and that changes the math. Most of the AI-tooling industry is sustaining margin against rising inference costs; we don’t have that pressure.

What this means for plugin authors

If you build an AI WordPress plugin, here are the questions I’d ask yourself, in priority order:

1. Do you hold any user’s API key? If yes, plan to drop it. The Connectors API removes the user’s reason to give it to you, and storing a key is liability you don’t need. Even if you encrypt at rest, even if you scope it carefully, even if your security review is clean: the key being in your database means it’s a potential incident. Not having it is strictly better.

2. Do you proxy LLM calls through your own service? If yes, plan to drop the proxy. Switch to wp_ai_client_prompt(). Your only architectural reason to keep the proxy is “we want to charge a markup on inference,” and the upstream providers’ ToS makes that a structurally weak position.

3. Do you require a paid tier to access AI features? That’s fine, but the gating rationale shifts. Pre-7.0, you could honestly say “we charge for AI because inference costs money.” Post-7.0, the user is paying inference directly to their provider; your charge is for the orchestration layer (prompts, tools, UX). If your orchestration layer is thin, your subscription is exposed. The customer can self-evaluate “what is the plugin doing that I couldn’t do with a raw model call?” and the answer better be substantive.

4. Is your differentiation “we figured out how to call OpenAI for you?” That moat just evaporated. Find the next layer up: vertical-specific prompts, integrations with other plugins via the Abilities API, a UX nobody else has, anything that isn’t “we configured an SDK.” Vertical packs (a set of prompts and tools tuned for a specific industry) are probably the highest-leverage place to invest, because they don’t compete with WP Core; they sit on top of it.

What we’d change if we started over

Honest reflection. We made a few bets early that look good now but didn’t have to.

We chose iframe-first isolation. That meant our bridge surface had to be carefully designed from day one, because we couldn’t fall back to “the app has access to the WP runtime.” Painful at the time; it forced the permission model that’s now the most defensible part of the product.

We resisted holding API keys even before WP 7.0 was finalized. The whole BYOK-through-proxy architecture was tempting; it’s the obvious early-monetization path. We decided we didn’t want to be in the API-resale business and let the WP-Connectors path catch up to us. That path was the right one in the end.

We made the plugin free and built revenue around the harness layer. The plugin’s value compounds with every site it’s on, and the harness is what compounds with every subscription. Charging for both would have suppressed the install curve without meaningfully changing the revenue.

Where to go next

• The WP 7.0 changes post for the architectural primer.
• The pricing & business-model doc for the full pricing thinking.
• The defensibility-strategy doc for what we think the moat actually is.

The next post in this calendar covers DSGo vs headless WordPress, which is a different architectural conversation but ends up at a similar conclusion: the platform you’re trying to glue onto is the platform you should run inside.

Nealey