The whole plugin is built around one uncomfortable fact: an AI agent connected to your site can do things, and you need to stay in control of what those things are. Most of the design follows from taking that seriously. This is a walk through the governance model, piece by piece, so you can see why it is shaped the way it is.
Off by default
Nothing is exposed when you install the plugin. Not one ability. You switch them on individually, and until you do, the agent has nothing to call. This is deliberate. A tool that ships with everything enabled asks you to remember to turn things off, which is the wrong default for anything an agent can reach. Starting from zero means the surface only grows when you decide it should.
There is a second half to this that is easy to miss: an update never silently widens access. If a new version adds abilities, they arrive off, the same as everything else. You do not come back from an upgrade to find the agent can suddenly do more than it could yesterday.
Least privilege by design
When the agent connects, it connects as a real WordPress user, chosen by you, through OAuth or an Application Password. It is never handed an admin-equivalent key. That user’s capabilities set the ceiling for everything the agent can do. If the user cannot publish, the agent cannot publish. If the user cannot manage other users, that door is closed too.
This is why the plugin nudges you toward a dedicated, low-privilege account for the agent. The credential type is not the safeguard. The user’s capabilities are. Pick a narrow user and the agent is narrow by construction, before any other control comes into play.
Two-layer capability gating
Here is the part that does the quiet heavy lifting. Access is checked in two separate places, not one.
The first layer is discovery. When a client lists the available tools, it only sees the ones its user is allowed to run. An agent cannot even see a tool it has no right to call, which keeps it from wasting attempts on things that would be refused anyway.
The second layer is execution. Before any ability actually runs, the plugin re-checks the user’s capability. Discovery being filtered does not mean execution is trusted. Both gates are enforced, so a call that slips past one still meets the other. Two independent checks are harder to get wrong than one.
Bounded by construction
Some limits are not toggles you set. They are baked in. The plugin runs no arbitrary code and fetches no remote URLs on the agent’s behalf. There is no open option or meta write, so an agent cannot poke at arbitrary settings. Post meta writes are limited to an allowlist of keys. Deletes go to Trash where WordPress supports it, so a mistake can be recovered rather than being final. And the last remaining administrator account can never be removed, no matter what the agent asks. These are floors, not preferences, which means you cannot accidentally configure your way underneath them.
An honest audit log
Every call is written to a log in your own database. Not just the successful ones. Refused attempts are recorded too, so you can see what an agent tried to do and was stopped from doing, which is often more useful than the list of things that worked. Each entry carries the principal and the argument keys, but never the values, so the log stays useful without hoarding the sensitive content that passed through it. The log lives in your WordPress database, under your control. It is not sent anywhere.
Optional guards on top
Beyond the built-in floors, there are extra controls you can switch on when you want them. A per-minute rate limit. An IP allowlist. A force-to-draft mode that keeps new content from going live. A cap on title length. All of them are off until you set them, in keeping with the rest of the model. They are there for when your situation calls for a tighter leash, not imposed on everyone by default.
No data leaves your site
Underpinning all of it: the plugin contacts no AI provider and no external service, and makes no outbound requests of its own. Your AI client connects in. The plugin never reaches out. There is zero telemetry. Whatever the plugin records stays with you.
The point of all this
Read together, these pieces are not a pile of separate features. They are one stance. You should be able to let an agent work on your site and still answer three questions at any moment: what is it allowed to do, what did it actually do, and what did it try that got refused. Off by default, least privilege, two-layer gating, and the audit log are how the plugin makes those questions answerable. That is the whole idea, and everything else is in service of it.