Safety model

The harness assumes the model can be wrong or manipulated, and limits what it can do:

• Edits stay in the worktree. Every path is resolved and checked before a read or write: no .., no absolute paths, no symlinks out, no protected paths, no Windows aliases such as .git. or GIT~1.
• No commands from the model. Only your configured gates and a fixed list of git subcommands run, as argv arrays. Git hooks are disabled for every git command the harness runs.
• No remote writes. Nothing is pushed, fetched or merged. The only download is a clone you confirm in the app.
• Scrubbed environment. Gates run without your tokens and secrets unless you list them in gateEnvAllow.
• Tools decide. A task is done only when its blocking gates pass or fail exactly as they did at baseline.
• Untrusted text is fenced. Repository content, docs, gate output and model output reach a model only inside a fenced block marked as data, never as instructions. Instruction-like text in your files (“ignore previous instructions”, “note to the AI”, …) is also pointed out to the model as data and listed in the report. That detection is a pattern match: it catches common phrasings, not every reworded attempt, so it warns and never blocks. The fence, the fixed edit format and your gates are what keep a planted instruction from taking effect.
• Findings need proof. A review claim is presented as fact only when a test confirmed it.
• No installs. The harness never installs your project’s dependencies; you do.
• Your checkout is untouched. All work happens on a branch in a separate worktree.
• Keys. Read only from the environment variable you name; never logged, recorded or shown.
• The app is local. It binds to 127.0.0.1 only, refuses foreign hosts, needs a per-start token and its own origin for every change, sends a strict Content Security Policy, and renders model output as text, never HTML.

Each of these has a test in test/guardrails_test.rb. See SECURITY.md to report a vulnerability.