I Ran an Autonomous AI Hacker on My Own Site: An Honest Strix Review
I pointed Strix, the most popular open-source AI penetration testing agent, at my own website. It found nothing, cost about $17 in tokens, and got my Anthropic key auto-disabled. Here is the honest account: how it works, what it takes to run, why blackbox results are shallow, and what an AI pentest really costs.

I pointed an autonomous AI hacker at my own website to see whether the 2026 hype was real. Ten minutes and roughly seventeen dollars in API tokens later, Anthropic automatically disabled my API key for the usage spike. The tool never found a single confirmed vulnerability on my site, but that is not because my site is bulletproof, and it is not because the tool is bad. This is the honest, unglamorous account of running Strix, the most popular open-source AI penetration testing agent, against a real target: what it is, how it works, what it actually found, and what it costs when nobody is watching the meter.
What Strix actually is
Strix is an open-source (Apache-2.0 licensed) autonomous penetration testing tool built by usestrix. Instead of following a fixed rulebook like a traditional scanner, it runs a team of AI agents that reason about a target, chain tools together, and try to exploit what they find. It is the most starred open-source project in its category and part of a wave of agentic security tools that reached a tipping point in 2026: as Help Net Security reported, these agents "act just like real hackers," running code dynamically and validating findings with actual proof-of-concept exploits.
The key word is autonomous. A normal vulnerability scanner (including our own free website scanner) reads your headers, certificates, DNS, and page source and reports what looks wrong. It does not attack you. Strix is the opposite category: it spins up a browser to test cross-site scripting, opens an interactive shell, and writes and runs Python exploit code inside a sandbox. That difference matters enormously for how, when, and whether you can use it, which we will get to.
To place it in context, independent research cataloguing 39 of these tools in 2026 puts Strix among the most reliable open-source options, alongside commercial agents like XBOW, which reached the top of HackerOne's global bug-bounty leaderboard, and academic projects like PentestGPT. The category is real and improving fast. The question for a practitioner is not "is this impressive" (it is) but "what does it take to get value out of it."
How it works under the hood
When you launch a scan, Strix does not send a single prompt to an LLM. It deploys a small org chart of specialized sub-agents, each with a job, all coordinated by a lead agent. In my run it spun up six of them: reconnaissance and attack-surface mapping, authentication and authorization testing, injection testing, server-side request forgery and open-redirect testing, cross-site scripting, and a rate-limiting and business-logic agent. Each one runs inside a Docker sandbox container and calls out to a commercial LLM (OpenAI, Anthropic, Google, or others) that you supply and pay for.
flowchart TB
U["You: strix -t your-app.com"] --> L["Lead agent<br/>(plans + coordinates)"]
L --> R["Recon &<br/>attack-surface mapping"]
L --> A["Auth / authz<br/>(IDOR, bypass)"]
L --> I["Injection<br/>(SQLi, NoSQL, cmd)"]
L --> S["SSRF &<br/>open redirect"]
L --> X["XSS<br/>(reflected/stored/DOM)"]
L --> B["Rate limiting &<br/>business logic"]
R --> P["Confirm with<br/>proof-of-concept"]
A --> P
I --> P
S --> P
X --> P
B --> P
P --> Rep["Validated findings<br/>+ report"]The design goal is to only report vulnerabilities the agent could actually prove, so you get proof-of-concept exploits instead of a wall of maybe-issues. That is the pitch, and on a target with real holes it delivers: an independent benchmark that ran Strix against a deliberately vulnerable server (14 planted vulnerabilities, scored by severity) had it surfacing a meaningful share of them across 18 different LLM models. The catch, as I found out, is that "point it at the target" is doing a lot of work in that sentence.
What it actually takes to run
Strix is a command-line tool, not a website you visit. Getting it running means: a working Docker install, pulling its sandbox image (10.9 GB in my case), an install script, and an LLM API key exported as an environment variable. The basic invocation is simple:
# after installing and starting Docker
export STRIX_LLM="anthropic/claude-sonnet-4-5"
export LLM_API_KEY="your-api-key"
strix -n --target https://your-own-app.com --scan-mode quickThat your-own-app.com is not a throwaway detail. Strix's own documentation and README are blunt about it: "Only test apps you own or have permission to test. You are responsible for using Strix ethically and legally." This is not boilerplate. Pointing an autonomous exploitation agent at a site you do not control is unauthorized computer access, which is a crime under the US Computer Fraud and Abuse Act and equivalent laws elsewhere. A permission checkbox on a public tool does not create authorization. This is exactly why you will never see a legitimate "scan any URL" version of a tool like this, and why I ran it only against my own property.
Why I did not point it at production
My first instinct was to scan the live site. That would have been a mistake, and it is worth explaining why, because it applies to anyone testing their own app. A production site is full of endpoints that do things: the contact form sends real email, the comment and chat features write to a real database and (in my case) call a paid AI API on every request, click-tracking logs to a database, and the whole thing sits behind a bot-detection layer that would happily flag my own domain. An autonomous agent that pokes every input will trigger all of that: junk emails to myself, junk database rows, extra token spend, and possibly a temporary block on my own site.
So I stood up an isolated copy instead: the same application code running locally, with the database, email provider, and application-side AI keys disabled. That way the agent exercised my real routing and application logic (where genuine bugs live) without any of the messy side effects. If you take one operational lesson from this piece, it is this: test a disposable or isolated instance, never the money-making production system.
What Strix found on my site: the honest answer
Zero confirmed vulnerabilities. And you should not read that as a clean bill of health, because the run had three real limitations that shaped the result.
It never found my real endpoints
Running blackbox (no source code), the agent guessed flat, conventional API paths: it tried /api/qa, /api/vulnerability-scanner, and /api/affiliate and got 404s, because my actual routes are nested one level deeper (/api/qa/questions, /api/tools/vulnerability-scanner, /api/affiliate/click). Out of roughly 1,350 requests it sent, more than 1,300 were 404s from fuzzing paths that do not exist, and only about 30 hit a real endpoint. The agent spent most of its budget knocking on doors that were not there.
Quick mode plus a budget cap equals a shallow pass
I ran the fastest scan mode and stopped the agent at turn 105 to cap the cost. That is enough for reconnaissance and surface probing, not for the deep, iterative exploitation where these tools earn their reputation. "No findings in a fast, shallow, blackbox pass" is a much weaker statement than "this application is secure."
The right way to run it is code-aware
The fix for the first two problems is the same: give Strix the source. Instead of a URL, you point it at a local directory or repository, and it reads your actual routes and logic instead of guessing at them. In practice that is a one-word change to the target:
# Point Strix at your local codebase instead of a live URL
cd /path/to/your-project
export STRIX_LLM="anthropic/claude-sonnet-4-5"
export LLM_API_KEY="your-api-key"
# Scan the whole project as source
strix -t ./
# Or, in CI, scan only what changed in a pull request (cheaper, faster)
strix -t . --scope-mode diff --diff-base origin/mainEverything else is the same as a URL scan: you still need Docker running and an API key exported. The difference is that Strix now reasons about your real code, so it does not waste budget fuzzing for endpoints that do not exist, and it can reach logic that a blackbox crawl never would. The --scope-mode diff flag is the one I would reach for in a pipeline: it limits the scan to files changed against a base branch, which keeps each run small enough to gate a pull request without a runaway bill. Pointed at code, with a standard or deep scan mode and a seeded test database behind it, this is where Strix becomes a genuine pre-release audit rather than a surface map. Blackbox against a stubbed-out running app, as I ran it, is the shallow end; the local-code mode is the deep end, and it is the one worth your tokens.
The part nobody screenshots: what it costs
This is where my run went sideways. In about ten minutes, quick mode made 105 model requests and consumed 5,716,615 input tokens. At Anthropic's list price for Claude Sonnet, that works out to roughly seventeen dollars, and the spike was sharp enough that Anthropic automatically disabled the API key. My experience is not an outlier. An independent benchmark of Strix across 18 models measured a single Sonnet run at about twenty dollars through the Claude API and $55.90 through a reseller, and concluded flatly that "you need to use big (and expensive) LLM models" for serious results, with no cheap sweet spot.
| Run | Model | Approx. cost | Source |
|---|---|---|---|
| My site, quick mode (stopped early) | Claude Sonnet | ~$17 (5.7M input tokens) | This article, first-hand |
| Vulnerable test server | Claude Sonnet (Claude API) | ~$20 | theaq.blog 18-model benchmark |
| Vulnerable test server | Claude Sonnet (via reseller) | $55.90 | theaq.blog 18-model benchmark |
| General guidance | Varies | Quick scans single digits, deep scans tens of dollars | Community reports |
Why so expensive? Agent loops are token-hungry in a way single prompts are not. Every turn resends a growing context (the plan, prior tool output, the page contents it has seen) to the model, and in my run none of it was cached, so the input-token count ballooned turn after turn. A "quick" scan of a small site cost seventeen dollars precisely because the agent kept re-reading everything it knew on every step. A deep scan of a large application is a different order of magnitude.
The practical takeaways: set a hard budget before you start, expect that a real audit costs real money, and treat the API key you hand it as a spending account, not a free resource. If your provider has spend limits or a separate low-limit key, use it. Learning this the way I did, through an automated key suspension email, is avoidable.
Who should actually use it, and who should not
Strix is a strong fit if you are a developer or security team testing your own code, especially as a pre-release or continuous check wired into CI against a staging environment with a budget cap. Pointed at source, it finds the classes of bugs it is built for (injection, broken authorization, SSRF, XSS) and hands you proof-of-concepts, which is a real acceleration over doing it by hand.
It is the wrong tool if you were hoping to scan a site you do not own, if you need a zero-cost check (it is free software but the LLM usage is not), or if you want a passive, non-invasive assessment. For that last case, a read-only scanner that checks headers, TLS, cookies, CORS, and known-vulnerable libraries without attacking anything is the safer everyday tool. That is the lane our free vulnerability scanner sits in, and it is the right first step before you ever reach for something as heavy as an autonomous agent.
How to run Strix without a surprise bill
- Only target your own asset. Your app, your infrastructure, or a system you have written permission to test. No exceptions.
- Isolate the target. Use a staging copy or a local build with email, database, and paid API integrations disabled or pointed at throwaway resources, so the agent cannot spam you, pollute data, or run up side costs.
- Give it the source. Run code-aware (
strix -t ./) so it maps your real routes instead of burning budget fuzzing for paths that do not exist. - Start in quick mode with a spend limit. Use a low-limit or separate API key, watch the token counter, and only move to standard or deep once you know how fast it burns.
- Read the proof, not just the label. The value is in the validated proof-of-concepts. Confirm each finding is real and reachable in your environment before you act on it.
Frequently asked questions
Is Strix free?
The software is free and open source under the Apache-2.0 license. The large language model it depends on is not: you supply and pay for an API key from a provider like Anthropic, OpenAI, or Google, and that token usage is the real cost. Expect a quick scan to cost single-digit to low-double-digit dollars and a deep scan to cost more.
How much does a Strix scan actually cost?
It depends on scan depth, target size, and model. My quick, early-stopped run on a small site consumed 5.7 million input tokens for roughly seventeen dollars. An independent 18-model benchmark measured a Sonnet run at about twenty dollars through the Claude API. Community guidance puts quick scans in the single digits and deep scans in the tens of dollars. Budget accordingly and use a spend-limited key.
Can I use Strix to scan any website?
No. Running an autonomous exploitation agent against a system you do not own or have explicit permission to test is unauthorized access, which is illegal under the Computer Fraud and Abuse Act and similar laws worldwide. Strix's own documentation says to test only apps you own or are authorized to test. Use it on your own code and infrastructure.
Did it find real vulnerabilities on your site?
No confirmed vulnerabilities, but that result is weak evidence: I ran it blackbox in the fastest mode and stopped it early to cap cost, and it never mapped my real (nested) API routes. On a deliberately vulnerable test server, independent testing shows Strix does surface real, proof-backed findings. Blackbox and shallow is not the same as an audit.
Is Strix better than a human penetration tester?
It is faster and far cheaper for the bug classes it automates, and it is excellent as a continuous, repeatable check. It is not a replacement for an experienced human on nuanced business-logic flaws, chained exploits, and context that requires understanding your product. The realistic framing is augmentation: run the agent constantly, bring in humans for depth.
Is it safe to run Strix against my production site?
Not recommended. It is an active exploitation tool that submits forms, hits APIs, and runs payloads, so against production it can send real emails, write junk data, incur real costs on any paid integrations, and trip your bot protection. Test an isolated or staging copy with integrations disabled instead.
The short version
Strix is a genuinely capable, free, open-source autonomous pentester, and the category it belongs to is going to matter more every year. It is also a command-line tool that needs Docker, a paid LLM key, and real care: point it only at your own systems, isolate the target, give it your source code so it does not waste budget guessing, start in quick mode with a spend limit, and expect a real scan to cost real money. My blackbox run found nothing and cost seventeen dollars and a disabled API key, which taught me more about how to use the tool than a clean report would have. Before you reach for an autonomous agent, run a passive website security scan first: it is free, it is safe to run on anything you own, and it catches the common problems without attacking a thing.
Security Hardening Checklist
Essential security controls for cloud-native applications and infrastructure.
No spam. Unsubscribe anytime.
Get weekly security insights
Cloud security, zero trust, and identity guides: straight to your inbox.
Continue Learning
SOC Analyst Level 1 Roadmap
Get job-ready for your first Security Operations Center role.
Microsoft Cloud Solution Architect
Cloud Solution Architect with deep expertise in Microsoft Azure and a strong background in systems and IT infrastructure. Passionate about cloud technologies, security best practices, and helping organizations modernize their infrastructure.
Share this article
Questions & Answers
Related Articles
Need Help with Your Security?
Our team of security experts can help you implement the strategies discussed in this article.
Contact Us