Strix: the open source AI that breaks into your own app and proves it
Most security scanners hand you a list of maybes. Strix will not report a vulnerability until it has actually exploited it and produced a working proof of concept.
Strix is an open source security testing tool that runs autonomous agents against your own application the way a human penetration tester would. It is Apache licensed, it has somewhere around 39,000 stars, and the design choice that makes it worth writing about is not the AI part.
Before anything else: this is a tool for testing systems you own or have written permission to test. Pointing it at anything else is illegal in most countries regardless of intent, and that is not a disclaimer, it is the entire boundary of legitimate use.
The problem it addresses
Traditional scanners produce findings, and a large share of those findings are not real. The scanner sees a pattern that resembles a vulnerability and reports it, and somebody then spends an afternoon determining that it was fine. Teams learn to distrust the output, and the report becomes something you generate for compliance and do not read.
False positives are not a minor annoyance. They are the reason security tooling gets ignored.
What Strix does differently
It will not report a vulnerability until it has exploited it. Every finding arrives with a reproducible proof of concept, which means the question changes from "is this real" to "how do we fix it". That is a much better question to hand a developer.
The agents work with the tools a person would use: intercepting HTTP requests, driving a real browser for anything client side, opening a shell, and writing custom exploit code in a sandbox when the situation needs something bespoke. Coverage runs across the OWASP Top 10 and past it, including injection of several kinds, SSRF, XXE, IDOR, cross-site scripting and request forgery, prototype pollution, and business logic flaws.
That last category is the one I find most interesting, because business logic bugs are exactly what pattern matching cannot find. Nothing about the request is malformed when someone changes a quantity to a negative number and receives a refund. The flaw is that the sequence is allowed, and finding it requires understanding what the application is for.
Where the caution sits
Running it against your own systems is legitimate. It is also not free of consequence, and anyone treating it as a button to press should think about a few things first.
It is an agent that exploits things. Run it against production and it may do something you did not want done, because a successful exploit is a real action against a real system. A staging environment with realistic data is the right target.
Self-hosting means bringing your own model API keys, which means the contents of your application, including whatever the agents read along the way, go to whichever model provider you configured. If you handle other people's data, that is a decision to make deliberately rather than by default. There is a hosted version, which moves the same question rather than removing it.
And it does not replace a human assessment, whatever anyone says. It finds a class of bug very well. Judgement about what matters in your specific business, and about the things that are only wrong in context, is still a person's job.
Who should look at it
Small teams shipping web applications without a security budget, which is most teams. The realistic alternative for that group is not a professional penetration test, it is nothing at all, and a tool that proves its findings is a substantial improvement on nothing.
If you build on Shopify, the relevant surface is usually not the platform itself but whatever you have added around it: custom apps, webhook endpoints, anything holding an API token, anything you wrote. That is the part worth pointing a tool at.