Choose a useful first agent authorization pilot

A small pilot is useful when it resolves a real uncertainty. Pick a question such as: can a reviewer understand one branch request without asking the agent to explain it again? Write down the present workflow, who performs the review, and where the team currently loses context. Avoid turning a first evaluation into a test of every tool the agent can access.

Gated’s controlled private preview covers one uniquely named GitHub branch at an exact existing commit in a selected non-critical repository. That scope can help evaluate request clarity, human review, execution evidence, and the effort of using a controlled route. It cannot answer whether broader repository or deployment operations are governed.

Use a repository your pilot owner can administer and inspect. Non-critical should describe the consequences, not just the repository’s name. Check whether creating a branch could trigger automation, notifications, or access to other services. Establish what those effects would mean before requesting a live write.

Choose an existing commit that the owner can verify and a branch name that is unique for the intended run. Assign a person to confirm the provider result. Agree who will handle any later cleanup through the team’s existing GitHub process; branch deletion is outside the supported Gated pilot.

• Name the repository owner, reviewer, and person responsible for uncertain outcomes.
• Record the policy requirement and the human passkey requirement for the chosen request.
• List independent credentials and tools available to the agent.

Policy, human approval, explicit execution, and provider readback are separate steps. Approval does not create a branch. Direct GitHub credentials can bypass Gated, and an instruction or project skill does not intercept every tool call. Put those limits in the team brief so everyone evaluates the same workflow.

Distinguish a runtime safe-mode rehearsal from a live provider write. A rehearsal can reveal confusing review steps, but it does not prove that the runtime performed a live GitHub operation. Preserve that distinction in every result you share.

Set an observation period and a few criteria before starting. Reviewers should be able to identify the exact target, distinguish approval from completion, and reconcile the provider state with the receipt. Record missing evidence as missing, rather than treating an absent error as success.

End with a decision to continue the same narrow evaluation, fix a specific issue, or stop. Joining the preview update list does not grant immediate pilot access. Use the downloadable brief to align your team while access and scope are reviewed.