Policies and assignment

A policy defines part of an agent’s delegated authority. Reuse a policy across agents when they need the same control, and combine policies when an action is subject to several boundaries.

Scope, rules, and fallback

Scope determines which requests a policy evaluates. Rules determine the effect for matching requests. A rule combines conditions with Allow, Require approval, or Block, plus a reason.

All applicable assigned policies contribute. A matching Block wins over Require approval; Require approval wins over Allow. Rule order does not make an Allow override a Block.

If no rule matches across the applicable policies, the agent’s When no policy matches setting decides. This includes requests for which no policy applies. New agents default to Allow; choose the fallback deliberately.

Drafts and publication

A draft is editable. Tests and simulations let you explore its behavior before it affects agent requests. Publishing creates an immutable version.

Assign a published policy on the agent’s page and save. Thereafter, publishing an updated version applies it to new decisions for assigned agents. You do not need to remove, re-add, or re-save the assignment.

Previously resolved decisions retain their original policy evidence. A retry with the same logical request and idempotency key does not re-evaluate under the newer policy.

Review the impact of changes

Before publishing, check the affected agents, changed test outcomes, approval group requirements, and any counters that will restart. A shared policy change can affect every agent assigned to it.

A policy name or threshold edit can preserve accumulated usage. Changing what a counter measures or which activity it includes can restart that counter. The review screen identifies these changes.

Follow Configure a policy for the authoring workflow and Usage limits for cumulative controls.