How to Revoke an AI Agent’s Access to WordPress
Revoke an AI client's credential at the issuing server and verify denial, then remove saved configuration without confusing it with model sign-in.
Revoke the credential at the service that issued it, then verify that the client can no longer make a protected request. Afterward, remove the saved connection from the client. Disconnecting an application’s interface alone is not reliable evidence that its server-side access has ended.
For Niwa MCP, open Niwa AI → Niwa MCP in WordPress, find the relevant credential under Active Tokens and use Revoke. If several applications share that token, withdrawing it affects all copies. Other active tokens must be reviewed separately.
Identify the credential before removing it
Record which client is connected, the intended WordPress site and how the connection was authorized. A Niwa Bearer token, a WordPress.com OAuth authorization and a core WordPress application password are different credentials issued in different places.
Look for duplicate entries and alternative connections. An assistant may have an MCP configuration as well as a separate application password or hosting credential. Withdrawing one route does not establish that every route has ended.
Keep the record descriptive: client name, token label or identifier, creation date and purpose. Do not paste the full secret into a shared checklist or support request. If the credential was exposed, withdraw that value before configuring a replacement.
Revoke a Niwa external MCP token
Use an authorized WordPress owner account to open Niwa AI → Niwa MCP. In Active Tokens, identify the token used by the client and select Revoke. The Niwa setup guide documents that action and the available token lifetimes.
For a temporary task, expiry can end the credential’s lifetime, but immediate removal is clearer when work has finished or the secret may have been exposed. Do not create a replacement token unless the application still has an approved task.
Niwa’s documented tokens grant administrator access. Retiring one is therefore more than tidying an application’s settings. If you reused it in another client, replace that shared arrangement with separately managed credentials before continuing work that still needs authorization.
Remove a WordPress.com authorization at the account
WordPress.com’s MCP developer guide directs owners to manage connected applications in their account. It specifically notes that disconnecting inside the AI client does not remove its entry there. A client can appear more than once, so review and disconnect each relevant entry.
The account’s MCP tool controls have a different scope from one application’s authorization. Turning off Write tools changes the allowed operations; it does not necessarily withdraw the client’s reading connection. Disabling MCP for a site or changing account-wide controls can affect other clients too.
Use the WordPress.com access guide to decide whether you are retiring one application, excluding one site or changing all clients’ effective tools. Choose the narrow action that matches your intended withdrawal.
Revoke a core WordPress application password
For a self-hosted integration using an application password, open the relevant user’s WordPress profile and its Application Passwords section. Revoke the specific named credential used for that integration. Review other entries rather than removing unrelated applications indiscriminately.
WordPress documents application passwords in its REST authentication handbook and provides a separate application-password reference. Identify the correct user’s record; an application password belonging to another user will not disappear because you edited your own profile.
Application-password removal and a WordPress user’s capabilities are separate controls. You do not normally need to change the account’s role or delete the user merely to retire one application credential. If the client used a different authentication plugin, use that issuer’s documented withdrawal process instead.
Confirm withdrawal with a protected request
Before revoking a test credential, identify a non-sensitive operation that requires it, such as retrieving an authorized test draft. After withdrawal, start a fresh request using the old connection and look for an authentication or permission rejection. Check the result rather than treating a network timeout as proof.
Reading a public page can still work without authentication. That is not evidence that the agent retained private access. Choose an operation whose prior success depended on the credential you removed.
If the protected request still succeeds, check whether the client is using another credential or automatically reconnecting through another authorization. Inspect the issuer’s active entries and the client’s configuration before declaring access ended. Do not test withdrawal by asking for a destructive operation on production.
Remove local copies and review what already happened
Once the server rejects the old credential, remove its saved configuration from the client and any private automation that used it. Review local configuration files, environment settings or the application’s connector entry as appropriate to that client. Do not distribute the retired secret as part of the report.
Revocation does not undo completed site changes or delete information already retrieved into a conversation. Review consequential work separately and use the appropriate content or backup recovery process where necessary. Provider-side conversation retention is also a separate account decision.
Disconnecting Niwa’s own model account is different from retiring an external MCP token. Existing WordPress owners can use the standalone plugin while withdrawing an external client they no longer need. Ask Niwa about the specific connection if you cannot identify its issuer; share the client, site and redacted configuration, without sending the real credential.
