[security]
Security flags controlling shell features. Defaults are restrictive (pipes and background execution off; redirects default to stream merges only — enough for cargo test 2>&1 but not file writes).
allow_background
Section titled “allow_background”Allow background execution cmd &. Default true: rarely used by agents but harmless; flipping off blocks the occasional valid pattern with no security upside.
allow_case_terminator
Section titled “allow_case_terminator”Allow the ;; case-statement terminator. Default true: rarely useful outside a full case block, but no security upside to gating it.
allow_compound
Section titled “allow_compound”Allow compound operators &&, ||, and single ; so commands like cd subdir && cargo test work. Default true: cd dir && cmd is the most common multi-step shell idiom.
allow_expansion
Section titled “allow_expansion”Allow parameter expansion ${VAR} (and related forms like ${VAR:-default}). Default true: read-only env access, lower risk than subshell, and the agent already sees the env it would read.
allow_pipes
Section titled “allow_pipes”Allow shell pipes cmd1 | cmd2. Default true: pipes are a foundational shell idiom and disabling them blocks cat | grep, ls | head, every basic composition.
allow_privilege_wrappers
Section titled “allow_privilege_wrappers”Whether granting a privilege-escalating wrapper as a command pattern (sudo:*, doas:*) is allowed. Default false — sudo / doas cross the sandbox boundary entirely: every subprocess they spawn runs outside seal’s policy enforcement, with the privilege uplift on top. Flipping to true lets users opt back in (an every-load warning still fires). Whether granting a privilege-escalating wrapper as a command pattern (sudo:*, doas:*) is allowed. Default false — sudo / doas cross the sandbox boundary entirely: every subprocess they spawn runs outside seal’s policy enforcement, with the privilege uplift on top. Flipping to true lets users opt back in (an every-load warning still fires).
allow_python_interpreter
Section titled “allow_python_interpreter”Whether granting a system Python interpreter as a command pattern (python:*, python3:*, uv run:*, etc.) is allowed. Default false — the managed python_exec tool with its [capabilities.python] config is the supported path; granting a raw interpreter command bypasses module blocking, the injected seal lib, and the entire managed- runtime safety story. Flipping to true lets users explicitly opt back into running their system python. Wrapper-table enforcement at manifest load surfaces a hard error when this is false and a Python-interpreter command is granted.
allow_redirects
Section titled “allow_redirects”Policy for shell I/O redirection operators in commands.
Three modes, least-permissive first:
None— reject every redirection.cmd > file,cmd < file,cmd 2>&1, everything. Strict lockdown, useful when any shell I/O reshaping is a policy concern.Streams— allow file-descriptor merges (2>&1,1>&2, etc.) but reject file redirects (>,>>,<). This is the practical default: merging stderr into stdout for output capture is a universally-needed agent pattern and touches no filesystem state, while writing/reading files through shell redirects is still the user’s filesystem-write/read grants’ concern.All— allow every redirect form, including file writes and reads. Opt-in only; signing this explicitly grants the agent the ability to spill command output into arbitrary paths.
| Value | Meaning |
|---|---|
"none" | Reject all redirect syntax. |
"streams" | Allow fd-to-fd merges only. Default. |
"all" | Allow every redirect form, including file writes and reads. |
allow_runtime_expansion
Section titled “allow_runtime_expansion”Whether the agent can request new permissions at runtime (via interactive prompts that modify seal.toml). Defaults to true — the prompt-driven flow is what most users want. Security-conscious users set this to false to fully lock the agent down to the currently-signed set of grants (CI pipelines, unattended runs, etc).
allow_subshell
Section titled “allow_subshell”Allow command substitution: $(cmd) and backticks `cmd`. High blast radius — a substituted command runs inside the shell with the agent’s full environment. Default false.
hide_model_info
Section titled “hide_model_info”Hide model name and provider from the agent’s system prompt. Default false — agent knows what model it is.
implicit_compound_coordinators
Section titled “implicit_compound_coordinators”Implicit allowlist for a small set of shell utilities (echo, printf, true, false, :, exit, cd, pwd, pushd, popd) when they appear as a segment of a compound command — no manifest grant needed.
These utilities have no fs/net/process side effects, so requiring a [allow.commands] entry for them adds friction without security signal. Users who write curl ...; echo done shouldn’t need to also grant echo:*. Deny grants still beat the allowlist: an explicit [deny.commands] patterns = ["echo"] keeps echo blocked.
Set to false to require explicit grants for every compound segment regardless of how harmless. The strict posture rejects every compound until the user adds each coordinator to their allow list. Default true.
prompt_file_reads
Section titled “prompt_file_reads”Whether fs:read prompts fire for paths not covered by an allow grant. Default true — the daemon asks the user on every new read inside the project root or an additional_directories entry, matching the command prompt flow. Set to false to silently allow all reads within declared roots (still subject to deny rules) — useful when prompt volume dominates a read-heavy workflow. Writes always prompt; this flag only affects reads.
restrict_file_visibility
Section titled “restrict_file_visibility”Filter file_list and grep results through the sandbox. Default false — agent can see all files but only read/write allowed ones. When true, files outside read patterns are invisible to the agent.
universal_deny_domains
Section titled “universal_deny_domains”Universally-denied network domains. Applies to EVERY network-capable surface — granted commands, future python and web tools — regardless of what per-surface allow lists say. Cloud-metadata endpoints (169.254.169.254, metadata.google.internal, 100.100.100.200) are the canonical entries; user-supplied additions stack on top.
Each entry validates against seal_net::validate_pattern at manifest load — literal hostnames or *.<registrable-domain> wildcards per the Public Suffix List. Empty / omitted leaves the deny list empty (defaults don’t get auto-injected; the project that wants the cloud-metadata baseline lists it explicitly).
Distinct from [capabilities.deny.commands] domains, which only applies to granted commands and not to non-command surfaces.