Strix and the twenty-thousand-dollar pentest

A prospect worth more than your last three deals combined sends over a security questionnaire before they will sign, and somewhere in the spreadsheet is the line that stops everyone: attach your most recent penetration test. You do not have one. You call two firms, and the quote for testing a single web application comes back somewhere between ten and thirty thousand dollars, with a lead time of a few weeks before anyone even starts. Strix is an open-source AI penetration testing agent that runs the same class of assessment against your app on a Tuesday afternoon, finds the real vulnerabilities, and proves each one with a working exploit, for the price of the model tokens it burns getting there. The catch is not in the finding. It is in what a report you ran on yourself is actually worth to the person who asked for it, and that is the part worth your time.

What Strix actually is

Strix, from a company of the same name, is on GitHub at around thirty-nine thousand stars with four thousand forks, and it got most of that in a hurry: it has been adding several thousand stars a week through the summer, which is the kind of curve that means genuine adoption rather than a launch-day spike. There are 521 commits and sixteen tagged releases behind it, the latest landing in June 2026, so it is not a weekend project that stalled. It is licensed Apache-2.0, which is about as permissive as licenses get. You can run it commercially, wire it into your own pipeline, and never ask anyone's permission.

Strip away the security jargon and here is what it does. You point it at a target, either a folder of your own source code or a live URL for one of your own applications, and it behaves like a penetration tester instead of a scanner. A traditional vulnerability scanner reads your code or pokes your endpoints and hands you a list of things that might be wrong, most of which are not. Strix runs the application, tries the attack, and only reports the vulnerability if it can actually exploit it and show you the proof. That distinction is the whole point. The output is not a thousand-line report of maybes. It is a shorter list of things that are genuinely broken, each with a working proof-of-concept and remediation guidance for closing it.

Under the hood it carries the same toolkit a human tester uses: an HTTP interception proxy for manipulating requests, a real browser for testing cross-site scripting and authentication bypass, a sandboxed Python runtime for writing exploits on the fly, and reconnaissance tooling for mapping what your app exposes. It covers the standard catalogue of web vulnerabilities, the OWASP Top 10 and then some, from SQL injection and broken access control to server-side request forgery and business-logic flaws. It can also run several specialized agents at once, one on reconnaissance, one on exploitation, coordinating like a small red team. It is built on top of a stack of well-known open-source projects, so it is not reinventing the primitives, it is orchestrating them with a model in the driver's seat.

There are two ways to run it, and the honest article has to name which is which. The self-hosted path is a command-line tool: you need Docker running and an API key from a model provider, you run an install script, and then a single command like strix --target ./your-app kicks off a scan. The hosted path is app.strix.ai, where you sign up for free, connect a repository or a domain, and let their infrastructure run it. The hosted version adds one-click fix pull requests, continuous scanning that reruns as you deploy, and connections to the tools you already use. So the answer to "could a non-engineer use this" is: through the hosted platform, mostly yes; through the CLI, you need to be comfortable with a terminal and Docker. Say that plainly to anyone you hand it to.

Why a small software shop should care

The reason this matters is the shape of the thing it stands in for. A penetration test is not a product you buy once and own. It is a recurring event, driven from the outside by people who will not take your word for your own security. A prospect's procurement team wants one. A SOC 2 or ISO 27001 audit wants one every year. A cyber insurance renewal increasingly wants one. And the market that supplies them is priced accordingly.

The old way is a boutique firm that scopes your app, runs a two-week engagement, and delivers a PDF, for the ten to thirty thousand dollars quoted above per application. The newer way is a penetration-testing-as-a-service platform like Cobalt, which runs on a credit model at roughly eighteen hundred dollars a credit, where a single web-application test consumes ten to twenty credits. That puts one test in the eighteen to thirty-six thousand dollar range, and a typical annual program at fifteen to forty thousand before platform fees. These are not enterprise-only numbers. They land on a twelve-person software company the first time it tries to sell to anyone with a real security team, and for that company the money is only half the pain. The other half is that security testing is the internal work that never gets prioritized. There is no engineer to spare, so the app ships unexamined until an outside deadline forces the invoice.

That is the gap Strix drops into, and it lands on both of our readers. The first is the technical-enough operator at a small software company, the person who can follow a Docker guide and owns the app but has never been able to justify a five-figure security line item between funding events. They can now run a real assessment against their own staging environment this week, read the validated findings, and fix the genuine holes before a customer's tester finds them. The second is the RevOps or IT lead at a company big enough to have been quoted by a firm, who took the number to finance and watched it stall. They can run Strix continuously between the paid engagements, so the annual test stops being the only time anyone looks. In both cases the displaced cost is not just the invoice. It is the weeks of waiting, and the internal ticket that was never going to reach the top of the queue.

The honest take

Free is carrying an enormous amount of weight in that pitch, and this is the series where that word does the most damage. Here is where the cost actually lives.

Start with the tokens, because the tool is not free to run, it is free to download. Strix uses your own model API key, it favors the strongest available models, and it is set to think hard by default across multiple agents. A thorough scan of a real application is not one model call, it is thousands, as the agents probe, write exploits, and retry. Depending on the app and the model you point it at, a single serious run can cost anywhere from a few dollars to well into the tens or low hundreds, and that meter runs every time you scan. That is still an enormous discount against a twenty-thousand-dollar engagement. It is not zero, and it scales with exactly the thoroughness you actually want.

Then the setup, told straight. The hosted platform is genuinely quick. The self-hosted CLI is a couple of hours for someone comfortable in a terminal: install Docker, get the install script running, set your provider key, and understand enough about scan scope to point it at the right target without knocking something over. This is at the upper edge of what a non-coding builder can do, which means it is doable and it is not casual, and if nobody on your team has ever used Docker, budget more.

Now the part that the "runs the same class of test" framing quietly skips, and it is the most important sentence in this piece. A penetration test that satisfies an auditor or a customer is not just a list of findings. It is an independent attestation, a named third party putting their reputation behind the statement that they looked and here is what they found. When a prospect's security team asks for your most recent pentest, what they are really asking for is evidence that someone who does not report to you did the looking. A report you generated by running an AI agent against your own code does not answer that question, no matter how good the findings are, because you ran it. So Strix does not replace the auditor's signature. What it replaces is everything that used to happen before the signature: the findings work, the fixing, the continuous checking between annual tests, and the expensive first pass where a firm charges you full price to discover the obvious things you could have caught yourself. Walk into the paid engagement with those already closed and you are paying the firm for depth and independence, not for catching your own low-hanging fruit. That is a real saving. It is just a different one than "cancel the pentest."

There is a depth limit too. Automated agents are strong on the vulnerability classes that have a shape, injection, access control, the OWASP catalogue. They are weaker on the business-logic flaws that require understanding what your specific application is for, the "why can a user in this state do that thing" problems that a thoughtful human tester lives for. Strix will find more than a scanner and less than your best human, and pretending otherwise is how people get burned.

Mind the data path, because it is real. When Strix runs source-aware, your code travels to whatever model provider you configured, inside the prompts, on every run. When it runs against a live target, your application traffic does too. For most software shops that is an acceptable trade for the capability. For anyone in a regulated trade, or anyone whose code is the entire business, it is a conversation to have with whoever owns that risk before the first scan, not after. The Apache license and the self-host option mean you can keep the orchestration on your own infrastructure, but the model call is still the exit unless you also run a local model, which raises the hardware cost you were trying to skip.

And there is a warning that comes stapled to the tool itself: only test what you own or have written permission to test. Strix does not just look, it exploits, and pointing an autonomous attacker at something you do not control is a way to cause real damage and real legal exposure. Run it against staging, not production, until you know exactly what it does, and never against a target that is not yours.

Last, the maintainer question that hangs over every open-core project. Strix is a venture-backed company, and the hosted platform is the business the free CLI feeds. That funds the fast pace, and it means the open-source tool's job is partly to sell the paid one, so the most polished features tend to land in the platform first. The Apache core is yours to keep and fork if the company changes course, but forking an offensive-security orchestration engine means owning the upkeep of something you did not build. The commit history says that is not this year's problem. It does not promise it is never anyone's.

The decision you now own

The pentest invoice used to make the decision for you: security testing was an event you scheduled once a year because that was all you could afford, and the app went unexamined the other fifty-one weeks. Strix removes the money as the reason not to look, which turns the annual test from the only time anyone checks into the last line of defense behind a habit. The question is no longer whether you can afford to test your own software. It is whether you are willing to know what you would find, on a Tuesday, before a customer's tester finds it first.