An API key is not a task boundary.

API keys, OAuth tokens and GitHub App credentials are not just identity labels. Providers can attach scopes, repository selections, expiration and other restrictions to them. Those controls matter. But a provider permission often covers a class of operations, while a person intends one specific operation.

For a coding agent, “work on this repository” is ambiguous. Reading code, creating a branch, deleting a branch and merging a pull request have different consequences. A broad credential should not silently turn one request into authority for all of them.

Consider a request to create a new branch at an existing commit. A useful authorization decision identifies the agent, the repository, the exact new branch name, the exact commit and the environment. It can return allow, deny or require human approval for that request.

This is a conceptual example, not a public API schema. Permission for this request should not imply permission to choose another commit, delete a branch or merge a pull request.

1. Policy: evaluate the specific request and record the reason for the decision.
2. Approval: when required, let a human inspect the action and target before confirming. A passkey verifies the approval ceremony; the system must still bind approval to the reviewed request.
3. Execution: let a trusted executor perform only the authorized operation, using appropriately scoped provider authority.
4. Evidence: record the provider outcome and read back the resulting state. “Approved” and “executed successfully” are different facts.

A useful design also bounds reuse: an approval should not become a reusable permission slip for unrelated requests. Replay protection and revocation belong in the controlled path. An uncertain provider result should remain uncertain until evidence resolves it.

An agent can query policy before attempting work. That helps it choose an allowed route or request approval. But advice returned by an MCP tool cannot, by itself, stop another tool or a shell command from using an independent credential.

The practical test is simple: can this agent reach the provider without the enforcement point? If it can, that route remains outside the boundary. Review credentials available through the environment, local tooling and other connected services. A project instruction to use the approved tool is useful guidance, but it does not remove alternate authority.

Gated’s private preview focuses on one narrow GitHub operation: creating a uniquely named branch at an exact existing commit in a selected non-critical repository. The controlled path combines policy checks, passkey approval when required, server-held GitHub App authority, execution evidence, replay protection and revocation.

Claude Code and Codex use explicit skills and CLI routing in the preview. They do not automatically route every action through Gated. Independent provider credentials can bypass it. Pull-request merge, force push, branch deletion and production deployment governance are not verified pilot capabilities.

Read the preview guide, GitHub operation and requirements, developer model and security boundaries before evaluating a pilot.

Is a narrowly scoped provider token enough?

It may be enough when its permissions precisely match the task and your risk tolerance. Add an action-level boundary when you need narrower targets, conditional approval or a clear record linking the decision to the operation.

Does every action need a human click?

No. Policy can allow routine actions and require approval for selected requests. The important property is that the executor obeys the decision for the exact request.

Does a successful approval prove the action happened?

No. Approval establishes permission. Execution evidence and provider readback establish the outcome.