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.
Incoming requestContent Agent wants to update “Release notes”acme/update-post · Production
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.
- 01IdentifyWho is acting?
- 02AuthorizeCan WordPress allow it?
- 03DecideAllow, approve, or block?
- 04ExecuteRun the exact request.
- 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
Content Agent
Production · Editorial operations
- WordPress user
- rulefence-content-agent
- Connection
- Healthy
- Session
- S-204 · active
- Agent state
- Restricted
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.
AllowLow consequence and explicitly permitted
Require approvalPublished content needs human review
SelectedBlockDenied, unconfigured, or outside policy
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
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.
acme/update-postOne attemptWordPress returned successPost #284 updated · 3 fields written
OutcomeCompleted and verified
- Agent
- Content Agent
- Ability
- acme/update-post
- Decision
- Approved once
- Result
- 3 fields updated
- Recovery
- Snapshot available
- Integrity
- Chain verified
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.
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.
Same path, every time
Connection starts the request. Governance decides the rest.
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.
