Approvals and policies

Policies decide what an AI session may do on its own and what needs a person. Approvals are where that person says yes or no. Both are recorded in the audit log and in the change's evidence pack.

Workspace policy

Open Secure → Policies. The page shows whether the policy is Enforced or Log only, the trust posture, the rules in effect, the version, and recent decisions. Owners, admins and security admins can edit it (the policy-manage permission).

Trust posture

The posture applies when no rule matches. Whatever the posture, a session's code change still needs an approved review before its pull request opens (see Approvals below).

Rules

Each rule has an action, a decision (allow, ask or deny) and an optional resource pattern. The strictest matching rule wins: deny beats ask, ask beats allow.

Protected paths are diff.apply rules with a file pattern. They are checked when a pull request is opened, against every file the change touches; the session still writes the change. Automatic deploys after a merge are release.deploy rules. An action that can't wait for a person can't use ask; the editor refuses it.

Choose Edit rules to change the posture and the rules, then save. Each save creates a new version and an audit entry. Switch to log only keeps evaluating rules and records what they would have done, without blocking anything. That is useful while you tune a new policy.

Approvals

An approval request is opened for you when:

• a session produces a code change (every change needs review, whatever the posture);
• a session start hits an ask rule (the session waits as held until the request is decided);
• a pull request is requested for a change that needs review and has none yet.

Open Review & Gate → Approvals. Pending requests lists each request with how many approvals it needs and when it expires. Choose Review the proposed changes to see the diff, then Approve (an optional note) or Reject (a reason is required). The run page has the same decision as Accept changes and Reject.

Who can approve

Owners, admins and security admins can approve by default; a custom role can be given the permission too. A request can also name specific approvers.

The person who launched a session can't approve its change when anyone else in the workspace can. A solo team can still approve its own work. Rejecting is always allowed.

Rules of the decision

• A code-change review needs one approval, from someone other than the person who launched the session (when the team has someone else who can approve). That makes it a two-person rule. Approvals are counted per distinct person, and voting again replaces your earlier vote.
• A single reject ends the request as rejected. It is not reopened by someone else approving.
• Code-change reviews expire after 7 days; a held session start expires after 3 days. After expiry, use Request approval again on the run page.
• Editing a change after it was approved resets its approval to pending.
• Approving a code change opens its pull request, if the quality gate also passes.

Next steps

• Members and roles
• Quality gates
• Audit and RBAC