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.

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.