The Problem

Traditional DAST and SAST tools produce high false-positive rates and require manual triage. Security teams spend days validating findings that turn out to be noise. Strix addresses this by using AI agents to not just find vulnerabilities but validate them through working proofs-of-concept, giving developers actionable results instead of a list of suspected issues.

What This Does

Strix is an autonomous AI penetration testing tool. It orchestrates multiple AI agents that act as pentesters—running reconnaissance, exploitation, and validation against your application. The system is built around a Python core (strix/core/) with a CLI (strix/interface/cli.py), a TUI (strix/interface/tui/app.py), and a web viewer (strix/interface/viewer/) built with React/TypeScript.

The tool integrates with multiple LLM providers (OpenAI, Anthropic, Google, etc.) and supports various scanning modes. It generates compliance-ready pentest reports and can auto-fix found vulnerabilities. The runtime uses Docker for sandboxing, and there's a CI/CD integration path via GitHub Actions.

How It Is Wired

Execution starts in strix/interface/main.py at the main function, which reaches 399 functions across the codebase. From there, control flows to the core runner (strix/core/runner.py), which orchestrates the agent coordination in strix/core/agents.py. The AgentCoordinator is called from 42 places, making it the central hub of the system.

The most critical module is strix/config/__init__.py with 29 modules depending on it—changing it creates a wide blast radius. The load_settings function in strix/config/loader.py is called from 44 places and is the most heavily used function in the codebase.

The system touches the outside world through: 115 functions doing file I/O, 27 making network calls, 12 performing cryptographic operations, and 9 running external commands. The shortest path from entry to external effect is main -> parse_arguments which reads a file, and action_request_quit -> action_custom_quit -> cleanup which makes a network call.

There's a circular dependency in strix/interface/viewer/server.py and strix/interface/viewer/__init__.py—two modules that mutually import each other.

How To Use It

git clone https://github.com/moses-y/strix
cd strix
# Install Python dependencies
pip install -e .
# Install frontend dependencies
cd strix/interface/viewer/frontend && npm install
# Run a scan (requires Docker and an LLM API key)
strix scan --target https://your-app.com

Configuration lives in strix/config/. You'll need an LLM API key from a supported provider and Docker running. The Makefile provides build targets, and containers/Dockerfile shows the container setup.

Real-World Use

A security team integrates Strix into their CI pipeline. Every pull request triggers a scan via GitHub Actions. The AI agents run against a staging environment, validate vulnerabilities with PoCs, and block the merge if critical issues are found—replacing a manual pentest that took weeks with an automated check that runs in hours.

Code Health & Issues

Static analysis found 91 issues (9 high, 82 medium) across 8 categories:

  • High - Hub module strix/config/__init__.py with 29 dependents; high blast radius on change
  • High - Deep nesting in strix/core/agents.py, strix/core/execution.py, strix/core/hooks.py (max depth 7)
  • High - Oversized files: strix/interface/utils.py at 1316 lines
  • High - Import cycle in strix/interface/viewer/server.py
  • High - 210 duplicated 6-line blocks across 43 files
  • Medium - 27 instances of broad exception handling in strix/report/state.py, strix/config/models.py
  • Medium - 3 files opened without context managers in strix/interface/viewer/server.py

SDLC observations: CI workflows exist but never invoke the test suite (48 test files, no test command). No Dependabot/Renovate configured. Docker base image uses mutable latest tag. No dependency vulnerability scanning in CI.

The Bottom Line

Strix is a serious, well-structured tool for AI-driven penetration testing with real PoC validation. The architecture is sound but has maintainability debt—oversized files, deep nesting, and duplicated logic will slow future changes. Teams wanting automated security testing with fewer false positives should evaluate it, but expect to invest in refactoring if you plan to extend the codebase.