Approvals and overrides

Which tool calls wait for a person, how a Team's cost threshold works, how an override replaces an inherited policy, and what a Package floor fixes.

Approvals

What agents may do → Actions that need a person to approve has three groups. Each is on in every policy unless you switch it off, so as soon as one enforcing policy applies to a run, these calls wait for a person:

Group	Covers
Send	App operations flagged destructive that are not deletes (send, share)
Write / update	API tool `POST`, `PUT` and `PATCH`; MCP tools that declare `destructiveHint: true`; Data Table `insert`, `update` and `upsert`
Delete	App `delete` operations and API tool `DELETE`

With no policy at all, nothing waits.

To add a call, set its tool to Needs approval under Tools & connections. Setting a tool to Allowed does not remove it from a group: only switching the group off does. Switching off a group that a parent policy keeps on is a loosening, and is refused at save.

What happens while a call waits

The run pauses and a review goes to the Organization's active Owners and Admins who hold workflow.review, by email and in-app. It is answered on the Reviews page, and appears as an approval card in the builder's test thread.

Answer	What happens
Approved	The call runs. An approval is good for that one call.
Rejected	The tool is not called, the model is told `policy_denied`, and the run carries on.
Not answered within 24 hours	The same as rejected. The decision is logged with severity `contained`.

Some runs cannot wait, so the call is denied and the Agent told:

Voice calls: a live call cannot pause.
Synchronous API requests: no caller can hold an HTTP request open for a review. Use the async API for runs that need approvals.

A monitor policy holds nothing: it logs that the call would have waited.

Known limits

A wait is held in process: a service restart while a run waits can lose the wait.
In a Team run, a lead's own tool call that needs review cannot be reviewed and is denied.
After a rejected call, the model is told the call was not performed and the run adds a policy notice, but the reply is still the model's own wording: check the run's decisions. Workflow steps and structured-output Agents get no notice.

A Team's cost threshold

The Human-in-the-loop approval setting in the Team builder is a rule too (capability.cost_threshold_approval), kept in a policy the platform manages, named Team approval threshold. It shows a SYSTEM badge in the list and is read-only there: change it in the Team's approval settings. When several policies set a threshold, the lower one wins, and reviewers are combined.

Overrides

Enterprise. An override lets one Agent, Team, Workflow or Project run under a substitute policy in place of exactly one policy it inherits. It is the one way to loosen an inherited rule, and it is deliberately visible. On Community the inherited, stricter policy always applies.

Create the substitute: a policy of the same scope as the object or Project, with its rules. It applies only through its override, so it is not attached as an ordinary policy.
On the object's Policy tab, choose Override…. Pick what it Replaces and what it applies With.
The dialog shows what the override loosens (old value to new), what still applies, and the Package floor check.
Give the required reason and attach.

Rules of an override:

It needs policy.override_parent (Owner and Admin by default).
It replaces one policy for that scope only. Everything else in force keeps applying, and the replaced policy stays in force everywhere else.
A Project's override can replace an Organization policy. An object's can replace an Organization, Project or Package policy.
A substitute with no active version replaces nothing yet.
It is refused if it would go below a Package floor (override_below_floor).
It is visible on the object, in the policy list and in run traces, and attaching or removing it writes an audit event with who, what and why. The evidence export includes the override history.
After a downgrade to Community an override on record is shown as inert and the inherited policy applies.

Remove override on the object's banner puts the inherited policy back.

Switching detection off on one object

With an override in place on an Agent, Team or Workflow (not a Project), the override can also switch detection off for that object. Non-floor data rules then do not apply and neither does the default redaction. A Package floor's data rules and the credential default still apply. The switch writes an audit event.

Package floors

A Package can bring its own policy through policy_set. Install creates a Package policy and attaches it to every Agent, Team and Workflow the install created; it cannot be attached to anything else by hand.

Its floor is fixed by the Package. It is applied last, in enforce mode, whatever the Package policy's status or mode, so archiving the policy, switching it to Monitor, editing it or overriding it never goes below the floor. The floor holds while the Package is installed. The object's Policy tab shows it in a locked card.

A Package whose floor needs an Enterprise capability is refused on Community at install, with PKG_MISSING_CAPABILITY.