July 28, 2026
When AI Agents Learn to Hack Responsibly: A Complete Guide to Strix
Inside the Open Source Platform That Turns Autonomous AI Teams Into Real Penetration Testers

By Dr. Fadi Shaar
12 min read
Inside the Open Source Platform That Turns Autonomous AI Teams Into Real Penetration Testers
Traditional vulnerability scanning has always had an honesty problem. Point a static analysis tool at a codebase, and it will happily return a long list of potential issues, many of which turn out, after hours of manual verification, to be false alarms that never posed a genuine risk in the first place. Manual penetration testing solves that accuracy problem, since a skilled human tester actually confirms an exploit works before reporting it, but it comes with its own cost: engagements that take weeks to schedule and complete, priced well beyond what many smaller teams or fast moving engineering organizations can justify on a regular basis.
Strix is an open source project built specifically to close that gap. Rather than another scanner that flags theoretical weaknesses, it deploys autonomous AI agents that behave the way an actual penetration tester would: running an application dynamically, actively probing it for weaknesses, and then proving that a discovered issue is real by constructing a working proof of concept exploit rather than simply reporting a suspicion. The project is aimed squarely at developers and security teams who need fast, genuinely accurate security testing without either the scheduling overhead of a traditional manual pentest or the noisy false positive rate that has long plagued static analysis tooling.
What Sets Strix Apart From a Typical Scanner
The core distinction driving Strix's design is validation. Most vulnerability scanning tools identify a pattern that looks suspicious, a particular function call, a missing input sanitization step, a header that seems misconfigured, and report it as a potential issue, leaving the actual work of confirming whether that pattern represents a genuine, exploitable weakness entirely to a human reviewer afterward. Strix instead treats identification as only the first step. Once its agents flag a candidate vulnerability, they attempt to actually exploit it, constructing a real, working proof of concept that demonstrates the issue can genuinely be triggered, rather than stopping at a theoretical description of what might be wrong.
This distinction matters enormously in practice, since the single biggest complaint security teams tend to have about automated scanning tools is the sheer volume of low value alerts they generate, each requiring real human time to triage before anyone can tell whether it deserves attention at all. By validating findings through actual exploitation rather than pattern matching alone, Strix aims to hand a development team a list of issues that have already been confirmed as real, each backed by concrete reproduction steps, rather than a long, unsorted list of maybes.
Core Capabilities
Strix's overall capability set is organized around a fairly complete penetration testing workflow rather than a single, narrow scanning function.
A full pentesting toolkit ships built in, covering reconnaissance, exploitation, and validation phases out of the box, meaning a functioning security assessment does not require a separate collection of external tools stitched together manually before testing can even begin.
Multi agent orchestration allows teams of AI pentesters to collaborate on a single engagement, dividing the overall workload the way a real red team would, with different agents focusing on different phases or aspects of a broader assessment rather than one single agent attempting to handle reconnaissance, exploitation, and reporting all on its own.
Real exploit validation, already described above, is treated as a defining feature rather than an optional add on, specifically to avoid producing the same kind of unreliable, false positive heavy output associated with legacy vulnerability scanners.
A developer first command line interface presents findings in an immediately actionable form, paired with concrete remediation guidance rather than a bare technical description of the underlying flaw.
Automatic patch generation and reporting round out the feature set, capable of producing both suggested code fixes and compliance ready pentest reports suitable for handing directly to an auditor or a compliance team.
Common Use Cases
A handful of recurring scenarios illustrate where Strix tends to fit naturally into a development or security workflow.
Application security testing covers the most direct use case: detecting and validating genuinely critical vulnerabilities across an application before they can be discovered and exploited by someone with less benign intentions.
Rapid penetration testing addresses the scheduling problem inherent to traditional manual pentesting directly, aiming to compress an assessment that might otherwise take weeks down to a matter of hours, complete with a compliance ready report at the end of the process.
Bug bounty automation applies the same underlying validation approach to bug bounty research specifically, automating the process of finding candidate vulnerabilities and generating the proof of concept material needed for a faster, more credible report submission.
Continuous integration and deployment integration allows security testing to run automatically as part of an existing pipeline, specifically to catch and block vulnerabilities before they ever reach a production environment, rather than discovering them only after a release has already shipped.
Getting Started
Running Strix locally requires a running Docker installation, along with an API key from any supported large language model provider, including OpenAI, Anthropic, or Google, among others.
Installation itself is handled through a short installer script:
curl -sSL https://strix.ai/install | bashcurl -sSL https://strix.ai/install | bashOnce installed, configuring which AI provider and model to actually use is a matter of setting two environment variables:
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"With that configuration in place, running a first security assessment against a local project directory requires nothing more than pointing Strix at it directly:
strix --target ./app-directorystrix --target ./app-directoryThe very first run automatically pulls down the sandboxed Docker image Strix relies on for safely executing its testing activity, and results from every scan are written directly to disk under a strix_runs/<run-name> directory, giving a durable, inspectable record of exactly what happened during a given assessment.
The Hosted Strix Platform
Beyond the self hosted, open source command line tool, a fully hosted version of the platform is available directly at app.strix.ai, allowing anyone to sign up, connect their code repositories and web application domains, and launch a full penetration test within minutes rather than setting up local infrastructure first.
The hosted platform builds on the same core validation philosophy as the open source tool, ensuring every reported vulnerability includes a genuinely working proof of concept exploit along with clear reproduction steps, rather than a bare description of a suspected issue. A one click autofix capability goes a step further, generating AI produced security patches packaged directly as ready to merge pull requests, meaningfully shortening the gap between discovering a vulnerability and actually shipping a fix for it.
Continuous pentesting is offered as an always on capability, running vulnerability scanning consistently in step with an application's ongoing deployment cadence rather than treating security testing as a single, isolated event. Integrations extend across common DevSecOps tooling, including GitHub, GitLab, Bitbucket, Slack, Jira, Linear, and general purpose CI/CD pipelines, letting findings flow directly into whichever tools a given team already relies on for day to day work rather than living in a separate, disconnected dashboard. A continuous learning capability is also part of the platform's design, with the underlying AI intended to build on findings from past assessments, adapt over time to the specific characteristics of a given codebase, and gradually reduce its own false positive rate the longer it operates against a particular application.
The Offensive Security Toolkit Behind the Agents
Strix's agents are equipped with essentially the same category of tooling a professional penetration tester or ethical hacker would use during a real engagement, rather than a simplified, automation specific substitute.
An HTTP interception proxy, built around Caido, provides full request and response inspection, modification, and replay capabilities, enabling agents to analyze and manipulate traffic flowing between clients and target applications in real time. Browser automation extends these capabilities by driving a full-featured browser to validate vulnerabilities that depend on genuine browser behavior, including cross-site scripting (XSS), cross-site request forgery (CSRF), clickjacking, authentication bypasses, and other client-side attack scenarios that cannot be reliably reproduced through raw HTTP requests alone.
An interactive shell provides a controlled environment for exploit development, custom tooling, and post-exploitation activities when required. Complementing this, a Python-based exploit runtime allows agents to generate, execute, and validate custom proof-of-concept exploits instead of relying solely on predefined payloads or signature-based attack libraries. Reconnaissance and open-source intelligence (OSINT) capabilities automate target profiling through attack surface discovery, subdomain enumeration, technology fingerprinting, and exposed service identification, providing the contextual information needed to guide subsequent testing.
The platform further combines both Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), enabling comprehensive security assessments that examine source code alongside the behavior of running applications. Finally, a structured vulnerability knowledge base ties the entire workflow together by classifying findings using industry-standard frameworks such as CVSS and the OWASP Top 10. This ensures that discovered vulnerabilities are consistently categorized, accurately prioritized, and reported in a format that aligns with established security operations and remediation workflows.
The Range of Vulnerabilities Covered
Strix targets a genuinely broad range of security issue categories, spanning the OWASP Top 10 and extending well beyond it. Broken access control issues, including insecure direct object references, privilege escalation, and authentication bypass, are covered directly. Injection based attacks, covering SQL injection, NoSQL injection, operating system command injection, and server side template injection, are similarly within scope. Server side vulnerabilities such as server side request forgery, XML external entity attacks, insecure deserialization, and remote code execution round out a further category. Client side attacks, including stored, reflected, and DOM based cross site scripting, prototype pollution, and cross site request forgery, are addressed as well. Business logic flaws, a category that automated static analysis tools are notoriously poor at catching, including race conditions, payment manipulation, and workflow bypass issues, fall within scope specifically because Strix's agents actually exercise an application's real behavior rather than only inspecting its source code in isolation.
Authentication and session related issues, covering JSON Web Token attacks, session fixation, and credential stuffing vectors, are covered as well, alongside infrastructure and cloud focused concerns such as misconfigurations and exposed services, and API specific security issues including broken authentication, mass assignment vulnerabilities, and rate limiting bypass.
Multi Agent Orchestration in Practice
A defining architectural feature of Strix is what the project describes as a graph of agents, an advanced multi agent orchestration approach aimed at genuinely comprehensive, automated penetration testing rather than a single monolithic scanning process. Distributed pentesting assigns specialized agents to reconnaissance, exploitation, and post exploitation activity respectively, mirroring how a real, human staffed red team would typically divide labor across a serious engagement.
Scalable security testing allows parallel execution across multiple targets simultaneously, supporting fast, comprehensive coverage across a broader application portfolio rather than testing one target at a time in strict sequence. Dynamic coordination between agents allows discoveries made by one agent to be shared with others, chaining together individually modest findings into a more significant combined vulnerability, collaborating in a way that closely resembles how an actual human red team shares information and builds on each other's progress during a live engagement.
Reviewing Results Through the Local Web Viewer
Every scan writes its results directly to disk as it progresses, and a dedicated local viewer can bring those results up in an interactive dashboard with a single command:
strix viewstrix viewPassing a specific run name instead opens that particular run rather than defaulting to the most recent one:
strix view my-run-namestrix view my-run-nameRunning this command starts a lightweight local server bound specifically to the local loopback address on a randomly assigned port, then opens a private, token protected link directly in a browser. Nothing about this process leaves the local machine, since the dashboard reads a run's files directly off disk without requiring any cloud account or file upload, and the interface itself ships prebuilt alongside Strix, requiring no separate installation step or JavaScript build process.
The dashboard itself is organized around several distinct views. An overview section shows a run's overall status, its target, and a breakdown of findings by severity. A vulnerabilities section lists each validated finding individually, along with its severity rating, supporting details, and concrete reproduction steps. An agent graph section provides a live, visual map of the active multi agent team, showing exactly which agent is currently working on what part of the assessment. A steering section allows sending direct instructions to a live, still running scan straight from the browser, letting a human operator redirect the agents mid run if something specific needs closer attention. A history section allows browsing past runs performed on the same machine and jumping freely between them. And a reports section can generate a shareable report directly from a completed run, ready to be sent by email to an individual or a broader team.
Usage Patterns Worth Knowing
Beyond the most basic invocation already shown earlier, Strix supports a range of more specific usage patterns suited to different testing scenarios.
Scanning a codebase hosted directly on GitHub rather than checked out locally is handled the same way as a local path, simply substituting the repository URL:
strix --target https://github.com/org/repostrix --target https://github.com/org/repoA black box assessment against a deployed, live web application follows the same general pattern, pointing directly at a running application's URL:
strix --target https://your-app.comstrix --target https://your-app.comGrey box, authenticated testing can be requested directly through a natural language instruction passed alongside the target:
strix --target https://your-app.com --instruction "Perform authenticated testing using credentials: user:pass"strix --target https://your-app.com --instruction "Perform authenticated testing using credentials: user:pass"Multiple related targets, such as a project's source code repository alongside its actual deployed application, can be tested together within a single run by repeating the target flag:
strix -t https://github.com/org/app -t https://your-app.comstrix -t https://github.com/org/app -t https://your-app.comFor situations involving a larger number of targets, a plain text file listing one target per line, ignoring empty lines and lines beginning with a comment character, can be supplied directly instead:
strix --target-list ./targets.txtstrix --target-list ./targets.txtA white box, source aware scan against a local repository can be explicitly requested through a dedicated scan mode setting:
strix --target ./app-directory --scan-mode standardstrix --target ./app-directory --scan-mode standardFocused testing aimed at a specific category of concern, such as business logic and access control issues specifically, can be directed through the same instruction mechanism shown earlier:
strix --target api.your-app.com --instruction "Focus on business logic flaws and IDOR vulnerabilities"strix --target api.your-app.com --instruction "Focus on business logic flaws and IDOR vulnerabilities"For more detailed guidance, such as formal rules of engagement, scope boundaries, or explicit exclusions, an entire instruction file can be supplied instead of a single inline string:
strix --target api.your-app.com --instruction-file ./instruction.mdstrix --target api.your-app.com --instruction-file ./instruction.mdFor pull request focused workflows specifically, Strix supports scoping a scan down to only the differences introduced against a given base branch, running quickly and non interactively:
strix -n --target ./ --scan-mode quick --scope-mode diff --diff-base origin/mainstrix -n --target ./ --scan-mode quick --scope-mode diff --diff-base origin/mainRunning Strix Without an Interactive Interface
For server environments and automated jobs where an interactive terminal session is not appropriate, a headless mode runs Strix entirely programmatically through the non interactive flag:
strix -n --target https://your-app.comstrix -n --target https://your-app.comIn this mode, the command line interface prints vulnerability findings as they are discovered in real time, followed by a final report immediately before the process exits. Critically for automated pipelines, the process exits with a nonzero status code whenever vulnerabilities are actually found, which makes it straightforward to wire directly into existing automation that expects a standard success or failure exit code to decide whether a broader pipeline should continue or halt.
Integrating Strix Into a CI/CD Pipeline
Strix is explicitly designed to slot into an existing continuous integration pipeline, running an automated security check directly against every pull request. A representative GitHub Actions workflow illustrates the general shape of this integration:
name: strix-penetration-test
on:
pull_request:
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0
- name: Install Strix
run: curl -sSL https://strix.ai/install | bash
- name: Run Strix
env:
STRIX_LLM: ${{ secrets.STRIX_LLM }}
LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
run: strix -n -t ./ --scan-mode quickname: strix-penetration-test
on:
pull_request:
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0
- name: Install Strix
run: curl -sSL https://strix.ai/install | bash
- name: Run Strix
env:
STRIX_LLM: ${{ secrets.STRIX_LLM }}
LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
run: strix -n -t ./ --scan-mode quickWithin a pull request run specifically, Strix automatically scopes a quick review down to only the files actually changed in that pull request. If that scoping mechanism cannot resolve properly, checking out the repository with full commit history, using a fetch depth of zero as shown above, or explicitly passing a diff base argument, generally resolves the issue.
Configuring the Provider and Model
Beyond the two required environment variables shown during initial setup, several optional settings extend and refine how Strix operates:
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
export LLM_API_BASE="your-api-base-url"
export PERPLEXITY_API_KEY="your-api-key"
export STRIX_REASONING_EFFORT="high"export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
export LLM_API_BASE="your-api-base-url"
export PERPLEXITY_API_KEY="your-api-key"
export STRIX_REASONING_EFFORT="high"A custom API base URL supports pointing Strix at a locally hosted model, such as one served through Ollama or LM Studio, rather than a hosted commercial provider. A separate Perplexity API key enables additional search capability during an assessment. And a reasoning effort setting controls how much internal deliberation the underlying model applies to its decisions, defaulting to a high effort level for standard runs and automatically stepping down to a medium effort level specifically during quicker scans where speed matters more than maximum depth.
Once set, this configuration is saved automatically to a local file at ~/.strix/cli-config.json, meaning these values do not need to be re entered on every subsequent run.
Authenticating Through a ChatGPT Subscription
For anyone who would rather not manage a separately metered API key, Strix also supports authenticating directly against an existing ChatGPT Plus or Pro subscription instead:
strix auth login chatgpt
export STRIX_LLM="chatgpt/gpt-5.4"
strix --target ./app-directory
strix auth status
strix auth logoutstrix auth login chatgpt
export STRIX_LLM="chatgpt/gpt-5.4"
strix --target ./app-directory
strix auth status
strix auth logoutSigning in this way lets a scan run directly against the usage already included in a personal ChatGPT subscription rather than incurring separate, metered API charges, with straightforward commands available to check the currently active sign in or remove it entirely when no longer needed.
Among supported models, the project specifically recommends OpenAI's GPT-5.4, Anthropic's Claude Sonnet 4.6, and Google's Gemini 3 Pro Preview accessed through Vertex AI as particularly strong choices for genuinely capable results, while broader support extends further to additional providers including Amazon Bedrock, Azure, and various locally hosted model options documented separately.
Enterprise Grade Deployment
For organizations needing stronger administrative controls than the open source tool or the standard hosted platform provide on their own, an enterprise offering extends the same core Strix experience with single sign on support through SAML or OIDC, custom compliance ready reporting formats suited to frameworks such as SOC 2, ISO 27001, and PCI DSS, dedicated support backed by a formal service level agreement, custom deployment options including a private virtual private cloud or a fully self hosted arrangement, support for bringing an organization's own model access rather than relying on a centrally managed one, and tailored AI pentesting agents specifically optimized for a given organization's particular environment and technology stack.
Conclusion
Security testing has long been forced into an uncomfortable choice between speed and trustworthiness: fast, automated scanning tends to bury genuine risk under a pile of false positives, while manual penetration testing, though far more reliable, moves too slowly to keep pace with how quickly modern applications actually ship. Strix is built specifically to close that gap, deploying coordinated teams of autonomous AI agents that behave like real penetration testers, actively exploiting what they find and proving each vulnerability with a working proof of concept rather than a bare, unverified alert.
Combined with a genuinely comprehensive offensive security toolkit, broad coverage across the OWASP Top 10 and beyond, straightforward integration into existing CI/CD pipelines, and both a fully open source local tool and a fully managed hosted platform available depending on an organization's needs, Strix offers a genuinely credible path toward security testing that is both fast enough to run continuously and accurate enough to actually trust.
The repository is available at: https://github.com/usestrix/strix