# Policy and kill switch

> Edit the Vigilbase OS action policy - separation of duties, self-approval, critical actions, protected resources, Vigil autonomy - and use the kill switch.

Source: https://docs.vigilbase.com/os/settings/policy

The action policy sets the rules for approving action plans and what Vigil may start on its own. The kill switch stops all action execution at once. Both are under **Settings**. For the ideas behind them, see [Approvals and policy](https://docs.vigilbase.com/os/concepts/approvals-and-policy).

## Edit the action policy

You need the `policy.read` permission to view the policy and `policy.manage` to change it. Without `policy.manage` you see the policy read-only.

:::steps
1. **Open Settings, then Policy.** The panel shows the current version, when it was updated and by whom.
2. **Change the settings you need.** See the table below.
3. **Choose Save policy** and confirm it's you.
:::

Saving creates a new policy version. Plans still awaiting approval must be recreated under it. Plans already approved stay executable only if their policy version is listed under **Compatible earlier versions**.

| Setting | What it does |
|---|---|
| **Require separation of duties** | The proposer of a plan can never approve it. Always enforced for critical actions. |
| **Step-up before approval** | Approving or rejecting needs an authenticator code, or a sign-in with multi-factor authentication, within the last hour. Always on. |
| **Self-approval** | With separation of duties on, owners and admins may approve their own plans for the setup actions you tick. Only collection setup, such as Logpush, can be listed. |
| **Approval lifetime (minutes)** | Approvals expire if the plan is not executed within this time. |
| **Critical action keys** | One action key per line. Critical actions always require the approver to be a different person from the proposer. An action cannot be both critical and self-approved. |
| **Protected resources** | A type, resource ID and reason for each resource. Plans that target these are blocked or need extra review. Choose **Add protected resource** to add one. |
| **Compatible earlier versions** | Comma-separated earlier policy versions whose approved plans stay executable. Leave empty to invalidate earlier approvals. |
| **Allowed model providers** | Comma-separated. Vigil only uses these providers for your organisation. |
| **Vigil autonomy** | Switches for **Collection**, **Analysis** and **Investigation**: what Vigil may start on its own. Vigil never has write tools, whatever these say. |

## Kill switch

The kill switch immediately blocks every action execution for your organisation. Detection, collection and investigation continue.

:::steps
1. **Open Settings, then Kill switch.** It shows **Engaged** or **Not engaged**.
2. **Choose Engage kill switch.** You need the `killswitch.manage` permission.
3. **Enter a reason and choose Engage.** The reason is recorded in the audit log. Confirm it's you.
:::

While the kill switch is engaged, running executions halt at the next step boundary and no new step starts. Plans cannot be approved, and the top bar shows **Kill switch engaged**.

To undo it, choose **Release kill switch**, enter a reason and choose **Release**. Approved, unexpired plans may then execute again.

Vigilbase can also engage a global kill switch for all organisations. You see **Global kill switch engaged by Vigilbase**, and you cannot release it yourself.