Guardrails and Safety

Guardrails & Safety

The non-negotiable rules are enforced in code, not just in prompts. This page maps each guardrail to where it's enforced, so you can verify it's real rather than take it on faith.

The capability map shows the core invariant visually — Argo's sessions fall into three disjoint zones, and no session ever holds both repo access and network access at once:

1. Never auto-submit

Stage 5 stops at DRAFT bundles; submission is a manual human action. There is no submission code path anywhere in the tree — the only HTTP client is the gated live-probe executor (off by default, see below). Report/draft artifacts carry a "Produced by Argo" footer (default on, --no-attribution to opt out) — attribution only, never a claim of authorship over the target code. The CLI exposes no submit command.

2. Never contact, scan, or exercise a live host — except two bounded, opt-in exceptions

Every stage of the default pipeline is fully offline against the program's hosts. config.NETWORK_TOOLS lists every network/sub-agent tool; the runner strips them from any session's allowlist before it launches, and asserts no network tool is present as a hard stop right before launch. This is backend-neutral: enforced via the tool allow/deny list for Claude, and via the OS sandbox (-s workspace-write) for Codex — see Multi-Backend.

• 2a — research + corroborate (opt-out, on by default): the only two stages allowed any network access, and only the OSINT subset (WebSearch/WebFetch) — never a shell, never the repo. Neither ever touches the program's live in-scope hosts (injected as an explicit forbidden denylist). See Threat-Informed Audit and Docs & History Corroboration.
• 2b — runtime (opt-in, default off): builds the OSS target from the cloned source into an egress-blocked container (--network=none) and probes only 127.0.0.1 inside that sealed namespace — never the program's real host. See Runtime Verification.
• 2c — live (opt-in, default off, ⚠️ authorized use only): the one capability that deliberately contacts the program's real in-scope host, for authorized bug-bounty engagements whose RoE permit it. Heavily gated: RoE-authorization check, in-scope-only scope-lock (out-of-scope, unknown, and loopback hosts all hard-blocked), read-only-by-default + anti-DoS caps, a second opt-in for non-destructive writes (DELETE never allowed), full audit logging. See Live Verification.

3. Repo mounted read-only to every session; the pipeline never patches

The session's cwd is a separate writable scratch dir, never the repo — the repo is exposed only via a read-only mount. Ingest additionally strips write bits from every copied repo file (defense in depth). Mutation tools (Edit, MultiEdit, NotebookEdit) are always disallowed. There is no code path that writes into repo/.

4. Prohibited techniques propagated into every rendered prompt

If a rendered prompt is missing a prohibited technique from the scope (e.g. "no DoS"), rendering fails — and an empty prohibited-techniques list is itself rejected, since a real program always has hard limits. Enforced at recon, audit, and validate — on the actual prompt that drives each session, not just the template.

5. Validate against JSON Schemas; log every LLM call

Scope and findings are Draft-07 schema-validated at every gate. Every LLM call is logged (prompt sha256, model, tokens, cost) even when the session errors — cost logging is never skipped.

Additional code-side defenses

• Scope filter, independent of the LLM verdict — drops any finding whose affected reference falls under an explicit out_of_scope token, before validation even sees it.
• Conservative ingest defaults — a silent brief defaults automation_allowed to false and injects a conservative default prohibited-techniques set.
• Budget is a hard guard — --budget aborts remaining sessions once real spend hits the ceiling; the abort is logged, never silent.

What the guardrails deliberately do not do

They do not vouch for finding quality — that's the job of the audit and validation prompts (see Adversarial Validation and Benchmarks & Costs). For the adjacent question — how the pipeline keeps a hallucinating, non-deterministic model trustworthy (mechanical diffs, ground-truth build verification, physical caps, commit-pin reproducibility) — see Determinism & Anti-Hallucination. They guarantee the pipeline stays inside the authorized envelope: source-static only, read-only, no submission, and no live contact unless you explicitly opt into the gated live stage — which itself stays scope-locked, read-only-by-default, capped, and audit-logged.