Control each request, one at a time.

Request context

Before anything is decided, the request is assembled into a complete, reviewable statement. Context is what turns “an agent wants to update a post” into a sentence a person can act on.

Identity

Which managed agent is acting, in which environment, using which connection.

Ability

The exact registered Ability being requested, not a category or a guess.

Input

The arguments the agent supplied, validated against the Ability’s schema.

Target

The object the action would affect, and whether it is public-facing.

Fingerprint

A stable digest of the request, so an approval can be bound to these inputs and no others.

Redaction happens on the way out

Sensitive input is redacted when a record is displayed or exported, not silently discarded when it arrives. The decision is still made against the real request; what a reviewer sees is a preview safe to read, alongside the fingerprint that proves which request it was.

Policy evaluation

Policy runs after WordPress has independently answered its own question. If native authorization already refused the action, evaluation does not continue — there is nothing for policy to permit.

Order of evaluation

1. Identity resolved. An unknown or revoked agent is refused here.
2. Ability recognised. An unregistered Ability has no permission record and is refused.
3. Native authorization. WordPress decides whether the underlying user may act at all.
4. Agent permission. The per-agent decision for this Ability: allow, require approval, or block.
5. Site mode. Read-only or paused overrides an allow for anything that writes.

Every step can only remove permission. Nothing later in the chain restores something an earlier step refused.

Risk shapes the default, not the answer

Classification informs what the interface recommends and what it asks you to confirm — allowing a high or critical risk Ability requires explicit confirmation and is recorded as an administrative decision. It does not decide for you. The permission matrix remains the single place the answer lives.

Human approval

Approval is the control you reach for when an action is acceptable but only with judgement attached. The request pauses, a person reads what would happen, and the decision is recorded against their name.

Approvals are bound and single-use

• Input-bound. An approval covers the exact request fingerprint that was reviewed. Changed arguments produce a different fingerprint and need a new decision.
• One-time. The approval is claimed atomically when it is used, so the same grant cannot be replayed for a second call.
• Time-bounded. Pending and approved requests expire on their own. An approval left unused does not become a standing permission.
• Attributable. Who decided, when, and on what evidence stays in the audit trail.

What a reviewer sees

The Approval Center presents the agent, the Ability, a redacted input preview, the classification, the target, and the exact retry guidance if the request expires. It is written to be read by the person accountable for the site, not by the person who wrote the integration.

Execution decision

The final gate turns everything above into one recorded outcome. The request is executed exactly as reviewed, refused, or held — and in every case the decision is written before the result is returned.

The distinction between refused and failed closed is worth keeping. The first is governance working as configured. The second means something about the installation needs attention — and the system chose not to act rather than act unrecorded.

Where to go next

• OperationsKeep outcomes inspectable

  What is recorded after a decision, and how you recover from one.

• FoundationsKnow the boundary

  Identity, WordPress authority, Abilities, and default deny.

• TroubleshootingA request stopped

  Find the gate that refused it before changing any setting.