The question is usually asked the wrong way round. It is not whether AI can be trusted with your WordPress site. It is what you actually connected it to, and whether that connection can do things you would not sanction.
An assistant with a well-designed set of tools is considerably safer than an assistant with your admin password. An assistant with a badly designed set is a liability no amount of careful prompting will fix.
The real risk is the tool list, not the model
When you connect an AI assistant to WordPress, it does not gain access to your site. It gains access to a specific list of operations someone decided to expose. That list is the entire security boundary.
If there is no tool for deleting posts, no prompt will delete a post. If there is a tool that runs arbitrary code, then everything else is decoration.
So the question to ask about any AI integration is not “is the AI safe” but “what is on the list, and what happens if the token leaks”.
Four things that should never share one switch
Reading content
The safest thing an assistant can do, and where any connection should start. Reading tells you whether the integration works before anything can be changed.
Writing content
Editing posts and pages. Recoverable — WordPress keeps revisions — and the worst case is embarrassing rather than catastrophic.
Writing code
Editing plugin or theme files is arbitrary code execution. It has nothing in common with editing a paragraph and should never be implied by content permissions. Consenting to “fix my typos” is not consenting to “run code on my server”.
Installing and activating
Installing puts third-party code on your server. Activating runs it with full privileges. No backup undoes code that has already executed, which is why this deserves its own explicit opt-in and its own confirmation.
An integration that bundles these into one “allow AI to manage my site” toggle has made a decision on your behalf that it had no business making.
Credentials are the quiet problem
Your WordPress options table contains API keys, SMTP passwords, licence keys and payment credentials. Any tool that can read arbitrary options can read all of them.
The obvious defence is an allowlist: only named options are readable. That is necessary and not sufficient, because credentials hide inside innocuous-looking settings. A plugin’s main settings option might be called something entirely bland and contain a live API key three levels down.
A careful implementation checks the values as well as the names, and refuses anything credential-shaped wherever it appears.
Reversibility matters more than prevention
Mistakes are certain. What matters is whether they can be undone.
Content edits should be backed up before being overwritten. File edits should keep previous versions. Settings changes should be reversible. Actions with no inverse — deleting, activating code — should require confirmation, or not exist.
A useful test: for every tool on the list, ask what happens if it does exactly the wrong thing. If the answer is “restore it”, fine. If the answer is “restore a backup of the whole site”, that tool needs a stronger gate.
Run it as a user, not as the site
The strongest guarantee in any WordPress AI integration is also the simplest: every action should run as a specific WordPress user, with WordPress’s own capability checks applying normally.
That means the limits are enforced by WordPress rather than promised by a plugin. If the assistant acts as an Editor, it cannot change plugin settings — not because the integration is careful, but because WordPress refuses.
Pick an account with the access you actually want exposed. An Editor is usually a better choice than your main administrator.
Practical advice
Start read-only and confirm it works. Enable writing when you need it. Leave code editing and plugin installing off until you have a specific reason. Use a dedicated user rather than your own account. Treat the token like a password, because that is what it is.
And check what a tool actually did rather than trusting the summary. An assistant reporting success is reporting that the call returned, not that the result was what you wanted.
Is it worth it?
For one small site, probably not. The value scales with repetition: several sites, frequent publishing, settings scattered across a dozen plugins.
The honest framing is that this is not about trusting an AI. It is about deciding which specific operations you want automated, and refusing to hand over the rest.
Marketur MCP is built around these boundaries: separate switches for content, files, plugins and settings, everything off by default, credentials refused at read time, and every action running as a WordPress user you choose. Connecting ChatGPT or Claude to WordPress covers the setup.