Strix

You will like this if you have shipped a web app and never had a pentest because pentests cost what a hire costs: point it at your code, it stands the app up, probes it, and hands back findings with a working exploit attached, which is the daily trait that separates it from a linter with opinions. A finding you can reproduce is a finding you can prioritise.

You will not like the wait or the bill on a big target, because a full run is many model calls. Pick it before a launch and after a big refactor. Pick CodeRabbit or Greptile for every pull request.

The risk is that the product is an attacker by design. The README carries its own warning that testing anything you do not own or have written permission for is illegal in most jurisdictions. An agent that misreads a hostname is not a bug report; it is an incident. The claim of working proofs of concept and no false positives arrives without a published false-positive rate to check it against.

The consequence: scope in writing, staging targets only, and a person reading the plan before the run. What it does right is tooling: a real HTTP interception proxy, Caido, rather than a model pretending to be one.

The architecture is unusual in that verification is the product. 1. Context: reconnaissance agents map the target and static and dynamic analysis read the code. 2. Planning: a graph of specialised agents, one family per attack class, run in parallel and share what they find. 3. Actions: a browser for XSS, CSRF and clickjacking, a shell and a Python runtime for exploit code. 4. Verification: the exploit is executed against the sandboxed application, so the check is empirical rather than a second model opinion.

No benchmark is published, and the row is unverified beyond the README. The observation: a system whose success criterion is a running exploit cannot easily hallucinate a pass.

This one has a business, which is rare on this board. The site lists SOC 2 Type II and ISO 27001, an enterprise tier with zero data retention so source never trains a model, and a logo wall that includes AWS, PayPal, Uber, Cisco, Ford and Pfizer. Security buyers pay for certifications and references before features, and the company has both.

Pricing power is strong in structural terms: a pentest is already a budget line, so the price can rise into it. Moat: the reference list and the compliance paperwork, both slow to copy. Likely acquirer: a platform security vendor, Snyk or GitLab shaped, or a cloud buying an AppSec line. Position: long, and note the open-source CLI is the funnel, not the product.

The demo is an agent finding an IDOR. Procurement cares about the workflow: a GitHub Actions job runs strix -n -t ./ in quick-scan mode on pull requests, which is the shape of a control an auditor recognises. The enterprise tier is self-hosted, with dedicated support, custom SLAs and a priority Slack channel, and integrations reach Jira, Linear, GitLab and Bitbucket.

The cost line is blank, because the cloud pricing page is not public, and sixty seats of anything priced by conversation is a quarter of negotiation. Legal must sign the scope, since the tool attacks what it is pointed at. Approved with conditions: a written target list and a quoted number.

Apache-2.0 and configured by environment variables I can read in one screen: STRIX_LLM picks the model, LLM_API_KEY the key, and LLM_API_BASE aims it at my own endpoint, so a local model can run the recon while a bigger one writes the exploit. The default is openrouter/z-ai/glm-5.3, which tells me the authors optimise for cheap, not for a single vendor.

MCP servers go in ~/.strix/mcp-servers.json, stdio or HTTP, with tool filtering so I can hand it a database server and hide the write tools. Settings persist in ~/.strix/cli-config.json. The cloud is optional. I can fork this and I would.