---
title: Autonomy policy
description: The twelve settings that bound what Ysra may do without asking, how account and repository policies combine, and why a running session keeps its snapshot.
---

Your **autonomy policy** is the contract between you and Ysra: what it may do on
its own, what it must ask about, and what it may never do. Safe defaults apply
until you save a policy.

![The account policy in Account settings: autonomy ceiling, dependency downloads and installs, delivery and unverified delivery, with unavailable choices greyed out](../assets/screens/settings-policy.webp){ width="1600" height="1351" }
/// caption
**Workspace → Account settings.** Choices the platform can't carry out yet are
marked *unavailable* rather than accepted silently.
///

## How policies combine

```mermaid
flowchart TB
    account[Account policy] --> effective
    repo[Repository override<br/><small>only the fields it sets</small>] --> effective
    effective[Effective policy] -->|snapshot at session start| session[Session contract]
```

- The **account policy** sets defaults for every repository.
- A **repository override** changes only the fields it sets; everything else
  comes from the account.
- When a session starts, the **effective policy** is copied into it. Editing
  settings later does not change a session that is already running or paused.

## Settings

| Field | Values | Default |
|---|---|---|
| `force_push` | `deny`, `ask` | `ask` |
| `run_tests_before_claim` | `true` | `true` |
| `package_installs` | `deny`, `ask`, `allow` | `ask` |
| `network` | `deny`, `ask`, `allow` | `ask` |
| `destructive_actions` | `deny`, `ask` | `ask` |
| `production_credentials` | `deny`, `ask`, `scoped` | `deny` |
| `delivery_mode` | `preserve_only`, `push_branch`, `draft_pr`, `merge_on_green` | `preserve_only` |
| `unverified_delivery` | `preserve_only`, `draft_pr` | `preserve_only` |
| `deployment` | `deny`, `staging`, `ask_production` | `deny` |
| `autonomy_ceiling` | `suggest_only`, `code_then_review`, `draft_pr`, `merge_on_green`, `deploy_to_staging` | `code_then_review` |
| `nightly_backlog_sweep` | boolean | `false` |
| `show_execution_rationale` | boolean | `true` |

!!! danger "Some values are stored but not yet enforced"
    Not every accepted value changes behaviour today. In particular,
    `merge_on_green` and `deploy_to_staging` do not currently perform what their
    names suggest. Read `GET /developer/account/capabilities` and treat it as
    the source of truth — never this table.

`run_tests_before_claim` is fixed on: the API rejects `false`.

## A policy for a first rollout

Most teams start conservative and widen one setting at a time:

```yaml title="Suggested starting policy"
delivery_mode: draft_pr          # open a draft PR once verified
unverified_delivery: preserve_only
package_installs: ask
network: ask
destructive_actions: ask
production_credentials: deny
deployment: deny
autonomy_ceiling: draft_pr
```

To change it through the API, see [Autonomy policy endpoints](../api/account/policy.md).