Nearly everything written about this plugin is about what you can turn on. Which abilities to enable, which role to connect as, which optional guard to switch on when your situation calls for a tighter leash. That is the interesting part, because it is the part you control. But there is a quieter half to the design that is worth saying out loud, because it is the half you do not control and cannot reconfigure your way out of. It is the floor. These are the things an agent connected through Agent Abilities for MCP cannot do, no matter which of the 153 governed abilities you enable, no matter how a request is phrased, no matter which client sends it.
Some doors were never built
The simplest boundary is the one that does not exist as a setting at all. There is no ability to run arbitrary code. There is no ability to fetch a remote URL on the agent’s behalf. There is no ability to read or write an arbitrary site option or an arbitrary piece of site meta. You will not find a toggle for these, hidden in an advanced tab or waiting behind a warning, because the toggle was never made. The catalog is a fixed list of specific, named tasks, and those capabilities are simply not on it.
This matters more than it sounds. A lot of “AI can control your site” tooling works by handing an agent a general lever, run this, fetch that, set this option, and trusting the prompt to stay reasonable. That approach means the boundary is only ever as good as the last instruction. Here the boundary is the catalog itself. If an ability to do something dangerous does not exist, no prompt can talk the plugin into it, because there is nothing to call.
Media is validated by its bytes, not its URL
Uploading an image is a good example of a bounded ability doing exactly what it says and nothing more. When an agent adds media, it does not point the plugin at a URL and ask it to go fetch. It hands over the image data inline, and the plugin decodes that data and checks the real bytes against an allow-list of image types before anything is written. The check is on what the file actually is, not on what it claims to be or what extension it wears.
So there is no path where “upload this image” quietly becomes “make a request to this server I control.” The agent cannot use the media ability as a way to reach out from your site, because the ability never reaches out in the first place. It only ever works on data already in hand.
Post meta stays on the allowlist, and some keys can never join it
Post meta is a place where a bounded ability still needs a bounded scope, and it has one. An agent can read and write post meta, but only for the specific meta keys an administrator has explicitly added to an allowlist. A key that is not on the list does not exist as far as the agent is concerned. It cannot read it, and it cannot write it.
There is a harder line inside that one. Certain keys can never be allowlisted at all, whatever an administrator does. Protected keys, the underscore-prefixed internal keys WordPress treats as private, and keys tied to authentication are all off the table by construction. You could not open them up even if you wanted to, which is the point. The allowlist gives you room to say yes to the meta your own theme or plugin relies on, without also handing over the internal machinery that keeps accounts and private state safe.
Users get the default role, and the last admin stays
The users ability is capability-gated like everything else, so most connections cannot touch accounts at all. But even where it can run, it is fenced. A user it creates lands on the site’s default role, whatever you have set that to, never Administrator. There is no path where an agent spins up a fresh admin for itself.
And the account that matters most is protected outright: the last remaining administrator can never be removed. It does not matter how the request is worded or how many steps it is broken into. WordPress needs one person holding the keys, and the plugin will not let an agent be the reason there is nobody left. This is one of those floors that sounds obvious until you imagine the alternative, and then it is the first thing you want guaranteed.
Destruction is off by default, and reversible where it can be
Anything that destroys is treated with more suspicion than anything that creates. Destructive abilities start off, the same as everything else, and each one is gated on a real WordPress capability, so the connected account has to genuinely hold the right to do it. There is no destructive shortcut that skips the capability check the rest of WordPress uses.
Where an ability supports it, a delete goes to Trash rather than vanishing, so a wrong move is something you recover from rather than something you mourn. That is not a promise that every action is undoable, and it should not be read as one. It is a design bias: when there is a softer version of a destructive step, the plugin takes it.
Why the floor is the real story
Put together, none of this is a feature you switch on. That is exactly why it is worth a post of its own. The abilities you enable are the part you tune to your site. The floor is the part that holds regardless, the set of things that stay true whether you connect a locked-down Subscriber or an Administrator with the whole catalog live. It is what lets you experiment with the toggles without wondering whether you have quietly left a trapdoor open, because the trapdoors were never installed.
If you want the other side of this, the controls you do get to set, the governance model walks through off by default, least privilege, and the audit log in one place. The security overview lays out the same boundaries as a reference, and the features page shows what the catalog actually offers once you start turning things on. Read those for what you can do. Read this one for what nobody can.