WordPress Application Passwords for AI Connections

A WordPress Application Password is a revocable credential intended for programmatic access. It is separate from the user’s normal interactive login password and can be named and revoked individually. It authenticates as the WordPress user who owns it, so the user’s capabilities still determine what API requests are allowed.

An Application Password is safer than sharing the main login password, but it is still a secret. Store it outside code and configuration files, use HTTPS and remove it when the integration is no longer required.

In one sentence: Use an individually revocable Application Password for a dedicated limited identity, never a human administrator’s primary password.

Seeing a WAP AI Assistant HTTPS warning?

Do not grant broader access to make the notice disappear. The warning may mean that the site is not served over HTTPS, that WordPress does not detect the original HTTPS request, or that Application Passwords were disabled independently of HTTPS.

• WAP AI Assistant Requires HTTPS in WordPress: What It Means and How to Fix It
• Why WAP AI Assistant Shows an HTTPS Warning on an HTTPS Site
• How to Revoke WAP AI Assistant Access
• What Permissions Does a WAP Application Password Have?

Authentication is not authorization

Fixing HTTPS or a credential error restores an authentication path. It does not determine which WordPress user owns the credential or which actions that user may perform.

• Which WordPress Access Level Should You Give an AI?

At a glance

What this guide helps you accomplish

This guide explains the credential lifecycle that underpins many WordPress REST and MCP proxy integrations. It covers creation, storage, transport, rotation, revocation and evidence without exposing a live secret.

A useful AI workflow is not defined only by the quality of the answer. It is also defined by the data the assistant can reach, the actions it is permitted to take, the evidence you can inspect afterward and the ease with which access can be withdrawn.

Why this matters

Users often paste their administrator username and password into a connector because it is the credential they already know. That shortcut creates unnecessary authority and makes revocation disruptive. Application Passwords provide a per-integration credential, but they do not solve overprivileged users or insecure storage.

Expected output

A successful run should produce:

• A dedicated WordPress user with an appropriate mode.
• A uniquely named Application Password.
• A secure secret-injection method.
• A successful authenticated request and denied-action test.
• A documented revocation and rotation record.

What the credential does

The credential proves the request is acting as a specific WordPress user. WordPress then evaluates the endpoint and user capabilities. An Application Password does not grant administrator authority by itself and should not be described as an API key that bypasses WordPress roles.

Creation and naming

Create the credential from the dedicated user’s profile and give it a purpose-specific name, such as “Claude Code content inventory test.” Record the owner, date, environment and planned expiry or review date. The secret is normally shown once, so move it directly into the approved secret store.

Storage and transmission

Use HTTPS. Keep the secret in an environment variable, operating-system credential store, CI secret or dedicated vault. Do not paste it into a prompt, commit, .mcp.json, config.toml, screenshot or support message. Ensure debugging tools redact authorization headers.

Revocation and rotation

Revoke the individual credential when the trial, test or integration ends. If a secret may have leaked, revoke it immediately and generate a new one only after addressing the exposure path. Confirm revocation by repeating a harmless request and expecting authentication failure.

A safe workflow

1. Create or select a dedicated limited WordPress identity.
2. Generate an Application Password with a purpose-specific name.
3. Place the value in the approved secret store or environment variable.
4. Configure the connector to read the secret without printing it.
5. Send a small HTTPS read request and verify the response.
6. Attempt an unauthorized action and confirm refusal.
7. Revoke the Application Password and confirm authentication fails.

Recommended access boundary

Use a Read Only identity. The assistant may inspect the WordPress data included in its scope, but any attempt to create, edit, delete or publish content should be refused.

This workflow can influence editorial decisions or create unpublished changes. Keep the scope narrow and review every proposed change.

The access level is a starting recommendation, not a universal entitlement. The exact WordPress capabilities available to an identity must come from the installed product version and its published coverage, not from this article alone.

What must remain outside the task

• Do not generate the credential for a human administrator unless the exact task truly requires that authority and has separate approval.
• Do not transmit it over plain HTTP.
• Do not log Authorization headers or full connector configuration.
• Do not assume the credential has expired merely because the trial ended; revoke it explicitly.

How PAGUP Agent Control fits

The guided private folder for Claude Code or Codex uses WordPress REST and an Application Password with a dedicated read-only profile. Existing Read Only, Draft, Content Editor and Publisher profiles remain under Advanced. They are not automatically converted to OAuth and do not inherit the remote task and exact-approval model.

Get structured site information and inspect selected published pages after connecting. No temporary task is needed for this public reading. You can also browse public pages without the plugin; Agent Control adds structured access and a path toward authorized WordPress work.

Connect your AI: docs first profile · See features and compatibility: coverage

Verification checklist

• ☐ The credential belongs to a dedicated identity.
• ☐ Its name identifies the integration and environment.
• ☐ The value exists only in an approved secret location.
• ☐ HTTPS is enforced.
• ☐ Logs and screenshots contain no secret.
• ☐ Revocation is confirmed by a failed request.

Common failure modes

• Using the main password: Revocation affects the human account and exposes interactive login credentials.
• Storing the secret in configuration: A shareable project file becomes a credential leak.
• Creating it on an administrator: The revocable credential still inherits excessive WordPress capabilities.
• Forgetting to revoke: A temporary test leaves a permanent active secret.

Advanced note

Credential governance should bind the Application Password to an owner, purpose, environment, task class, mode, creation time, last-use evidence and revocation state. The credential itself must never enter the governance record; only a safe identifier or fingerprint should be stored.

Related guides

• Using the WordPress REST API with an AI Assistant
• Why an AI Assistant Should Not Use Your WordPress Administrator Account
• How to Revoke an AI Assistant’s Access to WordPress
• WordPress AI Connection Errors: Why 401 and 403 Can Be Useful

Continue

Next step: open Which WordPress Access Level Should You Give an AI?, choose the smallest suitable access level, then follow the relevant connection guide. When you are ready to create a separate and revocable identity, review Product or begin the 7-day Solo trial.