One governed request path

One request enters.
Five explicit gates decide what happens next.

RuleFence places identity, WordPress authority, permission, policy, approval, execution, evidence, and recovery in one visible path.

WordPress stays authoritative Evidence stays local
Managed request · RQ-1048 Control path active
CA

Incoming requestContent Agent wants to update “Release notes”acme/update-post · Production

Review
01IdentifyAgent identity verified
02Authorizeedit_post confirmed
03DecideApproval required
04ExecuteHeld until approved
05VerifyNot yet run

The governing sequence

The request earns each next step.

No connection, credential, role, permission, policy, or approval can silently skip the rest of the path.

  1. 01IdentifyWho is acting?
  2. 02AuthorizeCan WordPress allow it?
  3. 03DecideAllow, approve, or block?
  4. 04ExecuteRun the exact request.
  5. 05VerifyWhat actually happened?

01 Identify

Managed identity first

Know the agent before judging the action.

A request is attached to one managed agent, one purpose, one environment, and one dedicated WordPress user. Paused, revoked, or unhealthy agents stop here.

  • Agent state and intended purpose
  • Credential and connection health
  • Active session and environment
How managed identity works
Request identityVerified

Content Agent

Production · Editorial operations

WordPress user
rulefence-content-agent
Connection
Healthy
Session
S-204 · active
Agent state
Restricted
Identity gate passed01 / 05
Native authorizationPassed

Requested Abilityacme/update-postPost #284 · Production

Ability is registeredExample plugin · Write operation

User capability is presentedit_post on resource #284

Resource is availablePost exists and accepts updates

Governance cannot grant what WordPress denies.

02 Authorize

WordPress remains the ceiling

Native authority is checked before agent permission.

The live Ability registry, the mapped WordPress user, the requested resource, and native capability checks decide whether the request may continue. Governance can only make access stricter.

A connection is never authority. Being able to reach WordPress does not mean an agent may perform the requested action.

03 Decide

Permission plus context

The smallest safe decision wins.

The agent’s explicit Ability decision is evaluated with risk, policy, scope, environment, and preview coverage. Anything uncertain becomes stricter—not more permissive.

AgentContent Agent
+
Abilityacme/update-post
+
ContextPublished post

AllowLow consequence and explicitly permitted

Require approvalPublished content needs human review

Selected

BlockDenied, unconfigured, or outside policy

Why this decision: Production content is already published and the requested change affects public copy.
Approval is bound to the exact request. Inputs are canonicalized and fingerprinted; approval expires and cannot be replayed for altered inputs.

Human judgment inside gate 03

Review consequence—not a vague permission prompt.

The reviewer sees the agent, Ability, risk reasoning, bounded input summary, expected change, and available preview. They approve once, reject, or let the request expire.

  • One-time, expiring decision
  • Exact request fingerprint
  • Honest preview coverage
Approval · AR-0314Waiting
CA
Content Agentacme/update-post
Expires in 09:41
Expected changePreview complete
Current headingVersion 2.4 release notesProposed headingRuleFence 2.4: safer automation

04 Execute

The exact request only

Approval opens one narrow execution window.

Before execution, RuleFence rechecks agent state, native authorization, permission, policy, approval validity, emergency mode, and runtime health. A changed request returns to the decision path.

No blanket elevation Approval permits this canonical request once. It does not grant a broader session capability.
Execution gate · EX-1048 Eligible
Identity unchanged
WordPress authority passed
Permission and policy passed
Approval claimed atomically
Executingacme/update-postOne attempt

WordPress returned successPost #284 updated · 3 fields written

Evidence receipt · EVT-0512Verified

OutcomeCompleted and verified

Agent
Content Agent
Ability
acme/update-post
Decision
Approved once
Result
3 fields updated
Recovery
Snapshot available
Integrity
Chain verified
Signed into the local evidence chain

05 Verify

Evidence closes the loop

Record the decision and the actual outcome.

The evidence receipt separates what was requested, what governance decided, what WordPress executed, and what could be verified afterward. Redacted events are linked into a local integrity chain.

Outcome evidence, not marketing certainty. RuleFence reports what the installed environment can prove and names coverage limits honestly.

The boundary continues

Recovery and emergency control use the same rules.

Execution is not the end of governance. Supported recovery is re-authorized, and emergency controls can immediately make every managed path stricter.

Supported recovery

Undo only where a real recovery path exists.

Capture bounded before-state for supported writes, recheck eligibility at restore time, claim the snapshot once, and audit the attempt.

Snapshot S-1104Available3 supported fields · 27 days remaining

Emergency restriction

Stop new managed execution without weakening evidence.

Pause an agent, revoke sessions, suspend a connection, or enable emergency mode. Existing evidence remains readable and every control change is audited.

Emergency modeNew executions blockedApprovals remain visible · audit active

Same path, every time

Connection starts the request. Governance decides the rest.

01Identify
02Authorize
03Decide
04Execute
05Verify

Every failed or uncertain gate stops the request or makes the decision stricter.

Start with one visible boundary

See the path before you grant access.

Connect one agent, choose one safe Ability, and keep every later step explicit.