PAGUP Agent ControlWordPress access for AI assistants
Start free trial

How to Find WAP Application Passwords in WordPress

WordPress Application Passwords are normally listed on the profile of the WordPress user that owns them. The plain secret is shown only when it is created; the profile later shows metadata such as the name, creation date and last-use information, not the original password value.

Match the credential label, owning user, creation time, last use and integrating plugin. A label that contains “WAP” is evidence about naming, not proof of the complete data flow or permission set.

Likely causes

  • The expected Application Password was never created, was revoked or belongs to another profile.
  • The credential is attached to a different WordPress user than the client expects.
  • Several similarly named credentials make ownership and active use ambiguous.
  • The visible credential name is a label and may not uniquely identify the page or workflow that created it.
  • The plugin automatically provisions a new Application Password when its previous credential is missing or invalid.

Diagnostic sequence

  1. Identify the plugin and admin page that renders the notice or assistant.
  2. Record WordPress, plugin, client, connector and server versions before changing anything.
  3. Review the Application Passwords section of the relevant user profile without exposing any secret.
  4. Inspect every plausible WordPress user instead of assuming the current administrator owns the credential.
  5. Compare credential name, creation date, last-used time and last IP with the observed workflow.
  6. Map each assistant, plugin or connector to one named WordPress user and one credential.

Apply the smallest correction

  1. Document who creates, rotates, reuses and revokes the credential, including the trigger for each change.
  2. Revoke credentials that are confirmed unused or no longer required.
  3. Create a dedicated WordPress identity instead of reusing the human administrator.
  4. Create one named Application Password for the dedicated identity and a single integration purpose.
  5. Escalate with sanitized, versioned evidence when the behavior remains specific to the plugin.

Verify the result

  • Every observed credential has an owner, purpose, creator, status and revocation decision.
  • The authenticated request resolves to the intended dedicated WordPress user.
  • The final record contains versions, evidence, change, verification and rollback information without secrets.
  • After revocation, the same credential can no longer authenticate.

What not to do

  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not delete every unfamiliar credential before recording its owner, purpose and last use.
  • Do not grant administrator access merely to make a connection test pass.
  • Do not expose debug logs or diagnostic endpoints publicly.
  • Do not publish claims about remote data use, consent or permissions that have not been verified against the exact version.

Sources and verification

This page was checked against the following primary sources. Last source review: .