---
name: running-dynamic-exploitation-with-strix
description: >-
  Run a dynamic, active-exploitation pentest with the self-hosted Strix CLI
  (usestrix/strix, Apache-2.0) — autonomous AI agents that don't just flag
  vulnerabilities but attempt real exploits (XSS, SSRF, IDOR, auth/access-control
  flaws, JWT attacks, business logic, race conditions) and only report findings
  backed by a working proof-of-concept. Closes the gap the passive skills in
  this pack (headers, TLS, CORS, SAST, secrets) can't: pattern-matching is not
  proof of exploitability. Self-hosted OSS CLI only — the managed app.strix.ai
  cloud path (source upload, billing) is explicitly out of scope; see Scope.
  Use when: an engagement has an authorized target in scope and the user wants
  active exploitation, a working PoC, or validated (not just flagged) findings.
  Trigger with: "run strix", "dynamically pentest this", "prove this is
  exploitable", "actively test for XSS/SSRF/IDOR", "find and exploit
  vulnerabilities".
disallowed-tools:
  - Bash(strix cloud:*)
  - Bash(strix auth:*)
  - Bash(curl:*app.strix.ai*)
  - Bash(curl:*strix.ai/api*)
  - Bash(wget:*app.strix.ai*)
---

# Running Dynamic Exploitation with Strix

Strix runs autonomous AI pentesting agents in a Docker sandbox that actively
exploit a target — not static analysis. It only reports a finding once it has
a working proof-of-concept, which is the one class of result nothing else in
this pack can produce: the static/SAST skills here detect *patterns*; Strix
proves *exploitability*.

> This skill performs ACTIVE exploitation against a live target. It runs only
> after `confirming-pentest-authorization` has passed AND the operator has
> explicitly named the target as in scope. See **Safety rules** before any
> other step. Stop and refuse if the gate is unmet.

## Scope (read before installing anything)

Strix ships two ways to run: a **self-hosted open-source CLI** (local Docker
sandbox, your own LLM key, nothing leaves your machine) and a **managed cloud**
(`app.strix.ai` / `strix cloud ...`), which uploads source code to Strix's
infrastructure and has an agent-payable Stripe top-up flow for credits.

**This skill covers the self-hosted OSS CLI only, and the cloud path is
technically blocked, not just discouraged.** This skill's `disallowed-tools`
refuses `strix cloud ...`, `strix auth ...`, and any `curl`/`wget` to
`app.strix.ai`/`strix.ai/api` outright — Claude Code enforces this at the tool
level regardless of how the request is phrased, so there is no way to send
the user's source/target to a third party or authorize a real payment (Stripe
`billing topup`) from inside this skill. If the user's own prerequisites block
the OSS CLI (no Docker, no LLM key) and they want the managed cloud instead,
that is a separate decision for them to make directly with Strix outside this
skill — do not attempt it here, even indirectly (e.g. via a raw `requests`/
`python -c` call to the REST API).

## Step 0 — Authorization & scope gate (mandatory, do first)

Do not run a scan until both of the following pass. If either fails, STOP and
report a process finding instead of proceeding.

1. **ROE check.** Confirm `confirming-pentest-authorization` passed and the
   exact target (URL, domain, IP, or repo) is named in the in-scope list, with
   a current time window.
2. **No prod surprise.** If the target looks like shared/production
   infrastructure rather than a dev/staging asset the operator just named,
   re-confirm explicitly before touching it. When in doubt, stop and ask.

## Step 1 — Prerequisites

```bash
docker info                 # Docker must be running; first scan pulls the sandbox image
strix --version             # install if missing — confirm with the user before running an installer:
                             #   curl -sSL https://strix.ai/install | bash   (or: pipx install strix-agent)
```

LLM configuration (two env vars — ask the user for these, never hardcode or commit):

```bash
export STRIX_LLM="openrouter/z-ai/glm-5.3"   # any LiteLLM model id: openai/..., anthropic/..., openrouter/...
export LLM_API_KEY="<provider api key>"
```

## Step 2 — Run the scan

Always `-n` (non-interactive — the default TUI blocks agents) and always
`--max-budget` (hard LLM spend cap):

```bash
# Deployed app / API (black-box) — the common case
strix -n -t https://staging.example.com --max-budget 20

# Local code (white-box), a clean checkout only — a local path is mounted
# *writable*, so the agents can read and modify it
strix -n -t ./ --scan-mode standard --max-budget 10

# Focused testing with credentials or scope hints from the operator
strix -n -t https://app.example.com \
  --instruction "Use credentials user@example.com:pass123. Focus on IDOR and auth bypass." \
  --max-budget 20
```

Run in the background and poll — `quick` is minutes, `deep` (default) is
hours. A clean exit (`0`) is not proof of full coverage if the budget/turn cap
was hit first; check `strix_runs/<run>/run.json`'s `status` and the report's
stated coverage before treating a clean result as complete.

## Step 3 — Read and report results

Artifacts land in `strix_runs/<run-name>/`:

| File | Contents |
|---|---|
| `penetration_test_report.md` | Executive report — read first |
| `vulnerabilities/*.md` | One file per validated finding, with PoC + remediation |
| `vulnerabilities.json` / `.csv` | Structured findings |
| `findings.sarif` | SARIF 2.1.0, for code-scanning ingestion |
| `run.json` | Run metadata, status, targets, cost |

Summarize by severity (critical/high/medium/low/info) and include the PoC
evidence. Redact secrets/credentials used during testing from any report that
leaves the engagement archive.

## Safety rules (non-negotiable)

1. **Never scan a target not explicitly named as in-scope.** Step 0 gate must
   pass first.
2. **Self-hosted OSS CLI only — enforced by `disallowed-tools`, not just this
   instruction.** `strix cloud ...`, `strix auth ...`, and any `curl`/`wget`
   to `app.strix.ai`/`strix.ai/api` are blocked at the tool-permission level
   for this skill; do not try to route around the block (no raw HTTP client
   calls to the same endpoints). That path uploads source/targets to a third
   party and can trigger a real Stripe payment.
3. **A local path target is writable by the agents.** Point it at a clean,
   disposable checkout, never uncommitted work.
4. **Confirm before installing.** Installing the `strix` binary runs a vendor
   installer (`curl | bash`) and pulls a Docker image — treat like any other
   new third-party executable: confirm with the user first.
5. **Redact secrets in reports.** Full credential values go only to the
   encrypted engagement archive, never into chat or a shared report.

## Success criteria

- Step 0 gate passed, exact target named, before any scan ran.
- `--max-budget` was always set.
- Every finding in the summary carries its PoC evidence and a remediation
  note, pulled from `vulnerabilities/*.md` — not just the raw severity count.
- No `strix cloud` / `app.strix.ai` command was ever issued.