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 agentmods add skills/usestrix/strix/find-security-vulnerabilities-in-codenpx skills add usestrix/strix --skill find-security-vulnerabilities-in-codegit clone --depth 1 https://github.com/usestrix/strixWhat 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 | $0.00129 | $0.00942 |
| Opus 5 | $0.00064 | $0.00471 |
| Sonnet 5 | $0.00026 | $0.00188 |
| Haiku 4.5 | $0.00013 | $0.00094 |
Grade A, and why
find-security-vulnerabilities-in-code 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 yesterday.
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 — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Find security vulnerabilities in code
White-box security review with Strix: the agents read the source to build a model of routes, sinks, and authorization checks, then attempt real exploitation. Findings come with a proof-of-concept, so the output is a short list of proven issues rather than the hundreds of "potential" hits a pattern-matching scanner produces.
Install, LLM setup, all flags, and the managed-cloud path are in the penetration-testing-with-strix skill.
Run it
# Local working tree
strix -n -t ./ --scan-mode standard --max-budget 15
# A GitHub repo directly
strix -n -t https://github.com/org/app --max-budget 15
# Monorepo: point at the service that matters, not the whole tree
strix -n -t ./services/checkout --max-budget 20
# Only what a branch changed (whole-repo review is wasteful on a large repo)
strix -n -t ./ --scope-mode diff --diff-base origin/main --max-budget 10
A local path is mounted into the sandbox writable, so the agents can modify it. Run against a clean checkout.
Two things sharply improve results:
- Add a running instance of the app.
-t ./ -t http://host.docker.internal:3000lets the agents confirm exploitability against live behavior instead of reasoning about it statically — this is the difference between "this looks unsafe" and a validated finding. If nothing is running, static-only findings should be described as unconfirmed. - Scope the review. Point at the risky subtree and say what matters:
Tenancy model, trust boundaries, and which inputs are attacker-controlled are things the agents cannot infer reliably — tell them.strix -n -t ./services/api --max-budget 15 \ --instruction "Focus on the authorization layer in src/auth and every route under src/routes/admin. Multi-tenant app: tenant id comes from the JWT. Flag any query that filters by object id without also filtering by tenant."
Reviewing a pull request instead of the whole repo
For diff-scoped review of a branch or PR (and blocking merges on findings), use ci-security-scanning-with-strix — it covers diff scoping, PR comments, and SARIF upload to GitHub code scanning. The managed platform can also review PRs directly via API (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.
- yesterday First seen · 63 lines · 129 tokens per session scan A 2633d6b57540
find-security-vulnerabilities-in-code is a skill published in the GitHub repository usestrix/strix (59,426 stars, last pushed 3d ago), licensed Apache-2.0. It adds 129 tokens to every session and 942 once invoked, about $0.0006 per session on Opus 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.