# Approvals and policies

> Set what AI sessions may do with workspace policy rules (allow, ask, deny) and how human approvals work: who can approve, expiry, and rejections.

Source: https://aicodeops.dev/docs/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](https://aicodeops.dev/docs/evidence-packs).

## 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).

| Posture           | What it means                                                                                                                                      |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Trusted           | Everything a rule does not restrict is allowed.                                                                                                    |
| Limited (default) | As trusted, but opening a pull request is an ask: it needs an approved review first.                                                               |
| None              | Sessions can still write a proposed change, but can't call MCP tools, run the test command, open a pull request or deploy unless a rule allows it. |

### 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.

| Action              | Label                | Resource              | Can ask? |
| ------------------- | -------------------- | --------------------- | -------- |
| `workflow.dispatch` | Start a session      | workflow              | Yes      |
| `agent.dispatch`    | Run an agent step    | agent                 | Yes      |
| `diff.apply`        | Change a file        | path, e.g. `infra/**` | Yes      |
| `github.push`       | Open a pull request  | owner/repo            | Yes      |
| `mcp.invoke`        | Call an MCP tool     | server/tool           | No       |
| `shell.command`     | Run the test command | command               | No       |
| `release.deploy`    | Deploy automatically | environment           | No       |

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](https://aicodeops.dev/docs/quality-gates) also passes.

## Next steps

- [Members and roles](https://aicodeops.dev/docs/members)
- [Quality gates](https://aicodeops.dev/docs/quality-gates)
- [Audit and RBAC](https://aicodeops.dev/product/audit-rbac)

## Frequently asked questions

### Can I approve a change from a session I started?

Not if someone else in the workspace can approve. Self-approval is only allowed on a team with no other approver.

### What happens when an approval expires?

The change stays blocked. On the run page you can choose Request approval again to open a new review.