An AI agent connected to WordPress does not get a permission scope of its own. It gets whatever WordPress user it connects as, and every ability it calls checks that user’s capabilities before running, the same current_user_can() check WordPress core uses everywhere else. That means the fastest, most reliable way to limit what an agent can do is not a setting inside a plugin. It is the WordPress role you connect it as, and for most content work, Editor is the right ceiling, not Administrator.
How do you limit what an AI agent can do on your WordPress site?
Connect the agent as a WordPress user with a limited role, such as Editor, instead of an Administrator. Every ability the agent calls re-checks that account’s capabilities before it runs, so the role becomes the real ceiling on what the agent can do, no matter how a request is phrased or which client sends it.
Takeaways:
- An AI agent inherits a real WordPress user’s capabilities. It does not get a separate permission scope of its own.
- Every ability call re-checks that user’s capability before it runs, using the same
current_user_can()check WordPress core uses for its own screens. - Editor can publish and manage content across the whole site but cannot change site-wide settings, edit or promote other users, or install plugins, capabilities Administrator has by default.
- Over OAuth there is no role picker inside the connection flow. The agent takes the capabilities of whichever account is logged in when you approve it in the browser.
- Over an Application Password, this plugin’s own Connection tab creates a dedicated agent user for you, but it lands as a Subscriber, not an Editor. You still choose the role on purpose.
Why the role you connect as is the real ceiling
WordPress does not have a separate permission system for AI agents. It has one system, roles and capabilities, that has governed every user, plugin, and theme since version 2.0. Agent Abilities for MCP does not replace that system or invent a parallel one. It registers each ability against a real WordPress capability and checks the connected user against it before the ability runs.
That check happens twice, not once. When the client asks what tools are available, it only sees the abilities the connected user’s capabilities allow. When it calls one, the plugin checks the capability again before letting the ability run. A tool the account cannot use is not just refused. It is not offered in the first place, and if a call somehow reaches the second gate anyway, that gate is still there.
So the practical question is not “which abilities did I switch on.” It is “which WordPress user did I connect as.” Switch on every content ability you like; an Editor-scoped connection still cannot touch anything an Editor cannot touch in wp-admin. Switch on nothing at all; an Administrator-scoped connection is one enabled ability away from doing whatever an Administrator can do.
What Editor can do that Administrator can also do, and what it cannot
Editor is a genuinely capable role. It can publish, edit, and delete any post or page on the site, including other people’s, moderate comments, and manage categories and menus. For most content tasks you would hand an agent, that is already everything needed. Where it stops is the handful of capabilities that reach past content into the site itself.
| Capability | What it unlocks | Editor | Administrator |
|---|---|---|---|
publish_posts |
Publish and manage content | Yes | Yes |
edit_others_posts |
Edit content other users wrote | Yes | Yes |
moderate_comments |
Approve, edit, and delete comments | Yes | Yes |
manage_categories |
Create and manage taxonomy terms | Yes | Yes |
manage_options |
Change site-wide settings under the Settings menu | No | Yes |
edit_users |
Create, edit, promote, or delete WordPress accounts | No | Yes |
install_plugins |
Install and activate new plugins | No | Yes |
edit_theme_options |
Change menus, widgets, and the Customizer | No | Yes |
Source: WordPress.org, “Roles and Capabilities,” last updated September 20, 2024.
Why the gap matters more than the plugin’s own catalog suggests
Agent Abilities for MCP’s own catalog is bounded on purpose. Nothing in it runs arbitrary code, fetches a remote URL, writes an arbitrary option, or installs a plugin, whichever account connects. So an Administrator-scoped connection cannot get the plugin itself to hand over manage_options or install_plugins-level power just because the account holds those capabilities. That protection is real, and it does not depend on which role you pick.
Two things still make the role worth getting right, though, and neither is hypothetical.
The plugin’s own catalog includes a Users ability, described in the plugin’s own documentation as capability-limited, and that limit is exactly the connected account’s real WordPress capabilities. Administrator holds edit_users, create_users, and promote_users; Editor holds none of them. Connected as Editor, a call that tries to edit, create, or promote a user is denied and logged as a denial. Connected as Administrator, the same call is allowed to run, because the plugin is correctly deferring to what that account can actually do.
The second reason is the credential itself, and it matters most if you connect over an Application Password rather than OAuth. An Application Password is a whole-site WordPress credential, bounded only by the role of the account it belongs to, and the plugin cannot narrow it. Put one on an Administrator account and that credential is a working admin login anywhere in WordPress, including the REST API and XML-RPC, not just through this plugin’s own governed endpoint. Put the same credential on an Editor and a leak or a misused client caps out well short of admin, no matter what generated the request.
Agent Abilities for MCP checks every ability against the connected account’s real WordPress capabilities, the same check WordPress core uses for its own screens. Choosing Editor over Administrator for that account is the single highest-leverage scoping decision available, and no setting inside the plugin overrides it.
The honest part: there is no role picker in the connection flow
It would be convenient if the plugin’s Connection tab had a dropdown: pick Editor, pick Contributor, done. It does not, and the real mechanics are worth knowing rather than assuming.
Over OAuth, the agent takes the capabilities of whichever WordPress account is logged in when you approve the connection in the browser. There is no capability picker inside the consent screen itself. If you are logged in as an administrator when you click approve, the agent becomes an administrator, regardless of what you intended. The fix is procedural, not a setting: log out of your own account, log in as the Editor-role account you want the agent to be, and approve from there. The full walkthrough of this flow, including what the consent screen does show you, is in OAuth or Application Password: how to connect an agent.
Over an Application Password, the account is chosen up front rather than at approval time, which is the whole appeal of that path. But the plugin’s own Connection tab can create a dedicated agent user for you, and that account is created with the Subscriber role, not Editor. A Subscriber can read its own profile and little else, so if the task needs Editor-level actions, that auto-created account needs its role changed on the Users screen before you generate the Application Password, or you generate the password on an Editor account you already trust instead.
Neither path is a shortcut around picking the role deliberately. Both just move the decision to a different moment: OAuth to the moment you approve, Application Password to the moment you create or choose the account.
Step by step: connect the agent as an Editor
- Decide the task first. Content work, drafting, editing, moderating comments, fits Editor cleanly. If the task also needs WooCommerce, ACF, or another integration, note that now; Editor alone will not cover it (see the FAQ below).
- Create or choose the Editor account. Do not reuse your own administrator login. Use an existing Editor-role user if one already exists for content work, or create one from the Users screen with the Editor role.
- If connecting over OAuth, log out of any administrator session first. Log in as the Editor account, open the plugin’s Connection tab, and approve the connection while that account is the one signed in.
- If connecting over an Application Password, either generate it on the Editor account from step 2, or use the Connection tab’s auto-created agent user and change its role from Subscriber to Editor on the Users screen before generating the password.
- Enable only the abilities the task needs. Everything starts off. Turn on the specific content abilities the task calls for and leave Users, Settings, and site health off unless you have a real reason to switch them on.
- Test with one read-only ability first, then check the audit log entry to confirm both the account name and the result before enabling anything further.
Try it: a prompt that shows the boundary
Once you have connected, a useful first move is to ask the agent to describe its own limits before asking it to do anything else:
List every WordPress ability you can currently call on this site, group them into read and write, and tell me which ones you cannot call and why.
Run that in a fresh conversation right after connecting, before switching on anything beyond a couple of read abilities. If the agent reports a capability it should not have, the account is not scoped the way you think it is, and that is worth catching before the agent does anything else.
Common mistakes
- Approving OAuth while still logged in as your own administrator account, out of habit, which hands the agent your capabilities instead of the Editor account’s.
- Assuming the Application Password screen’s auto-created agent user is already Editor-scoped. It lands as a Subscriber, and a Subscriber alone cannot do much beyond reading its own profile, so most content tasks need the role changed first.
- Enabling the whole ability catalog at once instead of the handful a task actually needs. The audit log gets noisier and harder to check when you do want to look something up.
- Generating an Application Password on an account you also use for something else, so revoking the agent later means untangling it from that account’s other logins too.
A quick FAQ
Can I pick the agent’s role from inside the connection screen? No. Over OAuth, the agent takes the capabilities of whichever account is logged in when you approve the connection in the browser, with no role picker in that flow. Over an Application Password, you choose the account up front, either the dedicated Subscriber-role user the plugin can create for you or an account you pick yourself.
Does connecting as an Editor mean the agent can do anything an Editor can do in wp-admin? Only for the abilities you have switched on. The role sets the ceiling; the plugin’s own catalog, off by default, decides how much of that ceiling the agent can actually reach, and every call still re-checks the account’s capability before it runs.
What if the task needs WooCommerce or another integration?
Editor alone will not be enough. WooCommerce’s own manage_woocommerce capability belongs to Administrator and Shop Manager by default, not Editor, so a WooCommerce task needs an account that holds that capability too. Source: WooCommerce, “Roles and Capabilities Documentation.” See Run WooCommerce with an agent for how to scope that case, and Editing customer data should need the capability that guards it for what changed there in 1.6.2.
The role is the setting no plugin can override
Off by default, capability gating, and the audit log all do real work, and none of it replaces the first decision: which WordPress account the agent becomes. Pick that deliberately, before you enable a single ability, and everything else in the governance model is reinforcing a boundary you already set rather than trying to build one from scratch. For the wider set of things that can go wrong and the control that limits each, see what can actually go wrong when you connect an AI agent to WordPress; for how that same capability check contains an agent that gets tricked, see WordPress AI prompt injection, contained.
If you have not connected an agent yet, Agent Abilities for MCP is free on WordPress.org, and its Quick Connect wizard walks through picking the account before it walks through anything else.