Strix (Autonomous Pentest Scanner) — AI Multi-Agent Pentest

Authorization gate. strix actively exploits targets and generates PoCs. Only run it against targets you own or have written authorization to test (your app, your repo, a paid bug bounty scope, CTF infra, anything where the operator has legal permission). Apache-2.0 on the tool does not transfer legal liability for what you point it at.

When to load this skill

Load when the user asks to:

• "run strix", "用 strix 掃", "autonomous pentest", "AI red team scan", "agent pentest"
• scan a whole repo / domain / live app end-to-end (not a single bug class)
• generate validated PoCs + pentest report from one command
• run a pentest inside CI/CD that blocks insecure PRs (-n --scan-mode quick --scope-mode diff --diff-base origin/main)
• ship a white-box source-aware scan (semgrep + AST + trivy + secrets → dynamic validation)

Do NOT load for: a single handcrafted payload, a manual nmap/nuclei sweep, or a one-off <script>alert(1)</script> test — use web-app-pentest / network-pentest / api-security-testing directly. strix is the orchestrator, not a replacement for hands-on craftsman skills.

Setup (one-time, already done on this machine)

# Binary (already installed via pipx)
pipx install strix-agent          # version 1.3.1+ on PATH at ~/.local/bin/strix

# LLM provider — exported via ~/.zshenv AND ~/.hermes/.env
# Routes through NVIDIA NIM (no OpenRouter budget consumed).
# LiteLLM uses `openai/` prefix + LLM_API_BASE override → NIM endpoint.
export STRIX_LLM="openai/nvidia/nemotron-3-ultra-550b-a55b"
export LLM_API_KEY="<NVIDIA_API_KEY>"
export LLM_API_BASE="https://integrate.api.nvidia.com/v1"

# Docker daemon must be running (strix pulls ghcr.io/usestrix/strix-sandbox:1.1.0 on first scan)
docker info >/dev/null 2>&1 || echo "start Docker Desktop / colima first"

Verify quickly:

source ~/.zshenv
strix --version    # → strix 1.3.1
strix --help | head -20

Pitfall: terminal() reads a non-login shell, but sourcing ~/.zshenv first guarantees STRIX_LLM/LLM_API_KEY are present. Always prefix source ~/.zshenv && before invoking strix.

CLI shape (the whole surface area)

strix (--target <T> | --target-list <F> | --mount <DIR>) [options]

Exit codes: 0 = clean (no findings), 2 = vulnerabilities found (headless only).

Modes & when to pick

Running from a Hermes session (this skill's actual job)

This skill exists so I can run strix on your behalf from inside a chat / cron job. Pattern:

# Always: source env, cap budget, run non-interactively, capture output
source ~/.zshenv && \
strix -n \
  --target ./my-app \
  --scan-mode quick \
  --max-budget-usd 2 \
  2>&1 | tee /tmp/strix-run.log

For background long scans, use terminal(background=true, notify_on_complete=true):

terminal(command="source ~/.zshenv && strix -n -m deep -t https://target.tld --max-budget-usd 10 2>&1 | tee ~/strix_runs/manual.log",
         background=True, notify_on_complete=True)

For scheduled scans (e.g. nightly PR-gate):

cronjob(action='create',
  schedule='0 2 * * *',
  prompt='Run strix -n -m quick --scope-mode diff --diff-base origin/main -t /path/to/repo --max-budget-usd 1. Notify me of any finding.',
  skills=['strix-pentest'],
  enabled_toolsets=['terminal','file','cronjob'])

Reading results

• Output dir: ./strix_runs/<run-name>/ (auto-created; --resume uses this name)
• Headless exit code: 0 clean, 2 findings
• Local dashboard: strix view [run-name] — binds 127.0.0.1:random-port, opens browser to a tokened URL, reads files off disk, no upload
• For a sessionable summary I can read into chat: ls strix_runs/ → pick latest → read_file the JSON/TOML findings file inside

Multi-agent internals (so I know what's happening)

strix spawns a Graph of Agents — root + child specialists each with up to 5 specialized skills loaded into their system prompts. Child skills per category:

This means strix is essentially a sub-agent topologist that dispatches to skill chunks I can read directly. The full knowledge base for all 60 chunks lives at ~/Documents/strix-knowledge/strix-skills/ — I can read_file any of them to predict what strix will focus on for a given target, or to cross-check findings against strix's own playbook.

Knowledge fusion with Hermes-native red-teaming skills

This skill is the bridge. strix's internal markdown skills are NOT duplicated into the Hermes skill tree — that would bloat the catalog and create drift. Instead:

• I load cybersecurity (the router) first; it dispatches to the right native skill (e.g. web-app-pentest, network-pentest, api-security-testing, professional-pentest-guide, advanced attack chain-pentest) for the manual / single-technique side.
• When the task is "autonomous end-to-end scan with PoCs", I load autonomous-pentest-scanner and let strix's own multi-agent system drive its sandboxed tools.
• For gaps strix fills that native skills under-cover, the relevant strix knowledge has been mirrored as references/ notes inside this skill (see below) and patched into the relevant native skills where it adds new tactics.

Gaps explicitly covered by strix that were light in the native tree (post-fusion): supabase / firebase / auth0 / grafana+prometheus attack surfaces, trivy-based dependency_cve_scanning workflow, source_aware_whitebox semgrep+ast-grep+tree-sitter+trufflehog+gitleaks orchestration, source_aware_sast white-box triage flow.

Pitfalls (real-world)

• Docker must be running — colima start or Docker Desktop, else first scan fails pulling ghcr.io/usestrix/strix-sandbox:1.1.0. Verify with docker info before invoking.
• Budget is per whole scan (root + every child) cumulative — but the check fires after each model response, so the final spend can overshoot by whatever was in flight. Set --max-budget-usd accordingly (e.g. budget $2 → actually cap at $3 in practice).
• Local big repos need --mount — default file-by-file copy stalls past 1 GB (STRIX_MAX_LOCAL_COPY_MB). Use --mount ./repo (read-only).
• --mount is NOT a security boundary — root inside the container can remount it RW. Treat as "scan my own code", not as isolation from untrusted code.
• Headless exit 2 ≠ failure — it means findings exist. CI should treat 2 as "block PR", not as a runner crash.
• Resume picks up terminal agents only — non-terminal subagents (already-finished leaves) are not re-spawned; their outputs stay in the run dir.
• Streaming callbacks: for LiteLLM-routed models (OpenRouter), strix enables streaming success callbacks to capture provider-reported cost. Message content stays private; only model names / request IDs / token counts flow to callbacks.
• Provider routing: openai/<model-id> prefix + LLM_API_BASE override → any OpenAI-compatible endpoint (NIM, OpenRouter, local vLLM). Current config = NVIDIA NIM via openai/nvidia/nemotron-3-ultra-550b-a55b + LLM_API_BASE=https://integrate.api.nvidia.com/v1. Switch provider by editing strix_LLM + LLM_API_BASE env vars — no strix config file change needed.
• strix view needs an interactive browser — from a headless server run it with --no-open and copy the printed tokened URL to a workstation browser.
• Don't dead-loop on --resume — if a scan consistently stops at the same agent, the budget ceiling or a hallucinated "validated" finding is the blocker. crank --max-budget-usd or read the agent's messages.jsonl in the run dir to see what it thinks is happening.

Verification (skill readiness)

Before declaring strix usable in a session, verify:

# 1) binary + env
source ~/.zshenv && strix --version          # → strix 1.3.1 or higher
docker info >/dev/null 2>&1 && echo dock      # dock=Docker daemon up
printenv strix_LLM                            # → openai/nvidia/nemotron-3-ultra-550b-a55b

# 2) sandbox image reachable (don't pull yet — first scan pulls)
docker manifest inspect ghcr.io/usestrix/strix-sandbox:1.1.0 >/dev/null && echo image-ok

# 3) help works (no API key consumed)
strix --help >/dev/null && echo cli-ok

# 4) knowledge cache present
ls ~/Documents/strix-knowledge/strix-skills/  # → 11 category dirs + README.md

All four passing = good to drive a real scan with --max-budget-usd 1 against an authorized target.

Reference files

• references/upstream-readme.md — strix README (provenance from usestrix/strix main)
• references/upstream-license.md — Apache 2.0
• references/strix-skills-index.md — auto-generated index of all 60 internal skill chunks under ~/Documents/strix-knowledge/strix-skills/ with one-line summaries; use this to find which specific skill chunk to read for a target.
• references/llm-provider-config.md — NIM / OpenAI-compatible provider config (strix_LLM + LLM_API_KEY + LLM_API_BASE, fallback chain, local models).
• references/cli-reference.md — full CLI flag table (mirrors docs/usage/cli.mdx).
• references/scan-modes.md — quick/standard/deep scope behavior, white-box triage stack.
• references/internal-skills/ — symlink into ~/Documents/strix-knowledge/strix-skills/ so skill_view(file_path=...) surfaces the actual strix knowledge.