Approvals workflow

Before testing an approval

Use a supported reviewed sandbox write and an allowed resource. Have two different active administrators available: one identity can initiate the workflow, and a different administrator must make the approval decision. A requester cannot approve their own action.

Choose Require another administrator for the configurable write decision and make sure no other guard denies the request first. Production writes are blocked by the current execution boundary, so they are not a suitable way to test the approval lifecycle.

How approvals work

When a supported request needs approval, the agent receives an approval-required response and no upstream action runs. A different administrator reviews the exact action in Approvals. Self-approval is rejected; approval does not automatically resume execution.

Exact approvals

Approvals are precise. They bind the requesting identity, the specific action and arguments, the schema and policy version, the resource set, and an expiry. An approval for "create issue in PROJECT-A" does not authorize "create issue in PROJECT-B."

Review pending approvals

Manage the approval queue from the admin workspace.

1. Go to Approvals in the admin sidebar.
2. Open the connection review and inspect the requester, tool, resource, argument digest, policy and schema versions, and expiry.
3. Choose Approve exact action or Deny action. After approval, ask the requester to retry the identical request before expiry.

Approval expiry

Grants are time-limited and consumed for the approved action. Expiry, changed arguments, policy or schema versions, membership, or other bound context require a new review. Never blindly retry a write whose execution outcome is uncertain.

Walk through an exact retry

For example, a sandbox client requests a reviewed create-ticket action for an allowed fixture resource. Durin returns approval-required and records the request without dispatching the write.

1. The reviewer opens the pending request and checks the requester, tool, resource, argument digest, versions, and expiry.
2. If appropriate, the reviewer chooses Approve exact action. This creates a bounded grant; it does not send the request upstream.
3. The requester retries the same tool call with the same arguments while the grant and its bound context remain valid.
4. Both parties inspect the execution outcome. A granted approval by itself is not a successful action.

When a request needs a new review

Changed arguments, a changed tool or policy version, expiry, or a change in the bound authorization context can make a grant unusable. Submit the intended request again and obtain a new review when the previous exact context no longer applies.

Do not edit a resource name or retry with broader arguments and expect the old grant to cover it. A denied request or consumed grant is not a reusable general permission for that tool. If the outcome of a dispatched write is uncertain, first check the upstream system before creating another potentially duplicate action.

Keep review evidence specific

Use the request’s identifiers, resource, argument digest, versions, and timestamps when discussing a review. Metadata lets the reviewer bind a decision to the exact action without assuming that an audit record contains the entire original payload.

Connection readiness review and exact action approval are separate decisions. Approving installation setup does not grant all later writes, and granting one action does not enable an unreviewed tool or bypass membership and credential checks.