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 application-security-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/application-security-testing)<a href="https://agentmods.dev/skills/usestrix/strix/application-security-testing"><img src="https://agentmods.dev/badge/skills/usestrix/strix/application-security-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/application-security-testing"><img src="https://agentmods.dev/badge/skills/usestrix/strix/application-security-testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket warn
- Snyk pass
- 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.00125 | $0.00999 |
| Opus 5.5 | $0.00050 | $0.00400 |
| Sonnet 5.5 | $0.00025 | $0.00200 |
| Haiku 4.5 | $0.00013 | $0.00100 |
Grade A, and why
application-security-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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Application security testing
Entry point for "make my application secure" requests, where the target is not yet a single URL or repo. The job here is to pick the right test per asset, run it, and produce one ranked plan — not to run everything at maximum depth.
Install, LLM setup, all CLI flags, and the managed-cloud path live in the penetration-testing-with-strix skill. Read it first 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).
Only test assets the user owns or is authorized to test. Confirm authorization before the first run, and prefer staging over production, because the agents send real exploit payloads and can change data.
1. Map the assets
Ask (or read from the repo) and write the answers down before scanning:
- Source — one repo, a monorepo, several services? Which languages/frameworks?
- Running environments — is there a staging deployment? A public production site? A local dev server only?
- APIs — REST, GraphQL, gRPC? Is there an OpenAPI/GraphQL schema?
- Authentication — can you get two test accounts in different tenants? Most high-impact bugs need them.
- Constraints — out-of-scope paths, whether production may be touched, budget and wall-clock limits.
If there is no staging environment and production is off limits, say so early. A code-only review is still valuable, but it cannot prove exploitability against a live app.
2. Pick the right test per asset
| Asset | Skill to use |
|---|---|
| Repository or working tree | find-security-vulnerabilities-in-code |
| Live web app or staging site | web-app-penetration-testing |
| REST/GraphQL/gRPC API | api-security-testing |
| Assessment mapped to OWASP categories | owasp-top-10-testing |
| Every pull request, continuously | ci-security-scanning-with-strix |
| No Docker, no LLM key, or a report an auditor will accept | managed-pentesting-with-strix |
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 b3041c800a9a
- 1mo ago First seen · 67 lines · 125 tokens per session scan A 5aad863f88d7
application-security-testing is a skill published in the GitHub repository usestrix/strix (70,805 stars, last pushed today), licensed Apache-2.0. It adds 125 tokens to every session and 999 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
potpie-debug-memory
Use while debugging or troubleshooting failures, flaky tests, incidents, production alerts, CI failures, local dev setup issues, repeated bugs, prior fixes, failed attempts, and verification history.
potpie-project-preferences
Use before writing, modifying, reviewing, refactoring, or testing code so repo/project preferences surface: error handling, file structure, frameworks, logging, dependency choices, testing, security, API style, and naming. Also use after code work when a reusable project preference should be recorded.
performing-soap-web-service-security-testing
Perform security testing of SOAP web services by analyzing WSDL definitions and testing for XML injection, XXE, WS-Security bypass, and SOAPAction spoofing.
performing-graphql-depth-limit-attack
Execute and test GraphQL depth limit attacks using deeply nested recursive queries to identify denial-of-service vulnerabilities in GraphQL APIs.
testing-llm-prompt-injection-and-jailbreaks
Testing LLM-backed applications, chatbots, and AI agents for direct and indirect prompt injection, jailbreaks, system-prompt leakage, and tool/agent abuse during authorized penetration tests, using structured payload families and reliable confirmation signals.
cis-aws-foundations-3.2.3
Ensure that RDS instances are not publicly accessible.