What should a human actually approve?

“Let the agent continue” is a difficult request to review. It leaves the reviewer guessing which actions will follow and how far the permission extends. A more useful request describes one action against a specific resource with explicit inputs.

For a GitHub branch request, that means naming the repository, proposed branch, and exact existing commit. A reviewer can compare those details with the intended task before deciding whether to authorize it.

A policy decision, a human approval, and a successful provider operation answer different questions. Policy determines how the request should be handled. Approval records a person’s authorization. The execution result records the provider’s response.

Keeping all three visible avoids a common mistake: reading “approved” as proof that the action succeeded. It also makes a denial clearer, because a request should not quietly turn into an executable action after policy rejects it.

The approval should remain bound to the request the person reviewed. If the repository, branch, commit, or other material input changes, that is a different request and deserves a new decision.

In Gated’s narrow GitHub pilot, the reviewer checks the requested repository, branch, and commit before the passkey step. The goal is a specific authorization, not an open-ended endorsement of whatever the agent does next.

A careful approval screen cannot compensate for an agent holding a parallel credential that bypasses the controlled route. Review both the request and the authority available outside the workflow.

Use a non-critical repository for the pilot, record what happened after approval, and inspect failed requests as well as successful ones. The decision history should help a person explain the action later without reconstructing it from memory.