PAGUP Agent ControlWordPress access for AI assistants
Start free trial

Application Passwords Are Missing From the WordPress User Profile

The site is not actually served over HTTPS on the URL used by the assistant.

Record WordPress, plugin, client, connector and server versions before changing anything.

Likely causes

  • The site is not actually served over HTTPS on the URL used by the assistant.
  • The browser uses HTTPS, but WordPress does not detect the request as secure at the origin.
  • A security plugin, must-use plugin or custom filter disables Application Passwords globally.
  • Application Passwords are unavailable for the specific WordPress user selected by the integration.
  • The credential is attached to a different WordPress user than the client expects.

Diagnostic sequence

  1. Record WordPress, plugin, client, connector and server versions before changing anything.
  2. Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.
  3. Check whether Application Passwords are globally available in the active WordPress environment.
  4. Check whether Application Passwords are available for the exact WordPress user.
  5. Inspect every plausible WordPress user instead of assuming the current administrator owns the credential.
  6. Review the Application Passwords section of the relevant user profile without exposing any secret.

Apply the smallest correction

  1. Serve the exact WordPress and REST URLs over HTTPS before enabling Application Password authentication.
  2. Correct trusted proxy and origin handling so WordPress reliably recognizes the original HTTPS request.
  3. Remove or narrow the filter that disables Application Passwords only after confirming the intended security policy.
  4. Permit Application Passwords only for the dedicated user that requires the integration.
  5. Create a dedicated WordPress identity instead of reusing the human administrator.

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 REST index responds from the canonical HTTPS URL and exposes the expected namespaces.
  • The final record contains versions, evidence, change, verification and rollback information without secrets.

What not to do

  • Do not grant administrator access merely to make a connection test pass.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not edit WordPress core or third-party plugin files as the first troubleshooting step.
  • Do not add an unverified permanent proxy workaround before confirming the trusted request path.
  • Do not delete every unfamiliar credential before recording its owner, purpose and last use.

Sources and verification

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