strix/skills/managed-pentesting-with-strix/SKILL.md

name	description	license	metadata
managed-pentesting-with-strix	Run a managed pentest of a web app or API on the app.strix.ai platform with the `strix cloud` CLI or the REST API — no local Docker, LLM key, or install needed. Sign in with a browser device flow, register domain/repository assets, launch and poll scans, triage vulnerabilities, export SARIF, download PDF/DOCX pentest reports for SOC 2 and other compliance evidence (Enterprise plan), start PR reviews, buy credits with an agent payment, and set up schedules and webhooks. Use when the user wants continuous or scheduled pentesting-as-a-service, an auditor-ready pentest report, scans tracked in a team dashboard, or security testing from a sandboxed agent/CI environment with no infrastructure.	Apache-2.0	author homepage usestrix https://docs.app.strix.ai

Strix Cloud (managed, no local infra)

Use this when you want Strix's autonomous pentesting without running Docker or an LLM yourself — the scan runs on Strix's infrastructure and results are tracked in a team dashboard. This is the right choice in sandboxed/hosted agent and CI environments, for teams, and for scheduled/continuous testing (downloadable PDF/DOCX reports are an Enterprise-plan feature). For fully local, free, air-gapped, or BYO-LLM runs, use the open-source CLI in the penetration-testing-with-strix skill instead — both share the same engine and SARIF output, so you can mix them.

There are two equivalent interfaces. Prefer the CLI:

• strix cloud CLI — every REST operation has a command in the form strix cloud <resource> <verb>. Install with curl -sSL https://strix.ai/install | bash. Run strix cloud to list all resources and strix cloud <resource> to list its verbs.
• REST API — base URL https://app.strix.ai/api/v1, Authorization: Bearer <token> on every request. Full reference: docs.app.strix.ai · OpenAPI: https://docs.app.strix.ai/openapi.json.

The CLI is agent friendly. Output is JSON when stdout is not a terminal, or when you pass --json. There are no interactive prompts when stdin is not a terminal. Exit codes: 0 success, 1 error, 2 invalid usage, 4 authentication required, 5 payment required.

Write commands take request fields as flags. Every write command also accepts one JSON object with --data, which is the way to send fields that have no flag:

strix cloud scans start --data '{"engagement_type":"code_review"}'   # literal JSON
strix cloud scans start --data @request.json                         # read a file
cat request.json | strix cloud scans start --data -                  # read standard input

The platform enforces plan and role limits, and the CLI passes the platform message through. Report downloads need the Enterprise plan. Schedules need the Pro plan. Billing writes need an admin token. A blocked command exits with code 4.

Setup: sign in

Run the device sign-in. It creates the user's account and workspace on first use and stores a personal API token in ~/.strix/platform-auth.json:

strix cloud login --scopes scans:read scans:write billing:read vulnerabilities:read assets:read assets:write

The user approves the sign-in in the browser. With --scopes (and optionally --workspace <name-or-id>) there are no prompts, so the command works from a non-interactive agent shell. In an interactive terminal without flags, the CLI offers a workspace picker and scope presets (Recommended, Full access, Minimal, Custom).

• strix cloud whoami shows the active sign-in. strix cloud logout removes it.
• Every other strix cloud command uses the stored token automatically. To use a different token (for example one created in the dashboard at Settings → API Access), pass --token <token> or set STRIX_API_TOKEN.
• Never hardcode, log, or commit the token. Store it in an env var or the CI secret store.
• Scopes (least-privilege): assign only what the integration needs and rotate regularly:

  Scope	Grants
  scans:read / scans:write	list/read/report scans · create/rerun/cancel scans
  vulnerabilities:read / :write	read findings · update status & notes
  assets:read / :write	read domains/repos · register/update them
  schedules:read / :write	read schedules · create/trigger recurring scans
  pr_reviews:write	trigger PR security reviews
  webhooks:read / :write	manage webhook subscriptions
  tokens:write	create/revoke API tokens
  billing:read / billing:write	read credit balance & auto top-up settings · buy credits (admin)

HTTP errors map to messages and exit codes: 401 bad/expired token (exit 4), 402 out of credits (exit 5), 403 scope/plan-tier limit (exit 4), 422 validation error (exit 1).

0. Credits & top-ups

Scans consume org credits. Check the balance before a scan (billing:read):

strix cloud credits

When the balance is too low, buy credits with strix cloud billing topup (billing:write, admin token). The server answers the first request with HTTP 402 and a machine-payment challenge (Stripe Machine Payments Protocol). The CLI pays the challenge with the mppx client when Node.js is available — the user approves the spend in their agent wallet, for example the Link Agent Wallet. The response returns the receipt (credits_granted, duplicate, reference) and the new balance.

strix cloud billing topup --credits 20 --yes   # --yes skips the confirmation prompt
strix cloud billing topup --credits 20 --no-pay   # print the 402 challenge without paying

If no wallet is available, print the challenge with --no-pay and ask the user to top up in the dashboard instead.

Automatic top-ups (admin): strix cloud billing auto-topup shows the setting. Enable it with:

strix cloud billing auto-topup update --enabled --topup-credits 20 --monthly-cap-credits 200

An omitted --monthly-cap-credits keeps the stored cap. Pass --no-monthly-cap to remove the cap.

Workspaces and account setup

Manage workspaces with a personal token from strix cloud login:

strix cloud workspaces list                    # id, name, role, and the active one
strix cloud workspaces create --name "My Team"
strix cloud workspaces use "My Team"           # store a token for that workspace
strix cloud org members invite --email dev@example.com --role analyst

workspaces use mints a new token for a workspace the user already belongs to, and the role in that workspace limits the scopes. Add --scopes to request a smaller set.

Handoffs a person must finish

Four steps end at the user. The command creates the link or the record and prints it. Strix opens the browser only in an interactive terminal. Pass --no-browser to print the URL only.

strix cloud billing subscribe --plan strix_pro   # hosted checkout page for a plan
strix cloud billing portal                       # billing portal for the card and the plan
strix cloud integrations install github          # GitHub App or Slack installation page
strix cloud domains verify <domain-id>           # DNS record to add, then run it again

Give the printed URL or DNS record to the user and wait. Do not claim that the payment, the installation, or the DNS change is complete. Confirm the result afterwards with strix cloud credits, strix cloud integrations list, or strix cloud domains list. All four commands need an admin token, except domains verify, which needs assets:write.

1. Register the target as an asset

Scans run against registered assets, not raw URLs. Register once, then reuse the returned UUID.

# Domain (black-box / live target). Requires domain verification before external scanning.
# --asset-type must be one of: web_app | api | attack_surface.
strix cloud domains add --domain staging.example.com --asset-type web_app

# Repository (white-box / code review). `full_name` is "owner/name".
strix cloud repos add --data '{"full_name":"org/app","provider":"github"}'

Look up existing assets instead of re-adding: strix cloud domains list, strix cloud repos list (both assets:read).

2. Launch a scan

strix cloud scans start (scans:write). Provide at least one target with --domain-ids, --repository-ids, or --internal-targets (internal infra needs a network connector — see docs).

strix cloud scans start \
  --engagement-type live_test \
  --domain-ids <domain-uuid> \
  --focus "IDOR, auth bypass, SSRF" \
  --context "Staging. Test account creds are configured as a test user." \
  --notify-on-completion

Useful flags (each maps to a CreateScanRequest field):

Flag	Purpose
--engagement-type	live_test (default), code_review, internal_infra, compliance_pentest
--domain-ids / --repository-ids / --internal-targets	targets (at least one)
--domain-paths / --repository-branches	narrow to specific paths / branches (JSON maps)
--credentials	authenticated scanning, incl. mfa_method (totp/email_otp/…) + totp_secret (JSON list)
--headers	extra HTTP headers (API keys, for example) for the target (JSON map)
--focus / --concerns / --context	steer the agents
--upload-ids	attach uploaded source/docs archives for white-box context
--notify-on-completion / --notification-emails	email when done

The response is { scan_id, title, status } with status = pending.

3. Wait for completion

Pass --wait to scans start to poll until the scan reaches a final state, or poll yourself with strix cloud scans get <scan-id> (scans:read). Status flow: pending → running → completed (or failed / cancelled). Scans take minutes to hours — poll on an interval, do not block.

4. Read findings

The scan-detail response includes executive_summary, methodology, recommendations, a findings severity roll-up, and a vulnerabilities[] array. Each vulnerability carries title, severity, status, cvss, cwe, endpoint, method, impact, technical_analysis, poc_description, poc_script_code, and (for code findings) code_file/code_diff/code_before/code_after.

strix cloud scans get <scan-id> --json \
  | jq '["critical","high","medium","low","info"] as $order
       | .vulnerabilities
       | sort_by(.severity as $s | $order | index($s))
       | .[] | {title, severity, endpoint, cwe}'

Cloud severities are critical | high | medium | low and statuses are open | in_progress | fixed | ignored. Sort by an explicit severity order rather than sort_by(.severity), which sorts alphabetically (critical, high, low, medium).

Org-wide triage across scans: strix cloud vulns list --severity critical (vulnerabilities:read, and it also filters by --status, --scan-id, and more). Update triage state with strix cloud vulns update <id> --status fixed. To remediate, hand off to the fix-security-vulnerabilities-with-strix skill.

5. Export & report

# SARIF 2.1.0 for GitHub code scanning / ASPM ingestion
strix cloud scans sarif <scan-id> --output findings.sarif

# Report. Formats: technical (default) | retest | attestation | executive_summary
# Types: pdf (default) | docx
# Any report download requires the Enterprise plan. Formats beyond `technical`,
# DOCX, and white-label branding are Enterprise-only too. Scan must be completed.
strix cloud scans report <scan-id> --format technical --type pdf --output strix-report.pdf

6. PR reviews

Trigger an automated security review of a pull request (pr_reviews:write). The results appear as PR comments and in the dashboard:

strix cloud pr-reviews start --repository-full-name org/app --pr-number 123

List/inspect with strix cloud pr-reviews list and strix cloud pr-reviews get <id>. Repo-level PR-review behavior is configured with strix cloud pr-reviews settings.

7. Continuous testing (schedules & webhooks)

• Schedules (schedules:write, Pro plan): strix cloud schedules create makes recurring scans, and strix cloud schedules trigger <id> runs one on demand — the managed equivalent of a cron-driven CLI loop.
• Webhooks (webhooks:write): strix cloud webhooks create subscribes to pentest/vulnerability lifecycle events such as scan.completed and vulnerability.created to push results into Slack, ticketing, or your own pipeline instead of polling.

See the schedules and webhooks sections at docs.app.strix.ai for payloads.

Safety

Only scan assets the user's organization owns or is authorized to test. External domain scans require verification (DNS/file/meta-tag) enforced by the platform — do not try to bypass it.