Last week I gave an AI agent admin access to a live WordPress site – on purpose, and without ever showing it my password. Here’s what I learned about doing this properly, including the two things that went wrong and the one time the AI refused to do what I asked. All of it is a lesson.
The setup
I’ve been using Claude Code to work on AI Search, my WordPress plugin, and on its marketing site. At some point the natural next step was obvious: I wanted the agent to edit the site directly – rewrite pages, create content, manage settings – instead of me copy-pasting everything it produced.
That means giving an AI credentials to a production website. Most people do this the worst possible way: they paste their admin password straight into the chat. Please don’t. Here’s the thing about a chat conversation: you don’t control where that text goes, how long it’s retained, or what other tooling sees it. A password pasted into any chat – AI or otherwise – should be considered burned.
What we did instead
1. An Application Password, not my real password. WordPress has had Application Passwords built in since 5.6, and they’re made exactly for this. They only work over the REST API – they can’t be used to log into wp-admin – and each one is a separate credential you can revoke without touching your real password. One click in Users → Profile → Application Passwords and the agent’s access is gone, while yours is untouched.
2. A local file, outside any git repository. The agent needs to read the credential somehow. We put it in a plain text file on my desktop – deliberately outside every project folder – so there was zero chance of it being committed to a repository. If a secret is anywhere near a git repo, sooner or later it ends up in one. The file’s location was mentioned in chat; its contents never were.
3. Least privilege, named access. Name the application password after who’s using it (“claude”), so when you look at your access list in six months you know exactly what it is and whether it should still exist. And give the underlying user only the role the job needs – an Editor role is enough for content work; save Administrator for when settings genuinely need changing.
4. Revoke when the work pauses. An unused credential is pure risk. When the project goes quiet, revoke it. Making a new one next time costs thirty seconds.
What went wrong (and taught me things)
The CDN ate the Authorization header. Our first attempts failed with a misleading “not logged in” error. The password was fine – the hosting CDN was stripping the Authorization header before it ever reached WordPress. The diagnosis was interesting in itself: a wrong password should produce a different error than a missing one, and it didn’t, which told us WordPress never saw the credential at all. The fix was passing the credential under a custom header name that the CDN leaves alone, restored server-side by a small snippet. Lesson: when API auth fails mysteriously, suspect the infrastructure between you and the application before suspecting the password.
The stale password. Later, everything worked except authentication – headers arriving, HTTPS detected, and still rejected. The application password in the file simply wasn’t the one in WordPress anymore. Regenerating it fixed everything in a minute. Lesson: application passwords are shown once; if there’s any doubt about a copy-paste, don’t debug – regenerate.
The time the AI said no
At one point I asked the agent to clean up a leftover diagnostic endpoint. The code snippet that contained it was locked to its author (me), so the agent couldn’t edit it directly – and when it tried to route around that restriction from a different snippet, its own safety layer stepped in and blocked the action, telling it to stop and explain the situation to me instead.
Which it did. I made the one-line edit myself in thirty seconds.
I want to highlight this because it’s the opposite of a failure. An agent that will happily engineer its way around access controls is an agent you can’t trust with credentials at all. The boundary held, the human was informed, and the work still got done – with the right person doing the sensitive part. That’s exactly the division of labour you want.
The checklist
If you’re going to let an AI agent work on your WordPress site – and honestly, it’s worth it – do it like this:
- Never paste real passwords into any chat. Anywhere. Ever.
- Use Application Passwords (or scoped API tokens on other platforms). They’re revocable, auditable, and can’t open wp-admin.
- Keep the credential in a local file outside your repositories, and reference the file, not the secret.
- Name the credential after its user and grant the minimum role that does the job.
- Expect infrastructure weirdness – CDNs and security layers love to strip auth headers. Test with a deliberately wrong credential: if the error doesn’t change, your password isn’t the problem.
- Revoke on pause, regenerate on doubt.
- Prefer agents with working guardrails. The refusal is a feature. If your agent never says “I shouldn’t do this – you do it”, that’s not convenience, that’s exposure.
The result of all this? Over a few days, the agent shipped three plugin releases, rebuilt the marketing site, built a live demo, and translated the entire admin into three languages – and at no point did it know my password, and at any moment I could cut its access with one click. That’s the deal you want: full productivity, revocable trust.
I build and customize AI-powered search for WordPress and WooCommerce. If you’re thinking about this kind of setup for your own project, let’s talk.
Leave a Reply