Documentation

Quickstart

Get Dristi up and running in under 5 minutes. Three commands — install tools, configure agents, start hunting.

Installation

Prerequisites

• Linux (Ubuntu 22.04+, Debian 12+, Arch, Fedora) or macOS
• Git, curl, sudo access
• OpenCode CLI installed (npm install -g @opencode/cli)
• LLM API key (Claude, GPT, or Ollama for local)

1. Install Tools (install.sh)

Installs 60+ security tools: Go binaries, Python packages, Cargo crates, Playwright Chromium, GF patterns, and SecLists.

2. Configure Agents (setup.sh)

Sets up the Dristi agent definitions, OpenCode config, and MCP server configuration.

3. Connect Burp Suite (Optional)

For active testing with Burp proxy:

Usage

Quickstart — Your First Engagement

Start OpenCode in the project directory and describe your target in plain English:

Agents auto-load by topic — you don't need to remember agent names. Just describe what you're testing.

Running the Full Pipeline

Dristi offers three modes for running the 12-phase pipeline:

1. Autopilot (fully autonomous):

Dispatches all 12 phases via sub-agents. Auto-checks phase gates, auto-checkpoints, handles WAF detection, activates conditional phases (DeepThink, Search) automatically, and ends with a full report. No human intervention needed.

2. Consult (interactive):

Same pipeline, but pauses at every phase transition. Presents findings, suggests next steps, and asks for your approval before proceeding. Best for learning the methodology or when you want oversight.

3. Manual (step-by-step):

Invoke each agent individually. You control the transitions and gates. Best for targeted single-class testing when you already know what you want to do.

Targeting Specific Vulnerability Classes

Describe what you see, and the right agent loads automatically. Or invoke by name:

Enterprise & Platform Testing

Slash Commands

Available inside OpenCode conversations for quick actions:

Finding Validation — The 7-Question Gate

Before any finding enters your report, it passes through the 7-Question Gate:

1. Can an attacker use this RIGHT NOW with a real HTTP request?
2. Is the impact on the program's accepted-impact list?
3. Is the vulnerable asset in scope?
4. Does it work without privileged access an attacker can't get?
5. Is this not already known or documented behavior?
6. Can impact be proved beyond "technically possible"?
7. Is this NOT on the never-submit list?

Verdicts: PASS → proceed to report  |  DOWNGRADE → lower severity, still report  |  CHAIN REQUIRED → needs another primitive  |  KILL → discard

Never-submit list: missing headers alone, introspection alone, clickjacking alone, self-XSS, open redirect alone, SSRF DNS-only, logout CSRF, rate limits on non-critical forms, cookie flags alone.

Engagement Management

Start an engagement:

Register scope: Agents use register_scope() and register_scope_batch() to register all in-scope domains, apps, and API endpoints. Bug bounty scope tables can be pasted directly for automatic parsing.

Set up auth: The auth phase detects WAF vendor via response headers, captures tokens/cookies, and saves authentication context for downstream phases.

Track everything: Every test, tool run, and finding is automatically tracked via MCP tools. At the end of an engagement, get_coverage() and get_tool_coverage() verify nothing was missed before report generation.

Report Generation

After validation, generate a professional report:

The report generator first runs get_coverage() and phase_gate_check() to verify all phases passed, then produces a CVSS-scored report with evidence, PoC output, and remediation guidance. Platform-specific reporters handle HackerOne, Bugcrowd, Intigriti, Immunefi, and client-facing DOCX formats.

Agent Reference

Dristi ships with 87 autonomous agents organized into 5 categories:

Pipeline Agents (12)

Hunt Agents (54)

Platform Agents (15)

Specialty Agents (10)

Supporting Agents (12)

Pipeline

Dristi's 12-phase pipeline covers the full bug bounty workflow: