PAGUP Agent ControlWordPress access for AI assistants
Start free trial

What Permissions Does a WAP Application Password Have?

A WAP-labelled Application Password is not a standalone role. It authenticates as the WordPress user that owns it. The effective authority therefore depends on that user’s roles and capabilities, the endpoint or ability being called and any additional permission callback enforced by the integrating plugin.

The label, transport or successful tool discovery does not widen those capabilities. To reduce impact, use a separate WordPress identity with the minimum capabilities required by the approved workflow.

Likely causes

  • The credential is attached to a different WordPress user than the client expects.
  • The assistant is using a human administrator account instead of a dedicated limited identity.
  • The authenticated WordPress user lacks the capability required by the endpoint or tool.
  • The workflow requests a write while the WordPress identity is intentionally limited to reading.
  • Several similarly named credentials make ownership and active use ambiguous.

Diagnostic sequence

  1. Verify that the username sent by the client matches the owner of the Application Password.
  2. Use a minimal authenticated identity check to confirm which WordPress user the request represents.
  3. Compare the authenticated user’s WordPress capabilities with the action required by the route or tool.
  4. Repeat one known, narrow read that should be allowed for this identity.
  5. Attempt one deliberately forbidden write to confirm that the boundary still refuses it.
  6. Review the Application Passwords section of the relevant user profile without exposing any secret.

Apply the smallest correction

  1. Create a dedicated WordPress identity instead of reusing the human administrator.
  2. Select the lowest WordPress access level that can complete the approved action.
  3. Create one named Application Password for the dedicated identity and a single integration purpose.
  4. Revoke credentials that are confirmed unused or no longer required.
  5. Document who creates, rotates, reuses and revokes the credential, including the trigger for each change.

Verify the result

  • 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.
  • After revocation, the same credential can no longer authenticate.

What not to do

  • Do not grant administrator access merely to make a connection test pass.
  • Do not confuse successful authentication with permission to perform every WordPress action.
  • Do not treat every 403 as a broken connection; it may be the correct permission refusal.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not jump from a limited identity to Full Power without a separate approved workflow, staging and rollback.

Sources and verification

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