Feature Live Verification

Feature: Live Verification (opt-in, authorized use only)

⚠️ This is the one capability that, by design, contacts the program's real, live in-scope host — a deliberate, heavily-gated relaxation of the "never a live host" rule, for authorized bug-bounty engagements whose rules of engagement permit automated interaction. It gives the agent bounded live recon/verification to confirm findings and cut false positives — the same edge a human researcher gets from touching the target — without leaving the authorized envelope.

Off by default (live_enabled=False), and the standalone argo live command additionally requires an explicit --i-have-authorization acknowledgement.

It's the live analog of Runtime Verification's sealed sandbox: same propose→validate→execute→interpret shape, but the target is the in-scope host instead of loopback — so the validators are inverted and tightened.

The gates, in order

1. RoE authorization gate — refuses unless the scope authorizes it: automation_allowed is true, safe_harbor is not explicitly false, and prohibited_techniques is non-empty (no touching a live host without declared hard limits).
2. In-scope-only scope-lock — every request must use an absolute URL whose host is a registered in-scope asset. Out-of-scope, unknown, and loopback hosts are all hard-blocked (careful wildcard matching — no *.acme.com overmatch). A violation aborts before any request is sent.
3. Read-only + anti-DoS caps — GET/HEAD/OPTIONS only by default; total request count, body size, and rate are capped. An oversized plan is rejected whole (fail-loud, no silent truncation).
4. State-changing policy (a second, separate opt-in) — --allow-writes permits non-destructive POST/PUT/PATCH for confirmation only. DELETE is never permitted, even in write mode. Writes are capped separately (--max-writes, default 5). Read requests omit headers/body from the audit log (no secret leakage); a write request records its body — a mutation must be fully accountable.

Execution

• No model execution primitive. The plan (hand-written, or LLM-generated from the validated findings using absolute in-scope URLs) is run by a fixed stdlib executor, not a model shell. Both the propose and interpret sessions are offline (no network tools) — only the fixed executor ever reaches the host, and only after the deterministic gates pass on the generated plan.
• Hardened executor:
  • a tool-identifying User-Agent;
  • never auto-follows redirects — each 3xx is re-validated in-scope before following; an off-host redirect is recorded, never chased; writes are never re-followed;
  • retries transient errors (timeout/connection reset/5xx/429 with Retry-After) for idempotent methods only — a write is never retried (no double-mutation);
  • captures response headers + the redirect chain as evidence;
  • supports a differential control request per probe (a baseline run alongside), so the interpret stage judges the difference — the biggest false-positive cut for access-control findings.
• Full accountability — every request (probe + control) is written to a JSON-lines audit log with timestamp, method, URL, status, size (+ body for a mutation).

Best-effort, off by default

Skips silently when disabled or no plan exists; any gate failure aborts the stage and sends nothing.

Related

• Runtime Verification — the sandboxed, loopback-only sibling of this stage for OSS targets you can build yourself.
• Guardrails & Safety §2c — the full code-level enforcement mapping.