Strix is an open-source penetration-testing tool that uses autonomous AI agents to inspect applications, exploit vulnerabilities, and validate findings with working proofs of concept. Developers and security teams use it for application security testing, bug-bounty research, remediation guidance, reporting, and automated checks in development pipelines.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add usestrix/strix --skill web-app-penetration-testinggit clone --depth 1 https://github.com/usestrix/strixWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/usestrix/strix/web-app-penetration-testing)<a href="https://agentmods.dev/skills/usestrix/strix/web-app-penetration-testing"><img src="https://agentmods.dev/badge/skills/usestrix/strix/web-app-penetration-testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/usestrix/strix/web-app-penetration-testing"><img src="https://agentmods.dev/badge/skills/usestrix/strix/web-app-penetration-testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket warn
- Snyk warn
- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00129 | $0.01004 |
| Opus 5.5 | $0.00052 | $0.00402 |
| Sonnet 5.5 | $0.00026 | $0.00201 |
| Haiku 4.5 | $0.00013 | $0.00100 |
Grade A, and why
web-app-penetration-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pentest a web application
Black-box (and optionally source-assisted) penetration testing of a running web app with Strix's autonomous agents. Every reported finding is validated with a working exploit, so there are no signature-based false positives to triage.
Install, LLM setup, all CLI flags, and the managed-cloud alternative are covered in the penetration-testing-with-strix skill — read it if the target is not a running web app, or if strix --version fails. For a run with no Docker and no LLM key, the same binary drives the managed platform: strix cloud login, then strix cloud scans start ... (details in managed-pentesting-with-strix). This skill is the web-app-specific workflow.
1. Confirm authorization and scope
Before running anything, establish:
- The target is the user's (or they are explicitly authorized to test it). Never pentest a third-party site on a hunch.
- Which environment. Prefer staging over production; agents send real exploit payloads and will create/modify data.
- Out-of-scope paths — payment flows, mass-email endpoints, admin destructive actions, third-party SSO providers.
- Credentials. Most real vulnerabilities live behind login. Without a test account, the agents only ever see the marketing surface.
Ask for anything missing rather than guessing.
2. Run the scan
strix -n -t https://staging.example.com --max-budget 20 \
--instruction "Test account: [email protected] / <password>. In scope: /app/*, /api/*. Do not touch /billing or send email. Focus on access control between the two seeded orgs."
Notes that matter for web apps specifically:
- Give it credentials via
--instruction(or--instruction-filefor anything long), including how to log in if the flow is unusual (magic link, SSO, MFA-exempt test user). - Two accounts beat one. Multi-tenant IDOR and broken-access-control bugs — consistently the highest-impact class in web apps — can only be proven when the agent can attempt cross-account access.
- Add the repo for white-box depth when you have the source:
-t https://github.com/org/app -t https://staging.example.com(or a local path). Source access materially improves coverage of business-logic and authorization flaws. - Localhost works. Point at
http://host.docker.internal:3000(Docker Desktop) so the sandbox can reach a dev server on the host. --scan-mode quickfor a fast dev-loop pass,standard(~30 min) for a normal review,deepfor pre-release assurance. Always set--max-budget.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed 2e8df0b92339
- 1mo ago First seen · 55 lines · 129 tokens per session scan A 7b345118ed8e
web-app-penetration-testing is a skill published in the GitHub repository usestrix/strix (68,829 stars, last pushed today), licensed Apache-2.0. It adds 129 tokens to every session and 1,004 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
cis-aws-foundations-3.2.3
Ensure that RDS instances are not publicly accessible.
cis-aws-foundations-2.14
Ensure IAM policies that allow full ":" administrative privileges are not attached.
cis-aws-foundations-3.2.1
Ensure that encryption-at-rest is enabled for RDS instances.
cis-aws-foundations-3.3.1
Ensure that encryption is enabled for EFS file systems.
cis-aws-foundations-4.1
Ensure CloudTrail is enabled in all regions.
cis-aws-foundations-4.3
Ensure AWS Config is enabled in all regions.