Gated · · Engineering checklist
An approval button is only one part of the boundary. This checklist is a design and review aid, not a security certification. For background, read AI agent permissions versus API keys.
Identify the operation
Name the action in provider terms. “Fix the repository” is a goal; “create this branch at this commit” is a reviewable operation. Separate read access from write authority.
Pin the target and payload
Review the repository, environment, branch name and full commit SHA. If any of these change, treat it as a new request rather than reusing the old approval.
Inspect the route to the provider
List credentials the agent can reach through environment variables, shell tools and other connections. An independent provider credential can bypass an approval tool. Instructions alone do not remove that route.
Check who may approve
Confirm the reviewer is authorized for this workspace and action. A passkey verifies a person’s confirmation; the executor still has to bind it to the specific reviewed request.
Bound time and reuse
Check when the request expires and what happens after revocation. Retry the same request through its supported idempotent path; do not create fresh requests just because a response was lost.
Decide what evidence is sufficient
Keep the policy decision, human approval, provider response and readback separate. A timeout is an uncertain outcome until you inspect the resulting provider state.
Worked example: one GitHub branch
Illustrative only: a coding agent asks to create gated/review-example in example-org/sandbox at an exact existing commit. The reviewer inspects the full SHA and branch name. Changing the repository, branch or SHA invalidates the premise of that review.
- Before execution
- Record the request, policy outcome and any required approval. Check that the executor will use only the reviewed target and payload.
- After execution
- Read the branch reference from GitHub and compare its commit with the reviewed SHA. A policy “allow” or a successful approval alone does not establish that the branch exists.
- If the response is lost
- Inspect request status and provider state before attempting another write. Keep the outcome marked uncertain until the evidence resolves it.
Where Gated fits today
The private preview focuses on creating one uniquely named GitHub branch at an exact existing commit in a selected non-critical repository. It does not automatically intercept every agent tool. Independent provider credentials remain outside the boundary. Merge, force push, deletion and production deployment governance are not verified pilot capabilities.
Review GitHub requirements · Read the security boundaries
Want to evaluate this workflow?
Join the waitlist for private-preview updates. Joining does not grant immediate access or commit you to a purchase.