Foundations

Know the boundary before you widen it.

Four ideas carry the whole control model: who is acting, what WordPress already allows, which Abilities exist, and what happens when none of that is certain. Learn them once and every later decision reads the same way.

Concepts
Applies to every plan
Read before granting access

Managed identity

An agent is not a user, and it is not an anonymous request. It is a managed identity: a named record that says which system is acting, what it exists to do, and which environment it belongs to. Every request RuleFence evaluates arrives attached to one of these records, or it does not proceed.

Identity is the first gate because nothing downstream can be answered without it. A permission decision is meaningless if you cannot say who the permission was granted to, and an audit record is unreadable if the actor is a shared credential.

What an identity carries

Name and purpose: Written in operational language, so a reviewer can judge a request without reading code.
Environment: Production, staging, or development. The same agent name in two environments stays two distinct records.
Connection: The Application Password the agent authenticates with. Identity and credential are linked but not the same thing.
State: Active, restricted, paused, or revoked. State is a control surface, not a status label.

Why the credential is not the identity

An Application Password can be rotated, suspended, or revoked without deleting the agent, and the audit history stays attached to the identity rather than to the credential. That separation is what makes a credential rotation a routine operation instead of a break in the record.

Practical rule

One agent, one purpose, one environment. Resist the shared “automation” identity: it produces an audit trail that cannot answer the only question that matters after an incident.

WordPress authority

RuleFence never grants an agent more than WordPress already allows. Native roles and capabilities remain the authority ceiling, and every governed request is checked against them independently of any policy you configure.

This ordering matters more than it first appears. It means the plugin can only ever narrow what is possible. Adding governance cannot accidentally widen access, and removing the plugin cannot leave behind a privilege an agent should not have had.

Two separate questions

Gate	Question	Owner
Native authorization	Can this WordPress user perform this action at all?	WordPress core roles and capabilities
Agent policy	Should this agent be permitted to do it right now, and under what review?	RuleFence

A native denial is final. No allow rule, no approval, and no emergency override changes it. When a request stops at this gate, the fix is a WordPress permissions question, not an agent policy question — and solving it by widening the underlying role is almost always the wrong answer.

Do not solve access by raising the ceiling

If an agent needs a capability its WordPress user does not have, decide whether that user should have it at all. Granting a broad role to unblock one agent hands the same power to everything else using that account.

Abilities

An Ability is a registered, named action that a system can request — acme/update-post, core/get-site-info, and so on. RuleFence discovers the Abilities registered on your site and treats that registry as the complete vocabulary of what an agent may ask for.

Abilities are what make governance legible. Instead of asking “can this integration write to my database,” you decide on a list of specific, named actions, each with its own input and output schema.

How each Ability is classified

Every discovered Ability is classified conservatively so that risk is visible before a decision is made, not after:

Action — read, create, update, or delete.
Risk — from low through critical, based on the consequence of a successful call.
Reversibility — whether the effect can be undone, and by whom.
Scope and bulk — whether one item or many are affected in a single call.
Exposure — whether the result is public-facing.

Where classification cannot be established with confidence, the Ability is treated as higher risk rather than lower. A conservative default costs you one approval; an optimistic default costs you an incident.

Unclassified is not unrestricted

An Ability the plugin cannot classify is still subject to default deny. It appears in the Ability Explorer with its evidence so you can make the call yourself.

Default deny

Nothing is permitted until you permit it. A newly registered agent can authenticate and can be seen — and can do nothing else. Every Ability starts blocked, and each one you open is a deliberate act with a name attached to it.

The three decisions

Allow: The agent may call this Ability without pausing, provided WordPress also allows it. Reserve this for work whose consequence you would accept unattended.
Require approval: The request is held and a person decides. The approval is bound to that exact request, not to the Ability in general.
Block: The request is refused before execution. Blocking is explicit and appears in the audit trail as a decision, not as silence.

Failing closed

Default deny is not only a starting state; it is the behaviour under uncertainty. If a permission record is unreadable, a schema is broken, or the audit trail cannot be written, the request is refused rather than executed unrecorded. An action that cannot be accounted for is an action the system declines to take.

What this buys you

The blast radius of a misconfigured or compromised agent is bounded by the list of permissions you consciously opened — not by everything its WordPress user could theoretically do.

Where to go next

Foundations describe the boundary. The next two pages describe what happens each time a request meets it.

Start with one useful permission

See the boundary on your own site.

No required AI API key. No per-call fees. Native WordPress authority remains the ceiling.

Download free Back to documentation