Approval

Request waiting for approval

The request is held. Nothing has run and nothing will run until an approval is created and claimed, so there is no clock forcing a hasty decision.

  • Approvals
  • 5 min read

What you are shown

  • Agent — which managed identity, in which environment.
  • Ability — the exact registered name.
  • Redacted input preview — the arguments, safe to read.
  • Classification — action, risk, reversibility, scope, bulk, exposure.
  • Target — what would be affected, and whether it is public-facing.
  • Fingerprint — the digest this approval will be bound to.
  • Expiry — when the request lapses, and the exact retry guidance if it does.

Where the Ability supports it, a preview of what the write would do is shown before it happens. Read that before anything else; it answers the real question more directly than the classification does.

What to ask

  1. Is this consequence acceptable right now? Not in general — now, on this object, in this environment.
  2. Does the input match the purpose? Compare it to the agent’s written purpose. A drafting agent asking to update a published page is worth a pause.
  3. Is it reversible? If not, you are making a permanent decision on someone’s behalf.
  4. Is anything about it unusual? Volume, timing, an unfamiliar target. Unusual is not wrong, but it is worth a question before it is worth an approval.

If you are not sure

Reject it. Rejection is not destructive: the agent can request again, and you will have the record of both the request and your decision. An expired or rejected request costs one retry; an approved one you did not understand can cost considerably more.

Nothing degrades while you think

A held request has changed nothing. Taking ten minutes to check with whoever owns the content is a completely reasonable use of the control.

After you approve

The agent must retry. The approval authorizes one execution of the exact reviewed request; it does not trigger it. If the agent never retries, the approval expires and nothing happens — which is the correct outcome, not a fault.

Approvals

Keep the boundary while you fix the problem.

A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.