Everyone is talking about AI agents now, agents that can read your Slack, touch your CRM, write code, and apparently also log into your WordPress site and publish posts for you. I was skeptical at first. Handing an AI write access to a live site sounded like the kind of thing that goes wrong at 2am when you’re not looking. But I wanted to see for myself so I decided to actually try it on this site.
So how do you actually connect Claude to WordPress? And more importantly, how do you do it without leaving a door open you forgot about?
The plugin: WPVibe
I used a plugin called WPVibe, it acts as the bridge, a small connector installed on your WordPress site that Claude talks to through something called MCP (Model Context Protocol). Think of MCP as the language AI tools use to call into other apps, similar in spirit to how a REST API lets two systems talk, except this one is designed specifically so an AI assistant can discover what a site can do and act on it.
Once the plugin is active, connecting is basically a two step handshake:
- Ask Claude to connect the site. I just told it my URL, https://<your-site>.com, and it came back with a one click authorization link.
- Approve it inside wp-admin. Clicking that link took me straight to my WordPress dashboard where I approved the connection, same pattern as connecting Jetpack or any OAuth style login you have seen before.
After that, the credentials are stored on WPVibe’s side and Claude can query the site directly, list posts, pull plugin and theme info, even draft new content, without me pasting a password into a chat window every time.
There is also a manual path if you would rather skip the browser step: go to Users > Profile > Application Passwords in wp-admin, generate a new one named something recognizable like “WPVibe”, and hand that username plus application password combination to the connect command instead. Same result, different door.
What I checked before I trusted it
Connecting is the easy part. Before I let it anywhere near real content I wanted answers to a few questions.
What account is it actually logging in as? On my site it connected as an administrator, full manage_options, edit_theme_options, publish_posts, the works. That is more power than a content assistant strictly needs. If I were doing this again on a site with more moving parts, I would create a dedicated Editor level account instead of handing over the admin login, so the blast radius of anything going wrong stays contained to content, not plugins, themes, or users.
Does it default to safe actions? This mattered more to me than I expected. New posts default to draft status unless you explicitly tell it to publish, and deletes move to trash instead of permanently wiping anything. That single default, draft first, undo always possible, is doing a lot of quiet work to keep this from being scary.
What happens on genuinely destructive actions? Things like permanently deleting a post, running raw database queries, or changing user roles do not happen silently. They require a separate approval step, a link you click yourself in the browser. The AI cannot approve its own destructive action, you have to.
Best practices I am actually following
- Use a scoped account, not your main admin login. A dedicated Editor or Author role can write and publish content without being able to install plugins or add users.
- Prefer application passwords over your real password, always. They are revocable individually without touching your main login, and you can name them so you remember what each one was for.
- Rotate and audit periodically. Go back into Users > Profile every so often and check which application passwords still exist. Delete ones you do not recognize or no longer use.
- Never paste raw credentials into a chat. The one click authorization flow exists specifically so you do not have to. Use it.
- Keep HTTPS non-negotiable. Any WordPress REST API traffic carrying auth tokens over plain HTTP is a bad idea, full stop.
- Watch your usage. WPVibe reports call counts against a daily limit, worth glancing at occasionally so nothing runs away from you unnoticed.
None of this is exotic security advice, it is the same least privilege thinking we already apply to CI/CD service accounts and API keys in any other pipeline. AI agents touching your production site are not a special exception to that rule, if anything they are exactly why the rule exists.
Happy Building…