What WordPress 7.0’s AI API Key Access Means for Agency Security Policy

WordPress 7.0 ships a native AI layer that places API key configuration directly inside the WordPress admin, giving site administrators the ability to connect third-party AI services without touching a theme or installing a separate plugin. The Automattic AI integration, built into WordPress core, centralizes AI feature configuration under a single settings screen. Site admins can enter keys for services used by core AI features and any compatible WordPress AI plugin that opts into the API standard.

This is a meaningful shift from how agencies have historically managed AI capabilities on client sites. Before this model, AI functionality lived in discrete plugins, each with its own settings, its own key storage, and often its own billing relationship. The WordPress AI plugin update model now standardizes where those credentials live. That standardization is good for end users. For agencies operating a fleet of client sites, it concentrates risk in a single, predictable location that every site administrator can now reach.

The key operational detail: the AI settings screen in WordPress 7.0 is accessible to anyone holding the Administrator role on a given site. That is a large population across a typical agency fleet. It includes the agency’s own accounts, client contacts granted admin access during onboarding, and in some cases developers or contractors who received temporary credentials and never had them revoked. The feature is live. The access question is now yours to answer.

When a credential lives in a predictable, accessible location across every site in your fleet, it becomes a governance surface, not just a configuration setting. Consider what happens across thirty client sites: some clients have full administrator access, some have had credentials pre-configured by your agency, and some may have already entered their own keys because the UI invited them to. Without a defined policy, all three states exist simultaneously and you have no reliable way to know which applies to which site.

The fleet governance problem is not that WordPress 7.0 created a security hole. It is that a capability that previously required technical intervention is now self-service. The blast radius of a misconfigured or exposed API key scales directly with the size of your fleet. A client who rotates their own key without telling your agency breaks AI features site-wide. A client who pastes a shared agency key into their personal admin account creates a credential that is, effectively, uncontrolled.

Agencies that discover this problem after an incident face two costs: the direct cost of the exposed credential (revocation, re-provisioning, potential billing liability) and the operational cost of auditing an entire fleet in reactive mode. The agencies that handle it well define the policy before either cost arrives.

The first policy decision every agency must make is whether the API key relationship belongs to the agency or to the client. Both models are defensible, but they carry different obligations. If the agency holds the keys, the agency is responsible for provisioning, rotation, and cost monitoring. If the client holds their own keys, the client carries the billing risk but the agency loses visibility into what is configured on sites it operates.

For most agencies running client sites at scale, a hybrid model is the most practical approach. The agency provisions and manages keys for AI features that are part of the managed service contract. Clients who want to self-serve beyond that scope receive a separate set of credentials tied to their own billing account. This separation means that a client’s experimentation does not touch the agency’s master credentials, and costs remain attributable by site.

The hybrid model also clarifies liability. If a client enters their own key and generates unexpected costs, that is a client billing relationship. If the agency provisioned the key and it was misconfigured, that is an agency operations failure. Clear ownership at setup prevents that ambiguity from surfacing during a dispute.

A written access policy for AI API keys should specify three things: which WordPress user roles can view or edit the AI settings screen, which AI services are approved for use on client sites, and what the process is when a client wants to add a service not on the approved list. Without these three answers documented and applied consistently, your fleet is operating on individual judgment calls made at the moment of setup, not on repeatable policy.

Role-based enforcement is the most important lever available. WordPress user roles determine what the admin panel exposes. If your standard client onboarding assigns the client contact an Editor role rather than Administrator, they cannot reach the AI key configuration screen at all. For clients who do require Administrator access, a documented change-management process converts a trust assumption into an auditable step: a ticket, a review, and a confirmation that the agency-provisioned key will not be modified without coordination.

The approved-services list matters more than it initially appears. Without one, a client or contractor can connect any AI service that has a compatible WordPress AI plugin available, including services that store data outside your clients’ required jurisdictions or that carry compliance implications your agency is not equipped to evaluate. The list does not need to be exhaustive. It needs to exist, and it needs to be the default answer when someone asks whether a new service is permitted.

Credential hygiene at fleet scale means treating AI API keys with the same discipline you apply to database credentials or hosting passwords: unique per site where possible, rotated on a defined schedule, and never stored in a place that survives a site export. A common failure mode is using a single master API key across many client sites because it is faster to set up. That key becomes a single point of failure. One site compromise, one client who copies the key out of the settings screen, and the credential is effectively public across your entire fleet.

The practical standard is one key per billing relationship. If an agency bundles AI features into its managed service, maintain one key per client account with that AI service provider, not one key shared across the fleet. This is a small operational cost that eliminates a category of risk entirely.

Rotation triggers should be explicit and documented:

• When a client engagement ends, revoke the key provisioned for that site.
• When a client’s administrator account changes hands, treat the key as potentially compromised and issue a new one.
• On a calendar schedule of no more than twelve months, regardless of other triggers.
• Immediately, upon any suspected credential exposure, whether or not abuse has been confirmed.

Document which key is deployed to which site in a system that is not the site itself. A spreadsheet, a secrets manager, or a field in your client records: any of these works. What does not work is relying on the WordPress admin to be the authoritative record of what credential is active on a given site.

Unmanaged AI API key access across a client fleet creates an invisible billing problem: usage accumulates against whichever key is active, and without per-site tracking, the agency cannot tell which clients are driving which costs. This is not hypothetical. AI features tied to key-based billing can generate significant usage from a single high-traffic site, and if that usage is buried in a shared key, the cost is invisible until a monthly bill arrives that is difficult to explain or allocate.

The agencies that handle this well treat cost attribution as a client deliverable, not an internal accounting task. They configure one API key per client, map usage reports to client accounts, and include AI consumption in monthly reporting alongside hosting and performance metrics. A client who can see their own AI usage understands the value being delivered. A client who cannot see it questions the line item when it appears on an invoice.

Agencies that operate at scale find that the governance framework for AI keys can become a differentiated service offering. Clients with AI features on their sites want to know what those features cost, whether usage is growing, and whether the cost is justified by the outcomes. An agency that can answer those questions from a centralized operating layer is providing something most agencies cannot.

Auditing your current fleet for AI key configuration is the right first operational move. For each site you operate, establish: whether an AI key is configured, who configured it, which role can edit it, and whether it is a shared or site-specific credential. That audit establishes your baseline. Without it, any policy you write applies only to new sites, and your existing fleet remains in an unknown state.

For agencies that operate many sites, this kind of fleet-level audit belongs in an operating layer sitting above individual site admin panels. Rather than logging into each site one at a time, the more scalable approach is to read and verify configuration state from a Command Center that covers your full fleet. The broader implications of WordPress 7.0 for agencies operating client fleets cover how this shift changes the operating model beyond just AI keys.

Once you have your baseline, the remediation steps are direct:

1. Apply your access policy to every site. Downgrade client users who do not need Administrator access to a role that cannot reach the AI settings screen.
2. Replace shared credentials with site-specific keys. Set up one key per client account with the relevant AI provider.
3. Document key assignments in a system outside the sites themselves.
4. Establish a rotation calendar and assign clear ownership for each site’s credential.
5. Run a change-management review for any site where a client has already configured their own key. Decide whether to unify under the agency model or formalize the client-owned key as the documented arrangement for that site.

The sites that already have credentials configured by clients require a direct conversation: explain the governance model, issue new credentials under the agreed ownership structure, and revoke the ad-hoc keys. Treat it as onboarding, not as a correction. Most clients accept a clear policy explanation more readily than they accept an unexplained credential change.