Giving an AI access to a client's WordPress site

A checklist that works on any tool, including ours. The site is not yours, which changes every answer.

Why this is a different question

Pointing an AI at your own site is a decision about your own time. Pointing one at a client's site is a decision about somebody else's business, made by you, usually without them being in the room.

If it goes wrong on your site you fix it. If it goes wrong on theirs you explain it, and the explanation is the expensive part.

So the questions below are not about whether AI editing is good. They are about what you can answer when the client asks.

1. Which credential, and can you take it back alone?

The test: can you cut this tool off in under a minute, without asking anybody?

• Never the client's own login. Rotating it locks out a person, and you will not do it in a hurry for that reason.
• Never a shared admin account that three tools and two contractors also use.
• An application password, named for the tool. Revoked from the user's own profile screen, instantly, affecting nothing else.

If a tool asks for anything other than a credential you can revoke yourself, that is the answer to the whole evaluation.

2. Does the credential's user have more power than the job needs?

An application password carries the full capabilities of the user it belongs to. On an administrator it can install plugins and edit theme files, whatever the tool says it does.

• Use Editor unless something genuinely requires more.
• Better: a user created for that tool, so the role is a real boundary.
• Ask what breaks at Editor. A vendor who cannot tell you has not thought about it.

3. Where does the credential live, and does the model see it?

This is the question most worth asking and the one least often asked.

A credential that reaches the model is a credential in a conversation log. Once it is there, it is wherever that log is.

4. Can it be told what it may not do?

"The AI decides sensibly" is not a control, because next month's model is a different model. What you want is a list of permissions that is off by default and enforced somewhere the agent cannot reach.

Ask specifically:

• Can it run arbitrary PHP? If yes, stop. Nothing on a client site needs that.
• Can it install or delete plugins?
• Can it edit theme files?
• Can it publish, or only draft?
• Are permissions per site, or global?

5. What happens when it is wrong?

It will be wrong. The question is what that costs.

• Is there a backup taken before the change, or only last night's?
• Is there a record of what changed, specific enough to reverse by hand?
• Can it publish without you?
• What happens if the site stops responding mid-change?

"Last night's backup" means a bad change at 2pm costs the client a day of orders. That is a different product from one that snapshots before each write.

6. Tell the client. Before, not after.

This is the section everybody skips, and it is the one with a real cost.

An application password named after an AI tool will appear in their WordPress. Somebody will see it eventually — a new developer, an audit, a security plugin's report. Finding out that way is much worse than being told.

What is worth saying, in two sentences:

• What the tool is, and that it works on their site rather than a copy.
• What it may do, and that changes are drafts you review.
• Where their content goes. If the tool uses an AI model, their page content is sent to that vendor. Say which one.
• That they can revoke it, and where the button is.

If the client is in a regulated industry, or has a contract about where data may be processed, that third point is not a courtesy. Check before, not after.

7. Start somewhere that cannot hurt

1. Your own site first, for a week. Not a client's, not a staging copy of a client's.
2. Reading only. Find out whether it understands the site before it can change one.
3. Then drafts, still on your own site.
4. Then one client site, picked because it is the most forgiving, with the client told.
5. Read the log after each session for the first few. If you cannot tell what it did, that is the finding.

Where we sit on this list

Since this is our site, the answers, once, so you can check them against anybody else's:

• An application password per site, revoked from the client's own profile screen in one click, without us.
• Credentials encrypted on your machine. The agent never receives one; the app makes the request. One exit point redacts anything credential-shaped from every reply.
• Sixty-four abilities, all off on a fresh install, set per site, enforced by a plugin on the site that does not trust the app.
• Arbitrary PHP, unsanitised CSS and raw custom field writes are not switches. They are not in the product.
• Drafts by default. A backup immediately before every write. A watchdog that reverts a change if the site stops answering.
• Your agent is your own account with Anthropic, Cursor or OpenAI. Your client's content goes to them, under their terms, and that is a real thing to disclose.

The whole model, including what we do not claim, is on the security page; every screen of the plugin is there too, which is the page to send a client who asks.