Application Passwords Explained: The Safe Way to Give AI Access to WordPress
Some MCP services add their own permission layer on top of the WordPress role, such as a drafts-only mode or the ability to switch off whole groups of tools.
Saqib
Every time a new tool promises to "connect to your WordPress site," the same question should come first: what exactly am I handing over? For years, the honest answer was "your admin password," which is a poor answer. A password that logs you into the dashboard can also change your email address, install plugins, and lock you out. Giving it to a third-party service, however trustworthy, was always a compromise.
WordPress solved this quietly in version 5.6 with a feature called application passwords. If you are thinking about letting an AI assistant manage your blog through an MCP server, understanding application passwords is the single most useful piece of background knowledge. This article explains what they are, how they differ from your login, and how to use them well.
What an Application Password Is
An application password is a second credential attached to an existing WordPress user. It is generated by WordPress, twenty-four characters long, and shown to you exactly once. It cannot be used to log in to the dashboard. It works only with the REST API and XML-RPC, which is to say, with programs rather than people.
A user can have many application passwords, each with its own name, and each can be deleted independently. Deleting one has no effect on the others or on the user's real password. That independence is the whole point: you can give one program its own key and take that key back without touching anything else.
Why This Matters for AI Assistants
AI assistants that use the Model Context Protocol act on your site through a server that translates their requests into REST API calls. That server needs to authenticate with your WordPress installation. There are exactly two sensible ways to do that: OAuth, which WordPress does not support natively, or application passwords, which it does.
With application passwords, the arrangement looks like this. You create a password named after the assistant, for instance, "Claude" or "ChatGPT." You give it to your AI app when you set up the connector. The assistant sends it, together with the username, on each request. The MCP server relays it to your site and gets on with the work.
A careful WordPress MCP server never stores that password. It passes it through and forgets it. Your credentials live only in your AI app, and the only party that persists them is you. If you ever suspect a problem, you delete the application password in WordPress, and every connection built on it dies instantly. No support ticket, no waiting.
Least Privilege: Pick the Right User
An application password inherits the capabilities of the user it belongs to. This is the second half of doing it safely. Do not create the password on your administrator account out of convenience. Create a dedicated user with the role that matches the work.
- Editor: can publish and edit any post or page, manage categories, tags, and comments, upload media. This is the right role for an assistant that manages content.
- Author: can publish and manage only their own posts. Good for an assistant that writes but should never touch other people's work.
- Contributor: can write drafts but not publish or upload files. The strictest choice for a drafts-only workflow.
An Editor cannot install plugins, change themes, add users, or alter site-wide settings such as the site URL. If an assistant on an Editor account misreads an instruction, the worst case is a content mistake, and content mistakes are covered by revisions.
Some MCP services add their own permission layer on top of the WordPress role, such as a drafts-only mode or the ability to switch off whole groups of tools. Use both. The WordPress role is the hard floor; the service's mode is the daily control.
Creating One, Step by Step
- Sign in to WordPress as the user that will be used by the assistant, or as an administrator who then edits that user.
- Open Users, then Profile (or the user's edit page).
- Find the Application Passwords section near the bottom.
- Enter a name that identifies the client, such as "Claude on my laptop."
- Click Add New Application Password and copy the result immediately.
The password is displayed with spaces every four characters for readability. WordPress strips them, so it does not matter whether you paste it with or without spaces.
If the section does not appear, check two things. First, application passwords require HTTPS by default; on a plain HTTP site, they are disabled. Second, some security plugins switch them off. Look for a setting named REST API or application passwords in the plugin.
Hygiene That Takes Thirty Seconds
A few habits make the arrangement safer with little effort.
- Name every password after its client and location. Six months from now, "Key 3" tells you nothing, but "ChatGPT on the office PC" tells you whether it can be deleted.
- One password per client. Never reuse the same application password for two assistants or two devices. If you need to cut one off, you should not have to cut off the other.
- Review the list quarterly. The profile page shows when each password was created and last used. Delete anything that has not been used in months.
- Rotate after a change of tools. Stopped using an assistant? Delete its password the same day.
- Keep the real password out of it. If a service ever asks for the password you use to log in to the dashboard, that is a reason to walk away, whatever it promises.
What Application Passwords Do Not Protect Against
They are a credential, not a policy. An Editor's application password can publish, and it can trash posts. What it cannot do is escalate beyond the Editor role. Protection against content mistakes comes from elsewhere: revisions, backups, and the permission modes offered by the MCP service. Treat those as layers that stack rather than alternatives.
They also do nothing about the security of the device holding them. If your AI app is on a shared computer, anyone at that computer can act as the assistant. Log out, or use a separate user profile.
A Short Comparison with the Alternatives
Some older WordPress integrations ask you to install a plugin that creates its own API keys. That works, but it adds code to your site that must be updated and trusted. Others ask for your full login through a browser session, which grants everything the user can do, including administration. Application passwords beat both: they are built into WordPress, need nothing installed, are scoped to the REST API, and are revocable one by one.
For further reading, the WordPress core team's integration guide describes the feature in detail: Visit
The Bottom Line
If you take one thing from this article: giving an AI assistant access to your blog does not have to mean giving it your password. Create a dedicated Editor, generate an application password for the assistant, hand it to your AI app, and choose an MCP service that does not keep it. You get all the convenience of "just tell the assistant to publish it" with an off switch that is entirely in your hands.
