Yes, let an AI agent edit your WordPress site — but not as you. Create a separate user for it, give that user a named application password, and turn write abilities on one at a time. The mistake almost everyone makes is clicking “Allow” on their own admin account because the screen offers it first, and that single click hands a chat window the same keys you use to change themes, install plugins and delete users.

This stopped being a thought experiment this month. OpenAI opened “Businesses in ChatGPT” on 10 November, WordPress.com told owners on 11 November to install its plugin and manage their site from that chat, and the WordPress AI team shipped an MCP Access screen that finally lets you choose which abilities an agent can see. The plumbing works. The scoping is the part nobody explains.

The short version

• Your site can already be edited from a chat window. WordPress.com has MCP on all paid plans, and free sites plus self-hosted sites connected through Jetpack can use it free until 30 November 2026.
• An agent should authenticate as its own user with its own application password. Never your admin login, never your account password.
• Grant abilities by name, starting with read-only ones. “Full access” is a checkbox, not a decision.
• Keep four things off permanently: user roles, plugin and theme installation, permanent deletes, and publishing without a human read.
• After the first task, check the revisions and the log. That trail is how you prove what it did.

What changed, and why it landed on your dashboard

Three releases in fourteen days:

• WordPress AI 1.5.0 (29 October) added an MCP Access experiment. It installs the MCP Adapter plugin and adds a Tools → MCP Access screen listing every registered Ability with a switch, plus your site’s MCP endpoint. Abilities in the adapter are private by default, so exposing one is now a deliberate act.
• Uncanny Automator put an MCP server inside its free plugin on 2 November. Its free tier gives you 300 tool uses a day in the first week, then 150 a day — and its own documentation is blunt about the guardrails: you approve the connection as an administrator, choose read-only or read-and-write, and switch off any single action. Raw database changes and deleting users are never available to any AI.
• WordPress.com published the ChatGPT plugin flow and, on 11 November, told business owners to install it. When you install it you pick Full access, Read only, or Keep existing access — and that choice applies to every AI you connect to the account, not just ChatGPT.

Access is granted at the account or endpoint level, while the risk lives at the ability level. That gap is where a solo operator gets hurt.

Three layers of access, and the default at each one

Step 1: Give the agent its own identity

Go to Users → Add New and create a user called something obvious like agent-editor. Give it the Editor role, not Administrator. Editor can write, edit and publish posts, manage categories, moderate comments and upload media. It cannot touch plugins, themes, users or site settings — which means the worst possible prompt still cannot install anything.

Then create an application password for that user. Application passwords are per-user, so you either log in as the agent user once, or use WP-CLI:

wp user application-password create agent-editor "chatgpt-mcp" --user=agent-editor

WordPress shows the password once. Copy it into the MCP client and nowhere else. Revoking it ends the agent’s access without changing your login, and every post it touches shows its name in the revisions — the same principle behind securing wp-login without a security plugin.

Step 2: Turn abilities on by name, not by trust

Open Tools → MCP Access and read the list before you switch anything. Every row is one thing an agent can do to your site, and the list is longer than most people expect. My order of enablement:

1. Read abilities first. Site information, list posts, get post, search content, list media. With only these on, the agent can answer real questions — “which posts have no featured image”, “what did I publish in October” — and cannot change a byte.
2. One write ability second. Updating post content or image alt text is a good first write, because the change is visible and reversible through revisions.
3. Publishing last, if ever. Keep it in draft and read the output yourself. I already fact-check every AI draft line by line in this workflow, and an agent with publish rights skips that step silently.

The abilities to leave off, in plain terms: anything with “delete” in the name, anything that creates users or changes roles, anything that installs plugins or themes, anything that writes site settings, and anything running arbitrary database queries. Uncanny Automator makes the same call in its own product — no raw database access, no user deletion. Those categories cost you a site, not an edit.

Step 3: Run one bounded task, then read what it did

Do not start with “clean up my site”. Start with a task that has an edge: “Update the alt text on the three most recent images in the media library. Change nothing else.” Then check four things:

• Revisions on any post it touched — the diff should be small and boring.
• Last edited by — it should be the agent user, not you.
• Your host’s access log — the requests should come in a short burst, not a long crawl. If you have never read one, this is the five-minute version.
• The plugin’s own log, if it keeps one. Agent Abilities records the acting user, ability name and argument keys for every call, denials included. WordPress core alone does not log MCP calls, so if nothing logs them you are trusting the agent’s own summary of what it did.

If the trail looks wrong, revoke the application password — that is the whole rollback procedure, and it takes ten seconds.

Four things I would not hand over

1. User management. A role change or a deleted administrator is a lockout, not an inconvenience. There is no revision history for users.
2. Plugin and theme installation. Updates are the most common way a working site goes down, so I do them in a window I control — see how to update core without opening an attack window. An agent updating plugins at 2am is that risk with worse timing.
3. Permanent deletes. Deleted posts and pages sit in the trash for 30 days, but deleted media, categories and tags are gone immediately. There is no recycle bin underneath the recycle bin.
4. Anything that spends money. If a plugin ability can place an order, charge a card or send a paid API call, it belongs to you and not to a tool that guesses intent from a sentence.

The 20-minute setup, as a checklist

1. Users → Add New: agent-editor, role Editor
2. Users → agent-editor → Application Passwords: "chatgpt-mcp"
3. Install MCP Adapter (or AI 1.5.0 → enable MCP Access)
4. Tools → MCP Access: expose read abilities only
5. Connect the AI client with the agent password, not yours
6. Run one read-only task, confirm the log row appears
7. Enable update-post-content. Leave publish and delete off
8. Revoke the password when the experiment ends

One check you can do in ten seconds

Before you decide anything, check whether your site already answers on an MCP endpoint:

curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/wp-json/mcp/mcp-adapter-default-server

A 401 means the route exists and is asking for credentials. A 404 means no adapter is registered — which is good news only if you know it. The deadline worth diarising: free WordPress.com sites and self-hosted sites connected through Jetpack have MCP access free until 30 November 2026. If you want to try it, try it in the next two weeks, on a staging copy, as a user that is not you.