# Automated runs

Stricter rules for the runs nobody is watching - automations, Software Factory builds and assurance checks - and what happens to an action that would need your yes.

Some runs have nobody watching: automations, Software Factory steps and builds, and assurance checks. Nobody is there to answer a question, so Warden treats them differently.

## Ask means hold

In an automated run, an action a rule would ask you about is **held**: it doesn't run, it isn't prompted, and the agent is told it was held for review and not to work around it. The run carries on with everything else. Held actions appear in Mission Control's **Needs you**, and in your notifications, for you to approve or refuse later.

A deny is a deny in every kind of run.

## A separate, stricter rule list

**Policies → Automated runs** is *a separate list for unattended runs… they can only tighten what an automated run may do.* Pick a preset, then adjust any protection:

| Preset | What it does |
|---|---|
| **Follow manual** | No automated-only rules: the same as your chats. |
| **Balanced** | Review risky actions (the Guarded levels). |
| **Locked down** | Block risky actions (the Hardened levels). |

Each protection can be **Inherit** (follow your manual policy), **Review** (hold for review) or **Block**. Behind the scenes, every rule in this list carries `when: { trigger_mode: automated }`, so it never changes what happens in a chat you are in.

You can write the same thing by hand in your custom rules:

```yaml title="Only in runs nobody is watching"
rules:
  - ask: "git push"
    when: { trigger_mode: automated }
    reason: "Unattended runs don't push: a person reviews first"
  - deny: { touches: package_install }
    when: { trigger_mode: automated }
    reason: "No new dependencies without a person"
  - deny: git push
    when: { trigger_mode: automated, assurance_meets_l2: "false" }
    reason: "Unattended pushes need L2 assurance"
```

Which mode a run is in is fixed when its session starts. The agent can't change it.

## Sandboxed runs

A **sandboxed run** (the Factory's Express builds, or a chat started as *Autonomous (sandboxed)*) adds a second layer:

- a **throwaway worktree**, so your checkout is untouched;
- a **kernel sandbox** (macOS Seatbelt), so the run can't write outside its folder;
- a **network proxy** that is the only way out: the run reaches your model provider and the domains your rules allow, nothing else.

Inside a sandbox, an action that would need your yes **goes ahead if its effect stays inside the sandbox**, and is recorded as *auto-allowed under sandbox*. An action whose effect would escape is **held for review** and never run: a push, `gh`, a deploy, a publish, an MCP call, a write outside the run, an off-list network call. When you approve a held action, it is replayed in a chat you can watch. A deny stays a deny.

> [!LIMIT]
> In a sandboxed run, a domain or path named anywhere in a deny or ask rule is unreachable, including values listed under `unless:`. A rule like *deny all web fetches unless github.com* blocks github.com inside the sandbox too.

## Fail closed

If the policy engine can't answer, automated runs are held. Nothing runs unchecked.