Every access-control decision this course has covered eventually needs an undo. An integration gets retired, a vendor relationship ends, a credential leaks, or you’re simply doing a routine review. This lesson covers the real, current mechanics of revoking Application Password access, what actually happens to an agent mid-session when you do, and how to manage this at the scale of several agent connections rather than just one.
Lesson 2 (generating Application Passwords) and at least one agent account already provisioned per Lesson 4.
Step 1: Revoke a single Application Password
The same list shows a last used date per password, a genuinely useful signal for deciding what’s actually still active versus what’s been provisioned and forgotten.
Step 2: Revoke from WP-CLI, individually or all at once
# Revoke one specific password by its UUID
wp user application-password delete ai-content-agent 6633824d-c1d7-4f79-9dd5-4586f734d69e
# List every password for a user first, to find the right UUID
wp user application-password list ai-content-agent --fields=uuid,name,last_used
# Revoke every application password for a user in one call, for full offboarding
wp user application-password delete ai-content-agent --allIf an agent account is being fully retired, deleting the WordPress user itself (or demoting it and clearing its roles) removes its ability to authenticate at all, not just its application passwords. For a genuine offboarding, prefer deleting or disabling the account outright, rather than only removing individual credentials from an account that otherwise remains active.
Step 3: What actually happens to an active connection
Application Password authentication is stateless Basic Auth, checked fresh on every single HTTP request. There is no session token, no cached credential on the server side that also needs separate invalidation. The practical result:
A common mistake during an incident response: someone resets the WordPress account’s main login password, assumes that’s sufficient, and moves on. It isn’t. Application Passwords are separate credentials with their own lifecycle. If you suspect a compromise, revoke the specific application passwords (or all of them) explicitly.
Step 4: Reviewing access at scale
Once you have more than one or two agent connections, a periodic review becomes necessary, not optional. Pull every application password across every user in one pass:
wp-env run cli wp eval '
$users = get_users( array( "role__in" => array( "ai_content_agent" ) ) );
foreach ( $users as $user ) {
$passwords = WP_Application_Passwords::get_user_application_passwords( $user->ID );
foreach ( $passwords as $p ) {
printf(
"%s | %s | last used: %s\n",
$user->user_login,
$p["name"],
$p["last_used"] ? date( "Y-m-d", $p["last_used"] ) : "never"
);
}
}
'Test it: confirm a revoked credential fails cleanly
curl -i -u "ai-content-agent:the-revoked-password" https://your-site.test/wp-json/Confirm you get 401 Unauthorized. Then check your connected AI client, its next
attempted call should surface an authentication failure, which is the expected, correct
behavior, not a bug to work around.
Recap
Revoking an Application Password is immediate and final, checked on the very next
request, with no lingering session or token to separately expire, a genuine simplicity
advantage over more stateful auth schemes. Revoke specific credentials via wp-admin or
wp user application-password delete, and for full offboarding, disable or delete the
underlying account rather than relying on removing credentials alone. Review usage
across all agent accounts periodically using each password’s last-used date, rather than
waiting for an incident to force the question.
Resources & further reading
- Application Passwords integration guide, make.wordpress.org
- wp user application-password, WP-CLI command reference, developer.wordpress.org
- WP_Application_Passwords class reference, developer.wordpress.org