Tool access isn’t permission for every action

An agent may need repository access to complete a task, but the task rarely requires every action that the credential permits. Reading an issue, creating a branch, and deleting a protected branch are different operations with different consequences.

A service credential describes authority the service will recognize. It does not necessarily describe the narrower authority a human intended to give an agent for one task. That gap is where action-level permissions become useful.

A concrete request includes who is asking, what they want to do, which resource they will touch, and the relevant environment. A policy can then return allow, deny, or require approval from that context.

For example, a team might allow a read while requiring a person to review a sensitive write. These are examples of a permission model, not a claim that every tool or provider already has an enforced integration in Gated.

Returning DENY is only meaningful as a control if the execution path respects it. A trusted integration must receive the request, evaluate it, and enforce the result before using provider authority.

If the agent can use an independent API key, local process, or network route to perform the same action, that alternative path is outside the boundary. Gated does not automatically intercept every action an agent takes.

We’re developing Gated around explicit requests, scoped authority, human review for sensitive actions, and decision records. The private preview is deliberately narrow: a GitHub branch workflow for a non-critical pilot.

A useful first step is to choose one action and write down its inputs, the policy that applies, who can approve it, and the path that executes it. If a team can explain that boundary precisely, it can also test where the boundary stops.