PAGUP Agent ControlWordPress access for AI assistants
Start free trial

WordPress Application Passwords Are Disabled: Causes and Safe Checks

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

Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.

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.
  • Another plugin changes HTTPS detection, REST access or Application Password availability.

Diagnostic sequence

  1. Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.
  2. Confirm that WordPress itself evaluates the request as HTTPS, not only the browser.
  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. Record WordPress, plugin, client, connector and server versions before changing anything.
  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. Escalate with sanitized, versioned evidence when the behavior remains specific to the plugin.

Verify the result

  • The REST index responds from the canonical HTTPS URL and exposes the expected namespaces.
  • The authenticated request resolves to the intended dedicated WordPress user.
  • The approved narrow read succeeds with a reproducible response.
  • A deliberately forbidden write remains refused.

What not to do

  • Do not grant administrator access merely to make a connection test pass.
  • Do not disable the WAF or security plugin globally to bypass one request.
  • Do not add an unverified permanent proxy workaround before confirming the trusted request path.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not confuse successful authentication with permission to perform every WordPress action.

Sources and verification

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