# Security and automation guardrails

Security settings describe active protections; Guardrails bounds unattended work. Review the meaning of each control before changing it.

## Security controls
The Security panel exposes active protections and a shell denylist. The packaged baseline is read-only; custom command patterns add restrictions rather than removing that baseline. Test a new pattern on representative commands to avoid accidentally blocking necessary work.

Network egress controls can allow named hosts or deny destinations; a deny wins over an allow. These gateway-mediated protections do not turn installed app code into a network sandbox. See [limitations](/docs/trust-and-safety/overview).

## Unattended budgets
Under **Guardrails**, set daily token and estimated-dollar limits and a per-run token bound. A zero value means unlimited where documented. At the daily ceiling, further unattended work is skipped or refused and can resume on the next day. Interactive chat is a separate path.

## Outbound scan
Choose the intended scan behavior: **warn** records and sends, **redact** substitutes and sends, and **block** refuses the call. Read a refusal before deciding whether to change the policy or remove sensitive input.

## Circuit breakers
Repeated provider failures can open a circuit breaker to fail fast during an outage. Configure failure and recovery thresholds only when you understand the service behavior. A breaker report is an operational signal, not proof that a task completed.

## Earned autonomy and incident mode
Autonomy increases require your decision; rejection, negative feedback, or undo can reduce it and start a cooldown. Externally visible effects have stricter limits.

**Incident mode** suspends unattended cron, hooks, triggers, and subagent spawning while interactive chat remains available. Resume is explicit. Inspect affected work before resuming it.