=== RuleFence - AI Agent Control ===
Contributors: wpagentmanager
Tags: ai, agents, abilities, mcp, security
Requires at least: 7.1
Tested up to: 7.1
Requires PHP: 8.0
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Control and govern AI agents that use WordPress Abilities.

== Description ==

RuleFence is the control room for AI agents working on your WordPress site. It gives every agent an identity, decides what that identity may do, asks a human before anything risky, and keeps a signed record of all of it.

It governs the WordPress Abilities API, so it covers whatever your plugins register - core, WooCommerce, your own - rather than a fixed list. That also sets the scale: a site whose plugins register a lot of Abilities has a lot for this to govern, and a site with none has little. WordPress 7.1 itself registers three, all read-only.

Abilities are what it governs, and that is worth being exact about. An agent's credential is a WordPress user, so anything that user could already do through the ordinary REST API, it still can - the permission matrix is not in that path. What limits it there is the WordPress user you map the agent to, which is why this plugin asks for a least-privilege one, warns you when an agent is mapped to an administrator, and scores it in Readiness. WordPress capabilities are the ceiling; the matrix is how you carve out what an agent may do underneath it.

= The rule everything else follows =

An Ability nobody granted is refused. A new agent starts paused and is allowed nothing, and stays that way until you say otherwise, one Ability at a time. Nothing you install can widen that by accident, because nothing widens it except you.

= What it does =

* **Identity.** Each agent is a managed identity with its own credential, mapped to a least-privilege WordPress user. You can see which agent did what, not just which user.
* **Permissions.** A matrix of every registered Ability against every agent: allow, require approval, or block.
* **Approvals.** A risky request stops and waits for a person. The approval is bound to the exact input it was granted for, so it cannot be reused for a different request.
* **Risk.** A contextual engine reads the request itself - how many records, how large a change, how sensitive - and can make a decision stricter than the matrix, never weaker.
* **Previews.** See what a write would do before it happens.
* **Activity and audit.** Every decision is recorded with its reason, allowed or blocked, in a hash-chained trail that can prove it has not been edited.
* **Emergency controls.** Stop every agent on the site immediately, or drop everything to read-only, in one click.
* **Readiness.** A scored check of what still weakens the site, with the evidence behind each score.
* **Runtime verification.** The governance controls are re-tested on the installed site rather than assumed.

= What this plugin is, and what a separate add-on adds =

Everything above is this plugin. There is no licence key, no edition, and nothing in it that a payment unlocks - what you install is what you get, working, for as many agents as you care to run.

A separate paid add-on, RuleFence Pro, is available from rulefence.com and adds workflows, conditional policies, undo and rollback, scheduling and email alerts, approval routing, rate ceiling tuning, audit export, custom retention, saved activity views, reusable agent and permission profiles, and configuration transfer between sites. A further tier adds multisite fleet governance. It is a second plugin you install alongside this one; nothing about it is present here.

That is worth being plain about, because the two arrangements look similar from outside and are not. This plugin does not ship the paid features in a disabled state. The screens have no buttons that exist to tell you what something would cost, and no control is switched off waiting for a key.

What is never sold, in this plugin or that one: default-deny, human approvals, the signed audit chain, audit logging, secret redaction, emergency mode, WordPress capability checks, failing closed when audit integrity is unavailable, and session expiry. A security control that only works if you pay is not a security control.

= External services =

This plugin contacts nothing, ever. There is no analytics call, no version ping, no licence check and no webhook. Your agents, permissions, decisions and audit trail live in your own database and are never sent anywhere.

The two features that could make an outbound request - webhook notifications, and validating a licence key - both belong to the paid add-on. Neither is here, so there is no code in this plugin that could make a request even if something asked it to.

Agents reach your site from outside it, over the REST API, using an Application Password you issue and can revoke. That is inbound, and it is what the plugin exists to govern.

== Installation ==

1. Upload the `rulefence` folder to `/wp-content/plugins/`.
2. Activate RuleFence.
3. Activation opens a guided setup that walks you through the environment check, your first agent, what it may do, and its credential.

You can reopen setup any time from RuleFence > Settings > Run setup again. The full written guide is in `docs/SETUP.md`.

WordPress 7.1 or later is required, because governance relies on the native Abilities execution lifecycle that 7.1 introduced.

= After setup =

A new agent starts paused and is allowed nothing. That is deliberate: every ability is blocked until you grant it in Abilities > Permissions. Grant a read ability first, watch it in Activity, and only then grant a write.

== Frequently Asked Questions ==

= Do I need a separate WordPress user for every agent? =

Use a dedicated least-privilege WordPress user for each security boundary you need to isolate. An agent is a separate RuleFence identity, but its Application Password still inherits the mapped WordPress user's native REST capabilities. Do not map an untrusted client to an administrator.

= My agent is blocked from everything. Is it broken? =

No, that is the default. Governance fails closed: an ability nobody granted is refused. Grant the specific ability in Abilities > Permissions.

= Where is the Application Password shown? =

Once, when the connection is created. It cannot be retrieved afterwards. If it is lost, revoke that connection and issue another.

= I installed it and there is almost nothing in the Ability Explorer. Is it working? =

Yes, and this is worth understanding before you judge it. WordPress 7.1 registers three Abilities of its own, all read-only: core/get-site-info and core/get-environment-info need an administrator, and core/get-user-info needs only a logged-in user. So on a site with no other Ability-aware plugins there is very little for an agent to do and very little to govern. Install WooCommerce and the list grows immediately, including writes with previews and captured before-states behind them.

There is a wrinkle in the meantime. An Editor mapped to an agent can reach only one of the three, while still being free to write posts through the ordinary REST API, which the permission matrix does not cover. On a stock site the safest mapping and the useful one are not yet the same thing. That is WordPress's design rather than this plugin's, it improves as plugins register Abilities with sensible capabilities, and it is the reason the Readiness screen scores your mapping instead of assuming it.

= Does it control everything an agent can do? =

It controls every Ability an agent invokes, which is what an AI client uses to work with your site. It does not sit in front of the ordinary WordPress REST API: a credential is a WordPress user, and that user's own capabilities decide what it can reach there. So map agents to a least-privilege user and keep it that way - the Readiness screen scores this, and the connection screen warns you if you point one at an administrator. The Activity trail records every Ability decision, and outside the Abilities API it records what a managed credential changed or was refused - so a change made through an ordinary REST route still appears, attributed to the agent that made it. Successful reads there are not kept one by one, because the trail is capped and a read-heavy client would crowd out the decisions.

= What happens if an agent is compromised? =

Revoke its connection in Agents > Connections, or stop everything at once with Settings > Emergency mode. The record of what it already did stays intact and signed.

= Does anything leave my site? =

No. Agents, permissions, decisions and the audit trail are stored in your own database, and this plugin makes no outbound request of any kind - there is no webhook code in it to configure.

= Which features need the paid add-on? =

As many agents as you want, and everything on the governance side, are here: default-deny permissions, approvals, the signed audit trail, risk assessment, emergency mode, the readiness checks and runtime verification. The add-on sells automation and convenience - workflows, policies, undo, scheduling, export. No security control is ever sold; a control you have to buy is not a control.

You do not need the add-on to use this plugin, and nothing here stops working without it.

= Does the plugin include an AI model, or send anything to one? =

No. It governs agents that connect to your site; it is not one, and it does not talk to any model. The AI client is whatever you connect - Claude, ChatGPT, a script of your own.

= Can it undo what an agent did? =

This plugin captures the before-state, so the evidence of what changed is kept whether or not you ever undo it. Performing the undo is in the paid add-on.

Not everything is reversible either way, and the plugin does not claim otherwise - the Ability Explorer tells you which Abilities are covered before you grant one, so you know what a grant is worth before you make it.

== Screenshots ==

1. The permission matrix: every registered Ability against one agent, set to allow, require approval, or block.
2. The activity trail: every permission decision recorded with the reason it was allowed, blocked, or sent for approval.
3. The approval queue: what a request asked for, how risky it is, and how long there is to decide before it expires.
4. Readiness, scored, with the evidence and the recommendation behind each check.
5. Guided setup: six short steps, beginning with whether the site can govern an agent at all.

== Changelog ==

= 1.0.0 =
First public release.

* Every agent is a managed identity with its own credential, mapped to a least-privilege WordPress user.
* A permission matrix over every registered Ability: allow, require approval, or block. An Ability nobody granted is refused.
* Approvals are one-time and bound to the exact input they were granted for, so one cannot be reused for a different request.
* A contextual risk engine that reads the request itself and can only make a decision stricter, never weaker.
* Previews of what a write would do, before it happens.
* Every decision recorded with its reason in a hash-chained audit trail that can prove it has not been edited.
* Emergency controls that stop every agent, or drop the site to read-only, immediately.
* Readiness scoring and 31 runtime verification checks that re-test the governance controls on the installed site rather than assuming them.
* Guided setup that ends with the readiness score for the agent it just created.

Development before this release was internal. No build older than this one was ever distributed.

== Upgrade Notice ==

= 1.0.0 =
First public release. Nothing to upgrade from.
