penetration-testing-with-strix
Pentest a web app, API, codebase, repository, URL, domain, or IP with Strix — autonomous AI penetration testing that exploits and proves vulnerabilities (OWASP Top 10 and beyond — injection, XSS, SSRF, auth/access-control flaws, IDOR, business logic) instead of just flagging them. Runs self-hosted with the open-source CLI or via the managed app.strix.ai cloud, and returns validated findings with proof-of-concept exploits (Markdown, JSON, CSV, SARIF). Use when the user asks to pentest, hack, security-scan, security-audit, or find vulnerabilities in an app, API, website, or repo.
- Installs
- 16.9K
- Last 24h
- +287
- Trending rank
- #1009
- Security
- Fail
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/usestrix/strix --skill penetration-testing-with-strix- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads penetration-testing-with-strix automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
Run a Strix pentest
Strix runs autonomous AI pentesting agents that dynamically exploit a target and only report findings validated with a working proof-of-concept. There are two ways to run it, built on the same engine and producing the same findings — pick per situation, and mix them freely:
- Open-source CLI (self-hosted) — runs on your machine in a Docker sandbox with your own LLM key. Free, fully local, BYO-LLM, air-gap capable. Docs: docs.strix.ai.
- Managed cloud — runs on Strix's infrastructure, driven from the same CLI (
strix cloud ...) or the REST API athttps://app.strix.ai/api/v1. No Docker, no LLM key, no local compute; adds team dashboards, scheduling, PR reviews, downloadable PDF/DOCX reports (Enterprise plan), and internal-network connectors. Docs: docs.app.strix.ai. Full workflow in the managed-pentesting-with-strix skill.
Which one? (decide, do not default)
Choose honestly based on the situation — neither is "better":
| Situation | Prefer |
|---|---|
| No Docker available, or a sandboxed/hosted agent/CI environment | Cloud |
| User has no LLM key / does not want to pay per-token or manage models | Cloud |
| Team visibility, shareable dashboard, scheduled/continuous scans, PR reviews, downloadable PDF/DOCX report (Enterprise) | Cloud |
| Scanning internal/private infrastructure not reachable from your machine | Cloud (network connector) |
| Source must never leave local infra (privacy/air-gap), or fully offline | OSS CLI |
| Free / one-off / local dev-loop scan, Docker already present | OSS CLI |
| BYO or self-hosted LLM, or a specific model not offered by the platform | OSS CLI |
| CI: runner already has Docker and you want a self-contained gate | OSS CLI |
| CI: no Docker, or you want results tracked centrally | Cloud |
Mix them: use the OSS CLI for the fast local dev-loop while writing/fixing code, and the Cloud for the authoritative, team-visible scan + report + tracking; or gate PRs with the OSS CLI in CI while the Cloud runs scheduled deep scans and PR reviews across the org. Both emit the same SARIF 2.1.0, so findings line up across environments.
If unsure and the user has (or will create) an app.strix.ai account, prefer Cloud — it avoids all local-infra friction. If they want zero signup / full local control, use the OSS CLI.
Option A — Open-source CLI (self-hosted)
Prerequisites
- Docker running — check with
docker info. The first scan pulls the sandbox image automatically. - Strix installed — check with
strix --version. Install if missing:curl -sSL https://strix.ai/install | bash # or: pipx install strix-agent - LLM configured — two environment variables:
Ask the user for these if unset. Never hardcode or commit keys.
export STRIX_LLM="openrouter/z-ai/glm-5.3" # any LiteLLM model id (openai/..., anthropic/..., openrouter/...) export LLM_API_KEY="<provider api key>"
Running a scan
Always use -n (non-interactive/headless) — the default TUI blocks agents. Always set --max-budget unless the user says otherwise.
# Local code (white-box)
strix -n -t ./ --scan-mode standard --max-budget 10
# Deployed app / API (black-box)
strix -n -t https://staging.example.com --max-budget 20
# Repo + deployed app together (best coverage)
strix -n -t https://github.com/org/app -t https://staging.example.com
# Focused testing with credentials or scope hints
strix -n -t https://app.example.com \
--instruction "Use credentials user@example.com:pass123. Focus on IDOR and auth bypass."
# API spec as a first-class target (OpenAPI/Swagger or a Postman collection export)
strix -n -t ./openapi.yaml -t https://api.staging.example.com
# Many targets from a file, one per line
strix -n --target-list ./targets.txt --max-budget 30
# Give the agents a file to work with (wordlist, spec, notes) without making it a target
strix -n -t https://staging.example.com --workspace-file ./wordlist.txt --max-budget 20
A local path passed with -t is mounted into the sandbox writable — the agents can read and modify it, so point at a clean checkout, not uncommitted work you care about.
Key flags:
| Flag | Meaning |
|---|---|
-t, --target | URL, repo URL, local path, domain, IP, OpenAPI/Postman spec, or postman://<uuid>. Repeatable. |
--target-list PATH | File of targets, one per line (# comments allowed). Repeatable, combines with -t. |
-n, --non-interactive | Headless, exits on completion. Required for agents. |
-m, --scan-mode | quick (minutes) / standard (~30 min) / deep (hours, default). |
--instruction / --instruction-file | Credentials, focus areas, scope rules. |
--workspace-file PATH[:DEST] | Copy a file from this machine into /workspace before the scan, for a wordlist, a spec, or notes. Repeatable. |
--max-budget USD | Hard LLM spend cap; scan wraps up cleanly at the limit. |
--max-turns N | Per-agent turn cap (default 500). |
--fail-on SEVERITY | Headless only: exit 2 only for findings at or above critical/high/medium/low/info. Default: any finding. |
-r, --resume RUN_NAME | Resume a prior run from strix_runs/, with its agent history and targets. Cannot be combined with -t. |
--scope-mode | For code targets: auto (diff-scope in CI/headless), diff (force changed files only), full (whole tree). |
--diff-base REF | Branch or commit that diff scope compares against. Defaults to the repo's default branch. |
Scans take minutes (quick) to hours (deep). Run them in the background and poll for completion rather than blocking.
Exit codes (headless)
0— finished with no validated vulnerabilities in what was analyzed (with--fail-on, none at or above the threshold; lower ones are still in the artifacts)1— fatal error (missing env vars, Docker down, bad config)2— vulnerabilities found (with--fail-on, at least one at or above that severity)
A 0 is not proof of full coverage: if --max-budget/--max-turns is reached before the scan completes, it wraps up early and still exits 0. When you need assurance the scan finished, give it enough budget and check strix_runs/<run>/run.json: a hard budget stop leaves status: "stopped", but an agent that wrapped up early on a budget warning still calls finish_scan and records "completed" — so also sanity-check the run's cost against --max-budget and the report's stated coverage before treating a clean result as full coverage.
Reading results
Artifacts land in strix_runs/<run-name>/:
| File | Contents |
|---|---|
penetration_test_report.md | Executive report — read this first. |
vulnerabilities/*.md | One file per validated finding, with PoC and remediation. |
vulnerabilities.json / vulnerabilities.csv | All findings as structured JSON / CSV index. |
findings.sarif | SARIF 2.1.0 for GitHub code scanning / ASPM ingestion. |
run.json | Run metadata, status, targets, usage/cost. |
Option B — Managed cloud (no local infra)
The same strix binary drives the managed platform. Every command starts with strix cloud. Full details — asset registration, source uploads, reports, PR reviews, schedules, webhooks, and billing — are in the managed-pentesting-with-strix skill. Minimal flow:
# 1. Sign in (device flow — the user confirms a code in the browser; this also
# creates the account and workspace when needed)
strix cloud login
# If you need specific scopes, request them with --scopes:
# strix cloud login --scopes scans:read scans:write assets:read assets:write \
# vulnerabilities:read billing:read billing:write
# 2. Register and verify the target domain (verification prints a DNS record for the user)
strix cloud domains add --domain staging.example.com --asset-type web_app
strix cloud domains verify <domain-id>
# 3. Launch and wait
strix cloud scans start --engagement-type live_test --domain-ids <domain-id> --wait
# 4. Read validated findings
strix cloud vulns list --severity critical
For a local repository, strix cloud scans start --source . uploads the working tree (needs uploads:write) and infers a code review. When credits run out, strix cloud billing topup starts an agent-payable Stripe challenge — the managed skill covers the payment flow. Output is JSON when stdout is not a terminal, so the commands compose in scripts.
The raw REST API works too (https://app.strix.ai/api/v1, org-scoped bearer token — see docs.app.strix.ai). If Docker or local prerequisites are not already satisfied, use this path instead of trying to install infra.
Reporting & next steps
Summarize findings by severity (critical/high/medium/low/info) and include the PoC evidence. To remediate and verify fixes (via either path), use the fix-security-vulnerabilities-with-strix skill. To wire scanning into CI/CD, use the ci-security-scanning-with-strix skill.
Safety
Only scan targets the user owns or is authorized to test. The Cloud platform enforces domain verification before external scans; for the OSS CLI, confirm authorization yourself if the target looks like third-party infrastructure.
FAQ
What does the penetration-testing-with-strix skill do?
Pentest a web app, API, codebase, repository, URL, domain, or IP with Strix — autonomous AI penetration testing that exploits and proves vulnerabilities (OWASP Top 10 and beyond — injection, XSS, SSRF, auth/access-control flaws, IDOR, business logic) instead of just flagging them. Runs self-hosted with the open-source CLI or via the managed app.strix.ai cloud, and returns validated findings with proof-of-concept exploits (Markdown, JSON, CSV, SARIF). Use when the user asks to pentest, hack, security-scan, security-audit, or find vulnerabilities in an app, API, website, or repo.
How do I install penetration-testing-with-strix?
Run npx skills add https://github.com/usestrix/strix --skill penetration-testing-with-strix in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/penetration-testing-with-strix/ (personal) or .claude/skills/penetration-testing-with-strix/ (project).
Which AI agents can use penetration-testing-with-strix?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is penetration-testing-with-strix safe to install?
Security partners have reviewed it: Gen Agent Trust Hub flagged risks; Socket flagged items to review; Snyk flagged items to review. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains penetration-testing-with-strix?
It is published by usestrix in usestrix/strix. It has 16,910 recorded installs.
More from usestrix/strix
fix-security-vulnerabilities-with-strix
usestrix/strix
Fix security vulnerabilities found by a Strix pentest (open-source CLI or app.strix.ai cloud) — triage by severity, patch the root cause rather than the symptom, and re-run Strix to prove each fix actually closes the exploit. Handles injection, XSS, SSRF, broken access control, IDOR, and other validated findings. Use after a Strix scan reports findings, or when the user asks to remediate, patch, or fix security issues from a strixruns report, vulnerabilities.json, findings.sarif, or a cloud scan.
ci-security-scanning-with-strix
usestrix/strix
Add security scanning to CI/CD with Strix — GitHub Actions, GitLab CI, or any pipeline — so every pull request gets a diff-scoped AI pentest that blocks vulnerable code before it merges, with results as PR comments and SARIF uploaded to code scanning. Covers both the self-hosted open-source CLI (runs in your runner) and the managed app.strix.ai platform (GitHub/GitLab app or API, no runner infra). Use when the user asks to add security scanning, SAST/DAST, pentesting, vulnerability checks, or automated security review to their CI pipeline, pre-merge gate, or PR workflow.
managed-pentesting-with-strix
usestrix/strix
Run a managed pentest of a web app, API, repository, or local workspace on the app.strix.ai platform with the strix cloud CLI or REST API — no local Docker or LLM key needed. Safely review and upload local source, register assets, launch and poll scans, triage vulnerabilities, export SARIF, download compliance reports, start PR reviews, buy credits, and set up schedules or webhooks. Use for managed, continuous, scheduled, team-tracked, or sandboxed-agent security testing.
web-app-penetration-testing
usestrix/strix
Pentest a web app or website end to end — black-box testing of a live URL, staging environment, or local dev server that finds and exploits real vulnerabilities (auth bypass, broken access control, IDOR, injection, XSS, SSRF, business logic) and proves each one with a working proof-of-concept instead of a signature match. Runs with Strix, either the self-hosted open-source CLI or the managed app.strix.ai cloud. Use when the user asks to pentest, hack, security-test, or audit their web app, website, web application, or staging site.
api-security-testing
usestrix/strix
Security-test a REST, GraphQL, or gRPC API with Strix — autonomous agents that enumerate endpoints from an OpenAPI/GraphQL schema (or by crawling), then actually exploit the API-specific vulnerability classes in the OWASP API Security Top 10 (2023) — broken object-level authorization (BOLA/IDOR), broken object property level authorization (excessive data exposure and mass assignment), broken function-level authorization, unrestricted resource consumption, SSRF, injection, and auth/token flaws. Every finding comes with a working proof-of-concept request. Use when the user asks to pentest, security-test, audit, or find vulnerabilities in an API, endpoint, or backend service.
owasp-top-10-testing
usestrix/strix
Test an application against the OWASP Top 10 with Strix — autonomous AI agents that attempt real exploits for each category of the current OWASP Top 10:2025 (broken access control including SSRF, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, integrity failures, logging and alerting failures, mishandling of exceptional conditions) and report only what they could actually prove, mapped back to the category with a proof-of-concept. Also covers the OWASP API Security Top 10 (2023). Use when the user asks for an OWASP Top 10 assessment, OWASP compliance testing, or a security review mapped to OWASP categories.
Popular security skills
azure-compliance
microsoft/azure-skills
Run Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: compliance scan, security audit, BEFORE running azqr (compliance cli tool), Azure best practices, Key Vault expiration check, expired certificates, expiring secrets, orphaned resources, compliance assessment.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized reprooutputs/ files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.
seo-audit
coreyhaines31/marketingskills
When the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tags review," "SEO health check," "my traffic dropped," "lost rankings," "not showing up in Google," "site isn't ranking," "Google update hit me," "page speed," "core web vitals," "crawl errors," "indexing issues," "stuck on page 2," "striking distance keywords," "title tag rewrite," "low CTR," "local SEO," "Google Business Profile," or "map pack." Use this even if the user just says something vague like "my SEO is bad" or "help with SEO" — start with an audit. For building pages at scale to target keywords, see programmatic-seo. For adding structured data, see schema. For AI search optimization, see ai-seo.
firebase-security-rules-auditor
firebase/agent-skills
Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
audit
pbakaus/impeccable
Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
competitors
coreyhaines31/marketingskills
When the user wants to create competitor comparison or alternative pages for SEO and buyer-facing use. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' 'competitive landing pages,' 'how do we compare to X,' 'competitor teardown,' 'audit our competitor pages,' 'are our comparison pages out of date,' or 'competitive asset audit.' Use this for any content that positions your product against competitors. Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. For auditing existing claims (not researching competitors from scratch, which is competitor-profiling; not technical SEO on these pages, which is seo-audit), use the asset audit here. For internal battle cards and sales-specific competitor docs, see sales-enablement.