How to Rotate and Revoke AI API Credentials in WordPress Without Breaking Workflows

Rotating and revoking AI API credentials in WordPress are two different jobs. Rotation replaces a credential while keeping a workflow alive; revocation removes the authorization path so the workflow can no longer act. In WordPress, the credential is often an Application Password tied to a user account. AI integrations add more layers: a client configuration, an MCP server or connector, a secret store, the WordPress credential, and the WordPress user identity. Removing only one layer can leave access active, so the reliable method is to inventory every layer, update or remove each one, and then prove the result with a harmless authenticated request. The offboarding guide for AI access to WordPress makes this point directly: access is revoked only when the WordPress authorization path is disabled and a follow-up request proves it.

What counts as an AI API credential in WordPress?

There are at least two credential paths in a typical AI workflow, and they are easy to confuse.

Inbound access to WordPress. An AI assistant, script, or integration authenticates to WordPress as a user. The usual credential is an Application Password. WordPress introduced Application Passwords in WordPress 5.6 in December 2020. They are tied to a specific user account, intended for API authentication such as the WordPress REST API and, where enabled, XML-RPC. They are stored hashed in WordPress and shown only once at creation time. They are individually revocable, and they cannot be used to log into wp-admin via wp-login.php.

Outbound access to an AI provider. A WordPress plugin may store a provider API key so the site can call an external AI service. That key is not a WordPress Application Password. It is rotated in the provider dashboard and updated in the plugin settings. Revoking it does not revoke an AI tool’s access to WordPress, and revoking an Application Password does not invalidate the provider key. Treat the two paths separately.

Connector and MCP layers. AI tools often use a client configuration, an MCP server, or a connector secret in front of the WordPress credential. The offboarding guide describes the connection path as client configuration, MCP server or connector secret, WordPress credential, and WordPress identity. Removing a server from a client does not necessarily revoke the WordPress Application Password stored elsewhere.

Prerequisites and inventory before you rotate

Before changing anything, build a simple inventory. The goal is to know what will break if a credential disappears.

• List every integration that can act on WordPress: AI assistants, automation platforms, deployment scripts, plugins, and custom REST clients.
• For each one, record the client, MCP server or REST tool, secret store, WordPress credential, and WordPress user. This is the connection path the offboarding guide recommends mapping.
• Identify the owner, purpose, creation date if available, and the workflows that depend on it.
• Decide whether the integration should use a dedicated WordPress user. Because Application Passwords are tied to a user account, revoking that user or their credentials affects every application password for that user. A dedicated agent identity limits the blast radius.
• Confirm that Application Passwords are available on the site. Hosts, security plugins, or configuration choices can disable them; the Application Passwords documentation includes availability and disabling notes.
• Choose a low-traffic window or a staging environment for the first rotation if the workflow is business-critical.

How to rotate an Application Password without breaking workflows

Rotation should be an overlap operation, not a delete-and-recreate operation. Keep the old credential valid until the new one is proven in every consumer.

1. Create the replacement credential. In the WordPress user profile, create a new Application Password for the same user or for the dedicated agent user. Copy it immediately. WordPress stores it hashed and shows it only once at creation time. Give it a name that includes the integration and rotation date or purpose.
2. Update every consumer. Replace the old secret in the client configuration, MCP server environment, connector secret store, CI/CD variables, and any plugin or script settings. If multiple services share the credential, update them in a controlled order and restart or reload the services that cache configuration.
3. Verify the new credential with a harmless request. Use a read-only endpoint that requires authentication. The exact endpoint depends on your site and permissions. An illustrative example is:

curl -u "ai-agent:xxxx xxxx xxxx xxxx xxxx xxxx" https://example.com/wp-json/wp/v2/users/me

A successful response confirms that the username, Application Password, and Authorization header are working. A 401 response usually means the credential is wrong, the username does not match, the Authorization header is stripped, or Application Passwords are disabled. A 403 response usually means the request authenticated but the user lacks permission for that endpoint. The command is illustrative; adapt it to your site and mask secrets in logs.

4. Watch the real workflow. Trigger a representative action, check plugin or server logs, and confirm that scheduled jobs and queued tasks complete. Do not revoke the old credential until the new one has passed both the harmless request and the real workflow check.
5. Revoke the old credential. In the WordPress user profile, revoke the old Application Password. The Application Passwords documentation also covers managing credentials with WP-CLI, which can help when you need to list or delete credentials without opening each profile.
6. Verify the old credential fails. Repeat the harmless request with the old credential. It should now fail authentication. This is the evidence step that the offboarding guide recommends.
7. Record the change. Note the owner, time, reason, old credential name, new credential name, and verification result. The offboarding guide lists this record as part of a complete revocation or rotation run.

How to revoke AI access completely

Revocation is not the same as rotation. Rotation keeps access; revocation removes it. It also means more than closing a chat window or deactivating a plugin. The offboarding guide warns that a trial ending, a plugin being deactivated, or an assistant session closing does not necessarily revoke every credential.

1. Revoke the WordPress-side credential. Delete or revoke the Application Password or token that authorizes the integration. If the credential is a provider API key stored in a plugin, revoke it in the provider dashboard and remove it from the plugin settings.
2. Disable or delete the dedicated agent identity when appropriate. If the integration used a dedicated WordPress user, disabling or deleting that user removes the identity behind the credential. Do this only after confirming that no other workflow depends on that user.
3. Remove the connector and client configuration. Delete the MCP server entry, connector secret, client configuration, and any secret stored in a CI/CD system. The offboarding guide notes that deleting a server from a client does not necessarily revoke the WordPress Application Password stored elsewhere, so check both sides.
4. Repeat a harmless request to confirm failure. Use the same read-only request with the revoked credential. Access should fail. If it still succeeds, another layer is still active.
5. Record the offboarding. The expected output from a complete run includes a list of every credential and configuration in the path, the WordPress-side revocation action, client and server cleanup, a failed post-revocation test, and a record of owner, time, and reason.

Avoiding breakage: practical safeguards

• Use overlap rotation. Create the new credential, update consumers, verify, then revoke the old one. This avoids a hard cutover that breaks scheduled jobs.
• Use one credential per workflow. A shared credential makes revocation risky because you cannot tell which workflow depends on it. Separate credentials make it possible to revoke one integration without touching others.
• Prefer dedicated agent users. Application Passwords are tied to a user account. A dedicated user for an AI integration keeps its credentials separate from human administrators and limits the effect of disabling the identity.
• Name credentials for humans. Include the integration, owner, and purpose in the Application Password name so a future administrator can identify it before revoking it.
• Check all layers. The connection path can include a client, an MCP server, a connector secret, a WordPress credential, and a WordPress user. Removing only one layer may leave access active.
• Expect caching and queued work. Some clients cache tokens, and some jobs may already be queued. After rotation or revocation, monitor logs and run a representative workflow to catch stale credentials.

Troubleshooting common rotation and revocation failures

The workflow still works after revocation

This usually means another layer is still authorized. Check the client configuration, MCP server or connector secret, secret store, plugin-specific provider key, and any other WordPress user identity. The offboarding guide’s layered model is useful here: removing a server from a client does not necessarily remove the WordPress credential stored elsewhere.

The new Application Password is rejected

Check the username and credential first. Application Passwords are tied to a specific user account, and the username must match. Confirm that Application Passwords are not disabled by a host or plugin. Check whether the Authorization header reaches WordPress; some server or security configurations strip it. A 401 points to authentication, while a 403 points to permissions or capabilities.

An administrator cannot log into wp-admin with the Application Password

This is expected. Application Passwords cannot be used to log into wp-admin via wp-login.php. They are intended for API authentication, not interactive browser logins.

An MCP tool still acts after the WordPress credential is revoked

Look at the connector or MCP server configuration. The tool may be using a cached token, a different WordPress user, or a secret stored outside the client you already cleaned up. Remove the connector configuration and repeat the harmless request until it fails.

Limitations and tradeoffs

• Application Passwords are per-user credentials, not fine-grained per-endpoint tokens. Their effective permissions follow the WordPress user’s role and capabilities.
• Revoking a user or all credentials for a user affects every application password tied to that account. Dedicated agent users reduce this risk but add user-management overhead.
• Application Passwords are for API authentication. They are not a replacement for interactive login security, and they cannot be used with wp-login.php.
• XML-RPC authentication with Application Passwords applies only where XML-RPC is enabled.
• Revocation may not be instantaneous if a client caches credentials or a queued job has not yet run. Verification with a fresh request is the only reliable confirmation.
• Some hosts or plugins disable Application Passwords. Check availability before building a rotation plan around them.

Next action

Start with an inventory, not a deletion. Map each AI workflow to its client, MCP server or connector, secret store, WordPress credential, and WordPress user. Then rotate in overlap: create the replacement, update every consumer, verify with a harmless request and a real workflow, revoke the old credential, and confirm failure. If you are revoking access entirely, remove the WordPress credential, the agent identity when appropriate, and the connector or client configuration, then prove that the old credential no longer works. If your environment has an unusual host restriction, security plugin, or MCP setup, share the goal, environment, result, or error in the community so others can compare notes.