Find the gate that stopped the request.

The method

Every symptom below is handled the same way. The order is what keeps a small problem from becoming a permissions rewrite.

1. Capture the exact state. Agent, Ability, decision, timestamp, and request identifier. Copy them before you change anything — some of it will not survive your first edit.
2. Locate the stopping layer. Identity, native authority, agent policy, approval, or execution. The activity record names it.
3. Apply one bounded correction. Change only the setting the evidence points at.
4. Verify the outcome. Confirm both the decision record and what WordPress actually changed.

Agent not recognized

The request arrived without a resolvable managed identity, so evaluation stopped at the first gate. Nothing was executed.

Check in this order

• Agent state. A revoked or paused agent is refused by design. Confirm the state before assuming a fault.
• Environment. A staging agent calling production is a different identity, not the same one in a different place.
• Connection. Run a connection health test. A suspended or rotated Application Password stops resolving immediately — that is the intended behaviour of a rotation.
• Credential source. Confirm the calling system is sending the credential you think it is, and not a cached one from a previous rotation.

WordPress denied access

Native authorization refused the action. This is WordPress’ own answer, and no agent policy, approval, or plan can override it.

Separate the two questions

First establish whether the underlying WordPress user should be able to perform this action at all. If the answer is no, the agent has been asked to do something outside its remit and the integration is what needs changing.

If the answer is yes — the user genuinely holds the role and the capability — check that the capability applies to the specific object, not only in general. Object-level checks are the usual explanation for an action that succeeds on one post and fails on another.

Request blocked or paused

WordPress allowed the action and agent policy did not. The record names which decision applied.

Change one decision, then retry the original request. Changing several at once means the next result will not tell you which change was responsible.

Waiting for approval

The request is held. Nothing has run, and nothing will run until the approval is created and claimed.

Before approving

• Read the redacted input preview and confirm the consequence is one you would accept right now.
• Check the request fingerprint. An approval is bound to these exact inputs; if the agent retries with different arguments, it will need a new decision.
• Note the expiry. Pending and approved requests expire on their own, and an expired approval is not a failure — it is the control working.

Common outcomes

Approval not found

The agent retried with different inputs, or the approval expired. Review the new request on its own terms.

Already claimed

Approvals are single-use. A second call needs a second decision; this is what prevents replay.

Approved but still refused

Something later in the chain declined — usually site mode, or a native permission that changed after the review.

Outcome unverified

The request ran but the result could not be confirmed to the standard the record requires. Resist the urge to repeat the call.

• Check what WordPress holds. Look at the target object directly. An unverified outcome frequently means the action succeeded and the confirmation did not.
• Read the linked evidence. The activity record shows how far execution got and what was captured.
• Verify the audit chain. A verification failure is a different problem from an unverified outcome, and it needs attention on its own.
• Do not retry blind. Repeating a non-idempotent action to resolve an ambiguity is how one uncertain change becomes two real ones.

Execution needs recovery

An action ran and its effect is not what you wanted. Work from the record, in this order.

1. Stop the source first. Pause or restrict the agent, or switch the site to read-only, so the request cannot repeat while you work.
2. Identify exactly what changed. The outcome links to the objects affected. Recover those, not everything from that period.
3. Use WordPress’ own recovery paths. Revisions, trash, and restores apply normally — the plugin governs requests, it does not replace WordPress’ content history.
4. Narrow the permission before resuming. Move the Ability to approval or block. Returning an agent to service unchanged invites the same outcome.
5. Verify both sides. Content restored, and a decision record that explains why it will not recur.

When to escalate

Open a support request when the evidence contradicts the documented model — a verification failure you cannot explain, a decision that does not match the configured matrix, or an outcome the record cannot account for.

Bring the state you captured in step one: site and WordPress versions, plugin version, agent, Ability, decision, outcome, timestamp, and request identifier. A support conversation that starts with the request context skips the first day of questions.

Open support