MCP security best practices for a WordPress site
The best MCP security practices for a WordPress site come down to six rules: let the assistant read before it changes anything, give it the narrowest access that does the job, keep heavy changes behind your own yes, log every call including the refused ones, keep a credential you can end, and look at what else can reach the site. BetterShield › Agents has a setting for each.
This post is the rulebook. The step-by-step connection, with the six questions to ask first, is in WordPress MCP: connecting an AI assistant to your site safely; here we turn those answers into rules you can check on your own site.
Quick summary
- Start read-only. Let my agent read security information gives an assistant 27 read-only abilities, and until it is on, nothing is offered to agents at all.
- Reading and changing are separate switches. Issue a read-only credential whatever the switches say.
- Small fixes with a way back apply directly. Anything heavier waits for a plan you agree to, and three fixes are never applied by an assistant.
- Each connected app can be limited to the tools it needs, on top of the site’s switches.
- Every ability call is recorded in Agent activity, refused ones too, and Rotate, Disconnect and Revoke end access at once.
- Agents › Agent surface shows what else on the site can act for an agent, from any plugin.
Why MCP needs rules at all
MCP, the Model Context Protocol, lets an AI assistant call tools in another system while it answers you. On a WordPress site those tools are abilities: named actions that a plugin offers to assistants and other tools, such as reading the security score. Each use of one is a call.
The assistant connects to your site’s own address and runs as the account that connected it, so it can never reach further than that account can. That is a good start, and it is also the reason the rest of the rules matter: the safest assistant is the one with the least it can do. This is the principle of least privilege, applied to a tool that talks.
Rule 1: read first, and read for a while
Turn on only step 1. On BetterShield › Agents › Connect, the Three steps to a connected assistant card has three switches, all off until you turn them on. Let my agent read security information is the first. With it on and nothing else, an assistant can use 27 read-only abilities: the score, grade and findings with their explanations, which fixes are on, the activity log, the file check, versions, and more. One of them, get-security-overview, gathers the score, its history, the findings with their fixes and how ready your recovery is into a single read, a good first question for a new connection.
What it reads is bounded. Login protection comes as counts, never addresses. Users come by display name and role. File checks return no file contents. Connector keys appear only as where they are stored, never as keys.
We recommend living with a read-only assistant for a week. Ask it what matters most on your site, and judge whether its answers are worth giving it more.
Rule 2: give it the narrowest access
Changing is a separate decision. Step 2, Let agents act: changes that can be undone right away, anything heavier once you agree, is off by default, and step 3, Let an assistant connect to this site, opens the connection itself. Turn them on only when you have a reason.
Each connected app can also be held to the tools it needs. Open Tools beside the app under Agents › Connect, keep only those the app’s job requires and press Save Tools. The app sees the new selection the next time it refreshes its tool list. This is an extra boundary: it never grants anything the switches, the credential or the account forbid. Our advice is a separate connection, and a reviewed tool selection, for each app.
The credential has its own limit too. Allow this credential to change the site decides whether the next credential may change the site or only read, and you can issue a read-only credential whatever the switches say. On the approval page that Claude and ChatGPT open, Allow it to change this site is ticked when changes are possible, and you can untick it.
There is also a ceiling on pace: 5 changes of one kind per hour for each connection (15 for the site as a whole), and 30 plans of one kind per hour for each connection. Extra requests are refused, not queued. That limit means a runaway assistant cannot make a hundred changes while nobody is looking.
Rule 3: keep heavy changes behind your yes
Not every change is the same size, and the settings treat them differently.
| Kind of change | How it happens |
|---|---|
| Remote publishing block (XML-RPC), File editor lock, Username privacy, WordPress version privacy, Browser protections | Applied directly, each with a way back |
| The six Signing in fixes, the six-month or all-subdomains form of the HTTPS fix, taking any fix off, putting a changed file back | A plan you agree to in the conversation |
| Uploads code block, Folder listing protection, Private file protection | Never by an assistant |
Newer releases add three more confirmed actions: ending sessions, revoking another connected app and putting the site into lockdown. A write-scoped assistant can propose each one, and applies it once you agree in the conversation. A caller that carries no such confirmation waits under Agents › Requests until you choose Allow once. Only the site itself can lift lockdown. An assistant can also help with confirmed file changes and incidents, and each has an undo. Write-scoped assistants can run audits, check files and recovery, and refresh incident evidence, but they cannot enforce a protection.
For the middle row, BetterShield writes out a plan first: what would change, and whether it can be put back. The assistant is told to show you the plan and act only after you agree. The plan expires after 15 minutes, and the site is checked again before anything moves. Sign-in changes also need your recovery link verified within the last day.
WordPress MCP write access: approvals, limits and undo walks through each kind of change in turn. Some things stay yours whatever is switched on. Agents › Permissions lists them under What stays yours: no assistant can make an account or credential, change your recovery options, weaken two-factor or alerting, lift a lockout, remove log rows, or write wp-config.php or .htaccess.
Rule 4: log every call, refused ones too
A log you do not read still helps later, and one that skips refusals hides the most interesting calls. Record what agents do on this site is on by default, and it records every ability call, whichever plugin registered the ability and however the call came in.
Open BetterShield › Activity › Agent activity and use the figures at the top: Recording, Calls, Refused and Completed. Filter by Outcome, by namespace, and by Came through: MCP, REST, WP-CLI or PHP. Each row has the time, the ability, the account, how it came in and how it ended. The input is kept only as a digest, never its contents, because an input can carry a secret.
Two limits to know. Recording needs WordPress 7.1 or newer. And a namespace is a naming convention, not proof of who is behind an ability, because WordPress does not record which plugin registered it.
Refusals also reach the main activity log, as Ability refused and, after ten refused requests within an hour, Abilities refused repeatedly. If another plugin stops the recording, BetterShield cannot prevent that, but it writes Agent activity recording stopped to the log.
Rule 5: keep a credential you can end
Treat the Connection credential like any other secret. It is shown once when you press Connect, and the site keeps only a fingerprint of it. Put it only where the assistant needs it. Apps that open an approval page can connect through browser sign-in instead, with no key to copy. Either way, keep assistants, issued credentials and application passwords apart in your head: Connected apps lists the first two, and application passwords live with each account.
You have four ways to end access, from gentlest to most complete:
- Turn off Let an assistant connect to this site. The site answers no assistant, and no grant is ended.
- Rotate the credential. The old one stops working at once.
- Revoke one app under Connected apps.
- Disconnect, which ends the credential and every signed-in app.
To keep reading but stop changes, turn off the step 2 switch on Agents › Permissions. Changes stop at once, even for a credential that was allowed to make them.
Press Test connection under Connection health after any of these. It makes one real call and says where it stopped.
Rule 6: look at what else can reach the site
BetterShield’s switches govern BetterShield’s own abilities. Other plugins can offer abilities too, and your rules should cover them. Agents › Agent surface lists every ability any plugin offers agents: whether it writes, whether it is reachable over REST, and who can call it. One that does all three and is open to lower roles becomes a finding. Filter with Open to lower roles to see them. Current versions also monitor the AI connections other plugins add and changes to the abilities on the list, so the picture stays current. Seeing something there is not approval of it, nor proof that it is safe. WordPress MCP permissions: limit each AI app’s tools shows how to limit each connected app to the tools it needs and how to review that screen.
The same screen covers application passwords, which sign tools in without a second factor, by design. Each account’s are listed, and one unused for 90 days is marked stale. Limit… holds one to certain REST routes, an address range, or both. WordPress application passwords: find, limit and revoke them goes deeper, and the doc Block app passwords covers turning them away for site managers or everyone. Two optional tripwires sit here too: Keep a decoy credential on my account and Decoy URL. Any use of the decoy is refused and alerts you, and a hit on the decoy path can mean probing or a stray visit, not proof of a break-in.
For the WordPress side of this, the platform’s own security documentation explains capabilities, nonces and data validation, which are the foundations any ability relies on.
A short checklist
- Step 1 on, steps 2 and 3 only when you have a reason.
- A read-only credential unless you need changes.
- Tools limited per app, with Save Tools pressed.
- Record what agents do on this site left on.
- Agent activity opened after the first week, with the Refused figure checked.
- Agents › Agent surface opened once, with Open to lower roles selected.
- A note of how you would Rotate or Disconnect, before you need to.
Frequently asked questions
Is an MCP server on my WordPress site safe?
It is as safe as its settings. BetterShield’s is off until you turn it on, starts read-only, and keeps heavier changes behind a plan you agree to. The rules above are how you keep it that way.
Should I give an assistant permission to make changes?
Only once you have a reason. Reading covers most questions. If you do allow changes, the small ones apply with a way back, and the heavier ones, including ending sessions, revoking another app or entering lockdown, wait for your yes in the conversation.
Can an assistant see passwords or email addresses?
No. Users come by display name and role, session times carry no tokens, file contents are never returned, and connector keys are shown only as where they are stored.
How do I know what an assistant did?
Open Agent activity. It lists every ability call on the site, with the time, the ability, the account, how the call came in and the outcome. Refused calls are highlighted.
What do I do if a credential leaks?
Press Rotate to replace it, or Disconnect to end it and every signed-in app. Both take effect at once. Ending a connection does not reverse what it already did. Then check Agent activity for calls you do not recognize.
Conclusion
Letting an assistant near a site is a series of small decisions, and each one has a switch. Start read-only, grant the least that works, keep the heavy changes behind your yes, read the log, and know how to cut access off.
BetterShield is free on WordPress.org. The docs cover each setting: Connect an AI assistant, Agent activity, and the playbook for AI assistants and agents.