Approval gate for sensitive actions

What you need for this exercise

Prepare a sandbox connection with a reviewed write tool, an allowed resource, and a current usable credential. Have a requester and a different active administrator available to review. Choose a simple action whose result can be checked directly in the sandbox.

This recipe verifies independent approval for one exact request. It does not establish a permanent grant for a tool, and it cannot override the production write denial. Keep a record of the initial request and its outcome so an uncertain write is not accidentally repeated.

When to use approval gates

Use approval gates for supported reviewed writes that need another administrator’s decision. Validate this workflow in the sandbox. A grant cannot override the production write denial or make an unreviewed tool executable.

Configure the gate

Configure the workspace write decision and verify the exact-request lifecycle.

1. Choose a reviewed sandbox write and an allowed resource.
2. Set the configurable Write decision to Require another administrator and publish it.
3. Have a different active administrator available to review the request.
4. When an agent invokes a gated tool, the request enters the approval queue.
5. The administrator checks the bound request and argument digest, approves or denies it, and the requester retries the exact approved action.

Best practices

Use the audit log to inspect approval decisions and execution outcomes separately. A connection review is not a blanket execution grant, and an exact approval does not resume a request by itself.

Confirm the request stops before execution

With Require another administrator selected, submit the chosen sandbox write once. The expected result is approval-required, and the action should be waiting for review rather than appearing as completed upstream.

If the result is denied, inspect the failed guard before looking for an approval. A membership, resource, credential, or tool-review denial cannot be repaired by an approver granting the request. If the write proceeds immediately, check the current policy and the identity or environment used for the exercise.

Approve, retry, and inspect the outcome

The reviewing administrator should confirm the requester, tool, resource, argument digest, policy and schema versions, and expiry. After Approve exact action, the requester retries the identical call before the grant expires.

1. Confirm that granting approval alone did not run the action.
2. Retry the original call without changing its arguments or target resource.
3. Inspect the execution outcome and the corresponding sandbox result.
4. Check that a changed request requires a new review rather than reusing the old grant.

Exercise a refusal as well as an approval

Repeat the workflow with a new request that the reviewer denies, or allow a separate test request to expire. Verify that the requester cannot turn that decision into a blanket permission by repeating the original call.

Treat each test as a distinct action with a known outcome. If a provider operation may already have completed, stop and investigate that outcome before attempting another write. The approval queue explains authorization; provider evidence explains whether the requested change happened.