Policies
A policy says what workers may do with a tool: allow, notify, require approval or deny. The most specific policy wins.
EffectsLink to Effects
- Allow: the worker acts on its own.
- Notify: the worker acts, then tells people.
- Require approval: a person approves before it runs.
- Deny: never allowed.
Which policy winsLink to Which policy wins
The most specific scope wins: worker, then role, team and organization. Priority breaks ties within a scope. When a tie remains, deny wins. A call that no policy matches gets the default for its risk tier.
DefaultsLink to Defaults
Without policies, reads run, messages notify, merges and deploys need approval, and destructive actions are refused.
The pageLink to The page
Policies has two tabs: Rules and Simulator. Use the simulator to test which policy applies to a call. Only owners and admins can add, enable or disable a policy.
Checked against the product on 2026-10-05.
Was this helpful?
Related articles
- Risk tiersEach action has a risk tier: none, low, medium, high or critical. The tier and your autonomy mode decide whether a worker acts, acts and tells you, asks, or is stopped.
- Autonomy modesThe autonomy mode decides how much workers do before they ask you. Auto is the default: internal work runs at once, and outside or risky actions wait for you.
- ApprovalsActions that need a person wait in Approvals. An approver, admin or owner approves or denies each one, with an optional comment.