Approvals
Use Cloud Agents approvals to keep humans in control of sensitive or merge-capable actions without slowing every run to a crawl.
Approvals are the governance layer of Cloud Agents. They let automation move work forward quickly while keeping sensitive final decisions in human hands.
What Approvals Are For
Approvals are most useful when the cost of an incorrect automated action is materially higher than the cost of a short review pause.
Examples:
- merging or finalizing a change
- acting on a run that touches protected paths
- accepting an execute run on a repository that uses strict validation policy
The exact approval types available can vary with repository configuration and rollout, but the visible interface shows the product principle clearly: automation prepares; people authorize.
Approval Workflow
When a run hits a gated step, the UI can present a pending-approval panel directly on the run page with:
- the approval requirement label
- explicit Approve and Reject actions
- an expiration timestamp
This makes approval an operational checkpoint, not a hidden side effect.
Why Approvals Matter
Separation of duties
The person or system preparing a change does not need to be the same actor authorizing it.
Risk-based control
Low-risk work can move faster, while higher-risk actions can stop for a deliberate decision.
Merge discipline
Approval gates help teams keep merge authority aligned with repository ownership and release practice.
Approve vs Reject
| Action | Use it when... |
|---|---|
| Approve | The run output is acceptable, the scope matches intent, and repository rules were respected. |
| Reject | The run solved the wrong problem, exceeded scope, or produced output that should not continue. |
Rejecting a run is not a failure of the system. It is part of the control model.
What to Inspect Before Approving
Always inspect the associated run first:
- Open the run from Runs or Approvals.
- Read the Timeline to understand what the agent did.
- Review Findings or Artifacts depending on the run type.
- Confirm the repository and branch are correct.
- Check whether protected paths or validation steps were involved.
Approval Expiration
Approvals are time-bound. The UI displays an expiration timestamp so a stale decision does not sit forever while repository state moves underneath it.
This is operationally important because:
- repository state changes
- pull requests change
- assumptions go stale
If an approval expires, restart from fresh context rather than treating the original decision as still valid.
Approval Policy and Repository Rules
Approvals do not replace repository policy. They work with it.
| Repository rule | Approval effect |
|---|---|
| Protected paths | Increases the likelihood that sensitive changes stop for human review |
| Validate after execute | Adds a checkpoint before approval is considered sufficient |
| Auto execute | Determines whether execute work can proceed automatically before a gate |
See Repositories for the policy layer behind these checkpoints.
Good Approval Practice
- keep approvers close to repository ownership
- approve based on run evidence, not summary text alone
- reject when scope is wrong, not only when code is bad
- use approvals to accelerate safe work, not to recreate a manual queue for every single action
If every run always needs approval and every approval needs a long manual investigation, the issue is usually repository policy or agent scope, not a lack of approvers.
Related
Runs
Inspect run evidence before approving or rejecting.
Repositories
Tighten or relax repository rules that influence approval frequency.
Responsible AI
Review the broader governance posture behind automated decisions and high-trust workflows.
Chat & Dispatch
Improve prompt scope so fewer runs stop for avoidable approval concerns.
How is this guide?