Feature Threat Informed Audit

Feature: Threat-Informed Audit (Stage 0 — Research)

What it is. Before recon even starts, Argo runs a public web OSINT pass: from the program brief, links, and name, it gathers CVEs, advisories, and the project's own security history, and writes research_brief.md + threat_intel.json. Those get injected into Stage 2 (recon), so the audit prompts it generates are threat-targeted from the start instead of generic.

Why it matters. A generic audit checklist finds generic bugs. Knowing "this project had a history of deserialization CVEs" or "the vendor patched an SSRF here last year" lets recon steer the generated prompts toward the classes of bug that actually recur in this codebase's history.

How it's gated

• Opt-out, on by default. --research/--no-research (pipeline) or the research toggle in the web UI (also default on). --no-research keeps the run fully offline.
• One of exactly two networked stages in the whole pipeline (the other is corroborate, after validation — see Docs & History Corroboration).
• Bounded to OSINT tools only — WebSearch/WebFetch, nothing else. No shell, no sub-agent tool, and critically: no repo access (repo_dir=None). The research session never sees your code; the code-seeing sessions never get the network. Two disjoint capabilities.
• Never touches the program's live in-scope hosts. Those are injected into the prompt as an explicit FORBIDDEN LIVE HOSTS denylist. It reads public third-party sources only — advisories, docs, the public source repo.
• Best-effort. A failure here never aborts the run — recon just proceeds without the brief.
• Forced off for a brief-less local review and for --smoke, so those stay 100% offline.

What downstream stages get from it

research_brief.md and threat_intel.json feed directly into the recon meta-prompt (Stage 2), so the archetype classification and the custom prompt split (see Archetype-Driven Prompts) already know the project's threat history before generating a single audit prompt.

Related

• Docs & History Corroboration — the other networked stage, running after validation instead of before recon.
• Guardrails & Safety §2a — the exact code-level enforcement of the network boundary.