Govern what is already registered.

How integration works

There is no integration list to install from, and nothing to configure per vendor. The model has two halves and they meet in the middle:

• Providers register Abilities. Any plugin — core, WooCommerce, an SEO plugin, your own code — can register named actions with WordPress.
• Agents request them. Any external system that can authenticate as a WordPress user can ask to run one.

RuleFence discovers everything in the registry, classifies it, and puts a per-agent decision in front of each one. A provider you have never heard of gets exactly the same treatment as a familiar one: discovered, classified conservatively, and blocked until someone grants it.

Ability providers

The Ability Explorer groups everything by provider, with search and filters for action, risk, category, exposure, and source. That grouping is how most operators actually work: decide what WooCommerce may be asked to do, then what core may be asked to do.

Each Ability’s detail view shows its input and output schema, its native permission status, and the evidence behind its classification — so a decision is made with the facts visible rather than from the name alone.

Connecting an agent

Any agent, assistant, or automation that can authenticate to WordPress can be governed. The connection identity is a WordPress Application Password belonging to a dedicated, least-privilege user — created through the Connection Wizard, revealed once, and never reused across agents.

1. Create the managed agent and describe its purpose and environment.
2. Run the Connection Wizard and choose a dedicated user. Its role is the authority ceiling for everything this agent will ever do.
3. Give the credential to the agent, once. Rotate it from here whenever you need to; the identity and its history stay intact.
4. Grant the first Ability explicitly, and leave the rest on default deny.

MCP endpoint

Where an agent framework speaks the Model Context Protocol, the site can expose a governed endpoint so tools are discovered and invoked through the same control path. The configuration is copyable from the admin screen, and the endpoint is optional — it is off unless you turn it on.

Exposing an endpoint does not change any decision. Requests arriving over MCP pass through identity resolution, native authorization, permission evaluation, approval, and the audit chain in exactly the same order as any other governed request.

Environments and fleets

Environment is part of identity, not a label. The same agent name on staging and production is two records with two credentials and two sets of permissions, so a boundary proven on staging is promoted deliberately rather than inherited by accident.

On the Agency plan, multisite fleets are governed from one console while each site keeps its own identities, permissions, decisions, and audit chain. A fleet view is a way to see and reuse standards — it is not a way to act on a site from outside its own authority.

See the agency solution

Registering your own Abilities

If you maintain a plugin, registering Abilities is how you make it governable. Declare what may be requested, describe the input and output, and let WordPress authorization and agent policy remain separate gates that you do not implement yourself.

• Name each Ability for the action it performs, not for the feature it belongs to.
• Give real input and output schemas — classification, validation, and previews all read them.
• Keep the native permission check honest. It is the ceiling, and it is checked independently.
• Return enough detail for evidence. An outcome that cannot be verified is recorded as unverified rather than assumed.

Open the developer guide