# Technical Documentation: usestrix/strix > ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/usestrix/strix) ### Overview (`README.md`)

Strix Banner

# Strix ### The open-source AI pentesting tool. Autonomous AI hackers that find and fix your app’s vulnerabilities.
Docs Website [](https://discord.gg/strix-ai) Strix Cloud Try Strix Enterprise GitHub Stars License PyPI Version Join Discord Follow on X usestrix%2Fstrix | Trendshift usestrix/strix | Trendshift
> [!TIP] > **New!** Strix integrates seamlessly with GitHub Actions and CI/CD pipelines. Automatically scan for vulnerabilities on every pull request and block insecure code before it reaches production - [Get started with no setup required](https://app.strix.ai?utm_source=github&utm_medium=readme&utm_content=tip_ci). --- ## Strix Overview Strix are autonomous AI penetration testing agents that act just like real hackers - they run your code dynamically, find vulnerabilities, and validate them through actual proofs-of-concept. Built for developers and security teams who need fast, accurate security testing without the overhead of manual pentesting or the false positives of static analysis tools. **Key Capabilities:** - **Full pentesting toolkit** - reconnaissance, exploitation, and validation out of the box - **Multi-agent orchestration** - teams of AI pentesters that collaborate and scale - **Real exploit validation** - working PoCs, not false positives like legacy vulnerability scanners - **Developer‑first CLI** - actionable findings with remediation guidance - **Auto‑fix & reporting** - generate patches and compliance-ready pentest reports
Strix Demo
## Use Cases - **Application Security Testing** - Detect and validate critical vulnerabilities in your applications - **Rapid Penetration Testing** - Get penetration tests done in hours, not weeks, with compliance reports - **Bug Bounty Automation** - Automate bug bounty research and generate PoCs for faster reporting - **CI/CD Integration** - Run tests in CI/CD to block vulnerabilities before reaching production ## 🚀 Quick Start **Prerequisites:** - Docker (running) - An LLM API key from any [supported provider](https://docs.strix.ai/llm-providers/overview) (OpenAI, Anthropic, Google, etc.) ### Installation & First Scan ```bash # Install Strix curl -sSL https://strix.ai/install | bash # Configure your AI provider export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" # Run your first security assessment strix --target ./app-directory ``` > [!NOTE] > First run automatically pulls the sandbox Docker image. Results are saved to `strix_runs/` ### Updating ```bash # Self-update the standalone binary to the latest release strix --update # ...or re-run the installer curl -sSL https://strix.ai/install | bash ``` Installed with pipx, uv, or pip? `strix --update` prints the matching upgrade command instead (`pipx upgrade strix-agent`, `uv tool upgrade strix-agent`, `pip install --upgrade strix-agent`). Strix also shows a notice with the right command when a new version is available. --- ## Ways to Run Strix - **Open Source** - free, runs locally with Docker and your own LLM key. [Quick Start](https://docs.strix.ai/quickstart) - **Strix Cloud** - no setup, validated findings, one-click autofix, and PR reviews. [Run a pentest →](https://app.strix.ai?intent=pentest&utm_source=github&utm_medium=readme&utm_content=table_cloud) - **Enterprise** - SSO, compliance-ready reports, VPC or self-hosted deployment. [Try Strix Enterprise →](https://strix.ai/demo?utm_source=github&utm_medium=readme&utm_content=table_demo) --- ## ☁️ Strix Cloud Try the Strix full-stack penetration testing platform at **[app.strix.ai](https://app.strix.ai?utm_source=github&utm_medium=readme&utm_content=cloud_heading)** - sign up for free, connect your repos and domains, and launch a pentest in minutes. - **Validated findings with PoCs** - every vulnerability includes a working proof-of-concept exploit and reproduction steps - **One-click autofix** - AI-generated security patches as ready-to-merge pull requests - **Continuous pentesting** - always-on vulnerability scanning that keeps pace with your deployments - **DevSecOps integrations** - GitHub, GitLab, Bitbucket, Slack, Jira, Linear, and CI/CD pipelines - **Continuous learning** - AI that builds on past findings, adapts to your codebase, and reduces false positives over time [**Run a pentest →**](https://app.strix.ai?intent=pentest&utm_source=github&utm_medium=readme&utm_content=cloud_cta) ## 🏢 Enterprise Get the same Strix experience with enterprise-grade controls: SSO (SAML/OIDC), custom compliance-ready penetration testing reports (SOC 2, ISO 27001, PCI DSS), dedicated support and SLA, custom deployment options (VPC or self-hosted), BYOK model support, and tailored AI pentesting agents optimized for your environment. [**Try Strix Enterprise →**](https://strix.ai/demo?utm_source=github&utm_medium=readme&utm_content=enterprise_cta) --- ## 🤖 Use Strix from Your Coding Agent Strix is agent-ready. Give Claude Code, Cursor, Codex, or any [SKILL.md-compatible](https://agentskills.io) agent the ability to run pentests, fix findings, and set up CI scanning: ```bash npx skills add usestrix/strix ``` This installs nine skills for running pentests, fixing findings, and CI scanning, against code, web apps, APIs, and the OWASP Top 10. Agents can use the local CLI or the managed cloud with the same engine. See [`AGENTS.md`](AGENTS.md) for the quick reference, [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) for the CLI, and [docs.app.strix.ai](https://docs.app.strix.ai) for the API. --- ## ✨ Features ### Agentic Pentesting Tools Strix agents come equipped with a comprehensive offensive security toolkit - the same tools used by professional penetration testers and ethical hackers: - **HTTP Interception Proxy** - Full request/response manipulation and analysis with Caido - **Browser Exploitation** - Automated browser for testing XSS, CSRF, clickjacking, and auth bypass flows - **Shell & Command Execution** - Interactive terminal for exploit development and post-exploitation - **Custom Exploit Runtime** - Python sandbox for writing and validating proof-of-concept exploits - **Reconnaissance & OSINT** - Automated attack surface mapping, subdomain enumeration, and fingerprinting - **Static & Dynamic Code Analysis** - SAST + DAST capabilities for comprehensive application security testing - **Vulnerability Knowledge Base** - Structured findings with CVSS scoring and OWASP classification ### Comprehensive Vulnerability Scanner Strix identifies, validates, and exploits a wide range of security vulnerabilities across the OWASP Top 10 and beyond: - **Broken Access Control** - IDOR, privilege escalation, auth bypass - **Injection Attacks** - SQL injection, NoSQL injection, OS command injection, SSTI - **Server-Side Vulnerabilities** - SSRF, XXE, insecure deserialization, RCE - **Client-Side Attacks** - XSS (stored/reflected/DOM), prototype pollution, CSRF - **Business Logic Flaws** - Race conditions, payment manipulation, workflow bypass - **Authentication & Session** - JWT attacks, session fixation, credential stuffing vectors - **Infrastructure & Cloud** - Misconfigurations, exposed services, cloud security issues - **API Security** - Broken authentication, mass assignment, rate limiting bypass ### Graph of Agents (Multi-Agent Pentesting) Advanced multi-agent orchestration for comprehensive automated penetration testing: - **Distributed Pentesting** - Specialized AI agents for recon, exploitation, and post-exploitation - **Scalable Security Testing** - Parallel execution across multiple targets for fast, comprehensive coverage - **Dynamic Coordination** - Agents share discoveries, chain vulnerabilities, and collaborate like a red team --- ## 🖥️ Local Web Viewer Every scan writes its results to disk as it runs. Bring them up in a local dashboard with a single command: ```bash # Open the most recent run strix view # ...or open a specific run by name strix view my-run-name # Expose the viewer on all IPv4 interfaces at a fixed port strix view --host 0.0.0.0 --port 8080 --no-open ``` The dashboard shows the findings, a live map of the agent team, and past runs. Nothing leaves your machine, and the UI ships prebuilt. `strix view` binds to `127.0.0.1` and prints a tokened link that grants access to the run, so share it carefully. See the [viewer documentation](https://docs.strix.ai/usage/viewer) for the options and for reaching the viewer from another machine. --- ## Usage Examples ### Basic Usage ```bash # Scan a local codebase strix --target ./app-directory # Security review of a GitHub repository strix --target https://github.com/org/repo # Black-box web application assessment strix --target https://your-app.com ``` ### API Testing (OpenAPI / Swagger / Postman) Point Strix at an API contract and it tests every declared endpoint instead of having to discover them by crawling. Pair the spec with the live base URL so the agent knows where to send traffic: ```bash # OpenAPI / Swagger file, Postman export, or a live collection by id strix --target ./openapi.yaml --target https://api.your-app.com strix --target postman:// --target https://api.your-app.com ``` ### Advanced Testing Scenarios ```bash # Grey-box authenticated testing strix --target https://your-app.com --instruction "Perform authenticated testing using credentials: user:pass" # Multi-target testing (source code + deployed app) strix -t https://github.com/org/app -t https://your-app.com # Targets from a file, one target per non-empty, non-comment line strix --target-list ./targets.txt ``` See the [CLI reference](https://docs.strix.ai/usage/cli) for every option, including scan modes, diff scope, instruction files, and budgets. ### Headless Mode Run Strix programmatically without interactive UI using the `-n/--non-interactive` flag - perfect for servers and automated jobs. The CLI prints real-time vulnerability findings and the final report before exiting. Exits with non-zero code when vulnerabilities are found. ```bash strix -n --target https://your-app.com ``` ### CI/CD (GitHub Actions) Strix can be added to your pipeline to run a security test on pull requests with a lightweight GitHub Actions workflow: ```yaml 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 quick ``` > [!TIP] > In CI pull request runs, Strix automatically scopes quick reviews to changed files, which is why the > checkout above fetches full history. See the > [CI/CD documentation](https://docs.strix.ai/integrations/github-actions) for the details. ### Configuration ```bash export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" # Optional export LLM_API_BASE="your-api-base-url" # if using a local model, e.g. Ollama, LMStudio ``` > [!NOTE] > Strix automatically saves your configuration to `~/.strix/cli-config.json`, so you don't have to re-enter it on every run. > See the [configuration reference](https://docs.strix.ai/advanced/configuration) for every environment variable. #### Sign in with a ChatGPT subscription Instead of a metered API key, you can run Strix on your ChatGPT Plus/Pro subscription: ```bash strix auth login chatgpt # sign in with your ChatGPT account export STRIX_LLM="chatgpt/gpt-5.4" # chatgpt/ runs on the subscription strix auth status # show the active sign-in, or logout to forget it ``` #### Use the managed platform: `strix cloud` Run scans on [app.strix.ai](https://app.strix.ai) from the terminal, without Docker or an LLM key: ```bash strix cloud login # browser sign-in, one credential per install strix cloud scans start --source . --yes --wait # scan local code, approving the upload strix cloud scans start --engagement-type live_test --domain-ids --wait strix cloud vulns list --severity critical ``` Every [REST API](https://docs.app.strix.ai) operation has a matching `strix cloud ` command. Run `strix cloud` to list the resources, and add `help` to a resource to list its verbs. Output is JSON when stdout is not a terminal or when you pass `--json`. Binary downloads are the exception: redirect the raw bytes, or combine `--output FILE --json` for download metadata. See the [cloud CLI documentation](https://docs.strix.ai/cloud/cli) for scopes, workspaces, billing, and source-upload options. #### Connect your own MCP servers Strix can connect to Model Context Protocol (MCP) servers you list and expose their tools to the agent during a run. Create `~/.strix/mcp-servers.json` with a JSON list of local `stdio` servers or remote `http` servers: ```json [ { "name": "github", "transport": "http", "url": "https://api.githubcopilot.com/mcp/", "auth": { "kind": "bearer", "token": "your-token" }, "allowed_tools": ["list_issues"] } ] ``` Each server's tools are namespaced by `name`, for example `github_list_issues`. See the [MCP documentation](https://docs.strix.ai/integrations/mcp) for the full schema, tool filtering, and `stdio` servers. **Recommended models for best results:** - [Z.ai GLM-5.3 on OpenRouter](https://openrouter.ai/z-ai/glm-5.3) - `openrouter/z-ai/glm-5.3` (the default pick) - [OpenAI GPT-5.4](https://openai.com/api/) - `openai/gpt-5.4` - [Anthropic Claude Sonnet 4.6](https://claude.com/platform/api) - `anthropic/claude-sonnet-4-6` - [Google Gemini 3 Pro Preview](https://cloud.google.com/vertex-ai) - `vertex_ai/gemini-3-pro-preview` - [DeepSeek V4 Pro](https://platform.deepseek.com) - `deepseek/deepseek-v4-pro` - [Moonshot Kimi K3](https://platform.kimi.ai) - `moonshot/kimi-k3` See the [LLM Providers documentation](https://docs.strix.ai/llm-providers/overview) for all supported providers including Vertex AI, Bedrock, Azure, and local models. ## Documentation Full documentation is available at **[docs.strix.ai](https://docs.strix.ai)** - including detailed guides for usage, CI/CD integrations, skills, and advanced configuration. ## Contributing We welcome contributions of code, docs, and new skills - check out our [Contributing Guide](https://docs.strix.ai/contributing) to get started or open a [pull request](https://github.com/usestrix/strix/pulls)/[issue](https://github.com/usestrix/strix/issues). ## Join Our Community Have questions? Found a bug? Want to contribute? **[Join our Discord!](https://discord.gg/strix-ai)** ## Support the Project **Love Strix?** Give us a ⭐ on GitHub! ## Acknowledgements Strix builds on the incredible work of open-source projects like [LiteLLM](https://github.com/BerriAI/litellm), [Caido](https://github.com/caido/caido), [Nuclei](https://github.com/projectdiscovery/nuclei), [Playwright](https://github.com/microsoft/playwright), and [Bubble Tea](https://github.com/charmbracelet/bubbletea). Huge thanks to their maintainers! > [!WARNING] > **Authorized use only.** Strix actively tests the targets you point it at, so only run it against systems you own or have **explicit, written permission** to test, and stay within the agreed scope. Unauthorized testing is illegal in most jurisdictions. > You alone are responsible for obtaining authorization and complying with the law. Strix is provided "as is" with no warranty or liability for misuse. --- ### Overview (`benchmarks/README.md`) # Benchmarks We use security benchmarks to track Strix's capabilities and improvements over time. We plan to add more benchmarks, both existing ones and our own, to help the community evaluate and compare security agents. ## Full Details For the complete benchmark results, evaluation scripts, and run data, see the [usestrix/benchmarks](https://github.com/usestrix/benchmarks) repository. > [!NOTE] > We are actively adding more benchmarks to our evaluation suite. ## Results | Benchmark | Challenges | Success Rate | |-----------|------------|--------------| | [XBEN](https://github.com/usestrix/benchmarks/tree/main/XBEN) | 104 | **96%** | ### XBEN The [XBOW benchmark](https://github.com/usestrix/benchmarks/tree/main/XBEN) is a set of 104 web security challenges designed to evaluate autonomous penetration testing agents. Each challenge follows a CTF format where the agent must discover and exploit vulnerabilities to extract a hidden flag. Strix `v0.4.0` achieved a **96% success rate** (100/104 challenges) in black-box mode. ```mermaid %%{init: {'theme': 'base', 'themeVariables': { 'pie1': '#3b82f6', 'pie2': '#1e3a5f', 'pieTitleTextColor': '#ffffff', 'pieSectionTextColor': '#ffffff', 'pieLegendTextColor': '#ffffff'}}}%% pie title Challenge Outcomes (104 Total) "Solved" : 100 "Unsolved" : 4 ``` **Performance by Difficulty:** | Difficulty | Solved | Success Rate | |------------|--------|--------------| | Level 1 (Easy) | 45/45 | 100% | | Level 2 (Medium) | 49/51 | 96% | | Level 3 (Hard) | 6/8 | 75% | **Resource Usage:** - Average solve time: ~19 minutes - Total cost: ~$337 for 100 challenges --- ### Overview (`docs/README.md`) # Strix Documentation Documentation source files for Strix, powered by [Mintlify](https://mintlify.com). ## Local Preview ```bash npm i mintlify cd docs && mintlify dev ``` --- ### Overview (`strix/skills/README.md`) # 📚 Strix Skills ## 🎯 Overview Skills are specialized knowledge packages that enhance Strix agents with deep expertise in specific vulnerability types, technologies, and testing methodologies. Each skill provides advanced techniques, practical examples, and validation methods that go beyond baseline security knowledge. --- ## 🏗️ Architecture ### How Skills Work When an agent is created, it can load up to 5 specialized skills relevant to the specific subtask and context at hand: ```python # Agent creation with specialized skills create_agent( task="Test authentication mechanisms in API", name="Auth Specialist", skills="authentication_jwt,business_logic" ) ``` The skills are dynamically injected into the agent's system prompt, allowing it to operate with deep expertise tailored to the specific vulnerability types or technologies required for the task at hand. --- ## 📁 Skill Categories | Category | Purpose | |----------|---------| | **`/vulnerabilities`** | Advanced testing techniques for core vulnerability classes like authentication bypasses, business logic flaws, and race conditions | | **`/frameworks`** | Specific testing methods for popular frameworks e.g. Django, Express, FastAPI, and Next.js | | **`/technologies`** | Specialized techniques for third-party services such as Supabase, Firebase, Auth0, and payment gateways | | **`/protocols`** | Protocol-specific testing patterns for GraphQL, WebSocket, OAuth, and other communication standards | | **`/tooling`** | Command-line playbooks for core sandbox tools (nmap, nuclei, httpx, ffuf, subfinder, naabu, katana, sqlmap) | | **`/cloud`** | Cloud provider security testing for AWS, Azure, GCP, and Kubernetes environments | | **`/reconnaissance`** | Advanced information gathering and enumeration techniques for comprehensive attack surface mapping | | **`/custom`** | Community-contributed skills for specialized or industry-specific testing scenarios | Notable source-aware skills: - `source_aware_whitebox` (coordination): white-box orchestration playbook - `source_aware_sast` (custom): semgrep/AST/secrets/supply-chain static triage workflow - `dependency_cve_scanning` (custom): trivy-based SCA workflow for reporting known dependency CVEs via `create_dependency_report` - `npx_confusion` (custom): npx/npm exec/bunx fallback and adjacent package-runner identity confusion, with runner-specific registry and reporting gates - `semantic_confusion` (vulnerabilities): cross-boundary parser, normalization, and representation mismatch analysis - `agentic_system_security` (vulnerabilities): effective-authority and MCP/tool ecosystem security testing - `browser_security` (vulnerabilities): browsing-context, postMessage, XS-Leaks, service-worker, and cross-origin state-machine testing - `azure` (cloud): Azure and Microsoft Entra privilege, PIM, workload identity, and cross-plane escalation analysis - `infrastructure_lifecycle` (reconnaissance): abandoned or mutable external dependencies such as update endpoints, MX, storage, and control domains - `argument_injection` (vulnerabilities): shell-free CLI option smuggling, secondary argument-file parsing, and platform-specific argv transformation boundaries - `electron_desktop_apps` (technologies): Electron renderer-to-native trust boundaries, preload/IPC exposure, and navigation analysis Notable LLM security skills: - `llm_applications` (technologies): end-to-end OWASP 2026 LLM01-LLM10 coverage across models, RAG, vectors, agents, tools, outputs, supply chain, and resource controls - `llm_prompt_injection` (vulnerabilities): deep direct, indirect, multimodal, memory, and tool-result prompt-injection testing --- ## 🎨 Creating New Skills ### What Should a Skill Contain? A good skill is a structured knowledge package that typically includes: - **Advanced techniques** - Non-obvious methods specific to the task and domain - **Practical examples** - Working payloads, commands, or test cases with variations - **Validation methods** - How to confirm findings and avoid false positives - **Context-specific insights** - Environment and version nuances, configuration-dependent behavior, and edge cases - **YAML frontmatter** - `name` and `description` fields for skill metadata Skills focus on deep, specialized knowledge to significantly enhance agent capabilities. They are dynamically injected into agent context when needed. --- ## 🤝 Contributing Community contributions are more than welcome — contribute new skills via [pull requests](https://github.com/usestrix/strix/pulls) or [GitHub issues](https://github.com/usestrix/strix/issues) to help expand the collection and improve extensibility for Strix agents. --- > [!NOTE] > **Work in Progress** - We're actively expanding the skills collection with specialized techniques and new categories. --- ### Overview (`strix/telemetry/README.md`) ### Overview To help make Strix better for everyone, we collect anonymized data that helps us understand how to better improve our AI security agent for our users, guide the addition of new features, and fix common errors and bugs. This feedback loop is crucial for improving Strix's capabilities and user experience. We use [PostHog](https://posthog.com), an open-source analytics platform, for data collection and analysis, along with [Scarf](https://scarf.sh). Our telemetry implementation is fully transparent - you can review the source code ([posthog.py](https://github.com/usestrix/strix/blob/main/strix/telemetry/posthog.py), [scarf.py](https://github.com/usestrix/strix/blob/main/strix/telemetry/scarf.py)) to see exactly what we track. ### Telemetry Policy Privacy is our priority. All collected data is anonymized by default. Each session gets a random UUID that is not persisted or tied to you. Your code, scan targets, vulnerability details, and findings always remain private and are never collected. ### What We Track We collect only very **basic** usage data including: **Session Errors:** Duration, the failure category, the scan phase, and the exception class name (not messages or stack traces)\ **System Context:** OS type, architecture, Strix version\ **Scan Context:** Scan mode (quick/standard/deep), scan type (whitebox/blackbox)\ **Model Usage:** Which LLM model is being used and whether it runs via an API key or a model subscription (not prompts or responses)\ **Feature Usage:** Which built-in skills were used during a scan (reported once, at scan end)\ **Aggregate Metrics:** Vulnerability counts by severity and weakness category (CWE) ### What We **Never** Collect - Usernames, or any identifying information - Scan targets, file paths, target URLs, or domains - Vulnerability details, descriptions, or code - LLM requests and responses ### How to Opt Out Telemetry in Strix is entirely **optional**: ```bash export STRIX_TELEMETRY=0 ``` You can set this environment variable before running Strix to disable **all** telemetry. --- ### Overview (`strix/tools/agent_browser/README.md`) # agent-browser Browser automation CLI installed in the sandbox image. Driven by the agent through `exec_command` (not a function tool). - **Implementation:** sandbox CLI at `/home/pentester/.npm-global/bin/agent-browser` — npm package `agent-browser@0.26.0` (Vercel), driving Chromium directly. - **Strix config:** `containers/Dockerfile` sets `AGENT_BROWSER_*` env (executable path, UA, launch args, screenshot dir). - **Skill:** `strix/skills/tooling/agent_browser.md` — **always-loaded** into every agent prompt by `strix/agents/prompt.py:_resolve_skills`. --- ### Overview (`strix/tools/apply_patch/README.md`) # apply_patch SDK-provided file patching tool — the agent's only first-class way to edit files in the sandbox. Surfaced to the model as `patch` (renamed via `_TOOL_NAME_OVERRIDES` in `strix/agents/factory.py`). - **Implementation:** `agents.sandbox.capabilities.tools.apply_patch_tool.ApplyPatchTool` (upstream `agents` SDK) - **Wired in:** `strix/agents/factory.py` — added per-run via the SDK `Filesystem` capability. --- ### Overview (`strix/tools/shell/README.md`) # shell — `exec_command` + `write_stdin` SDK-provided shell tools wired per-run from the sandbox session. Every CLI invocation the agent makes (nmap, ffuf, agent-browser, python3, …) goes through `exec_command`. `write_stdin` streams input to a still-running process started by an earlier `exec_command` (for interactive prompts). ## `write_stdin` requires a TTY-backed process `exec_command` runs each command in a fresh **non-interactive** shell (plain pipes, no TTY) by default. `write_stdin` only works against a process that is still running **and** was started with a PTY. The canonical sequence is: ```text exec_command(cmd="python3", tty=true) # start a PTY-backed process write_stdin(session_id=, chars="print(1)\n") ``` Calling `write_stdin` on a command started with the default `tty=false`, or on a process that has already exited, fails with `stdin is not available for this process. Start the command with 'tty=true' in 'exec_command' before using 'write_stdin'.` Use `tty=true` for REPLs, `ssh`/`nc`/`ftp`, `msfconsole`, or to deliver a Ctrl-C to a long-running job. - **Implementation:** `agents.sandbox.capabilities.tools.shell_tool.ShellTool` (in the upstream `agents` SDK) - **Wired in:** `strix/agents/factory.py` — added per-run via the SDK `Shell` capability; `write_stdin` is wrapped to drop the SDK's `pid` arg from the function schema. - **Sandbox env:** `http_proxy` / `https_proxy` route every shell child through Caido; `AGENT_BROWSER_*`, `REQUESTS_CA_BUNDLE` etc. come from `containers/Dockerfile`. --- ### Overview (`strix/tools/view_image/README.md`) # view_image SDK-provided tool that loads an image from the sandbox workspace and returns it as an image content block for vision-capable models. - **Implementation:** `agents.sandbox.capabilities.tools.view_image.ViewImageTool` (upstream `agents` SDK) - **Wired in:** `strix/agents/factory.py` — added per-run via the SDK `Filesystem` capability. - **Strix defaults:** screenshots default to `/workspace/.agent-browser-screenshots/` via `AGENT_BROWSER_SCREENSHOT_DIR` (set in `containers/Dockerfile`; dir is created at container start in `containers/docker-entrypoint.sh`). - **Skill:** screenshot workflow lives in `strix/skills/tooling/agent_browser.md`. - **Recovery:** vision-not-supported model rejections are auto-recovered via `strix.core.sessions.strip_all_images_from_session`, invoked from `strix/core/execution.py`. --- ### Index (`docs/index.mdx`) --- title: "Introduction" description: "Open-source AI hackers to secure your apps" --- Strix are autonomous AI agents that act like real hackers—they run your code dynamically, find vulnerabilities, and validate them with proof-of-concepts. Built for developers and security teams who need fast, accurate security testing without the overhead of manual pentesting or the false positives of static analysis tools. Strix Demo Install and run your first scan in minutes. Learn all command-line options. Explore the security testing toolkit. Integrate into your CI/CD pipeline. ## Use Cases - **Application Security Testing** — Detect and validate critical vulnerabilities in your applications - **Rapid Penetration Testing** — Get penetration tests done in hours, not weeks - **Bug Bounty Automation** — Automate research and generate PoCs for faster reporting - **CI/CD Integration** — Block vulnerabilities before they reach production ## Key Capabilities - **Full hacker toolkit** — Browser automation, HTTP proxy, terminal, Python runtime - **Real validation** — PoCs, not false positives - **Multi-agent orchestration** — Specialized agents collaborate on complex targets - **Developer-first CLI** — Interactive TUI or headless mode for automation ## Security Tools Strix agents come equipped with a comprehensive toolkit: | Tool | Purpose | |------|---------| | HTTP Proxy | Full request/response manipulation and analysis | | Browser Automation | Multi-tab browser for XSS, CSRF, auth flow testing | | Terminal | Interactive shells for command execution | | Python Runtime | Custom exploit development and validation | | Reconnaissance | Automated OSINT and attack surface mapping | | Code Analysis | Static and dynamic analysis capabilities | ## Vulnerability Coverage | Category | Examples | |----------|----------| | Access Control | IDOR, privilege escalation, auth bypass | | Injection | SQL, NoSQL, command injection | | Server-Side | SSRF, XXE, deserialization | | Client-Side | XSS, prototype pollution, DOM vulnerabilities | | Business Logic | Race conditions, workflow manipulation | | Authentication | JWT vulnerabilities, session management | | Infrastructure | Misconfigurations, exposed services | ## Multi-Agent Architecture Strix uses a graph of specialized agents for comprehensive security testing: - **Distributed Workflows** — Specialized agents for different attacks and assets - **Scalable Testing** — Parallel execution for fast comprehensive coverage - **Dynamic Coordination** — Agents collaborate and share discoveries ## Quick Example ```bash # Install curl -sSL https://strix.ai/install | bash # Configure export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" # Scan strix --target ./your-app ``` ## Community Join the community for help and discussion. Star the repo and contribute. Only test applications you own or have explicit permission to test. --- ### Quickstart (`docs/quickstart.mdx`) --- title: "Quick Start" description: "Install Strix and run your first security scan" --- ## Prerequisites - Docker (running) - An LLM API key from any [supported provider](/llm-providers/overview) (OpenAI, Anthropic, Google, etc.) ## Installation ```bash curl -sSL https://strix.ai/install | bash ``` ```bash pipx install strix-agent ``` ## Configuration Set your LLM provider: ```bash export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" ``` For best results, use `openrouter/z-ai/glm-5.3` (the default pick), `openai/gpt-5.4`, `anthropic/claude-opus-4-6`, or `openai/gpt-5.2`. ## Run Your First Scan ```bash strix --target ./your-app ``` First run pulls the Docker sandbox image automatically. Results are saved to `strix_runs/`. ## Target Types Strix accepts multiple target types: ```bash # Local codebase strix --target ./app-directory # GitHub repository strix --target https://github.com/org/repo # Live web application strix --target https://your-app.com # Multiple targets (white-box testing) strix -t https://github.com/org/repo -t https://your-app.com # Targets from a file, one target per non-empty, non-comment line strix --target-list ./targets.txt ``` ## Next Steps Explore all command-line options. Choose the right scan depth. --- ### Cloud Overview (`docs/cloud/overview.mdx`) --- title: "Introduction" description: "Managed security testing without local setup" --- Skip the setup. Run Strix in the cloud at [app.strix.ai](https://app.strix.ai). ## Features No Docker, API keys, or local installation needed. Detailed findings with remediation guidance. Track vulnerabilities and fixes over time. Automatic scans on pull requests. ## What You Get - **Penetration test reports** — Validated findings with PoCs - **Shareable dashboards** — Collaborate with your team - **CI/CD integration** — Block risky changes automatically - **Continuous monitoring** — Catch new vulnerabilities quickly ## Getting Started 1. Sign up at [app.strix.ai](https://app.strix.ai) 2. Connect your repository or enter a target URL 3. Launch your first scan ## Scan Local Source Send a local working tree to the managed white-box scanner without connecting a source-control provider: ```bash # Review the exact file manifest and capture source.archive_sha256. Nothing is uploaded. strix cloud scans start --source . --dry-run --show-files --json SOURCE_SHA256="" # Repeat the same source-selection flags and approve that exact snapshot. strix cloud scans start --source . --approve-sha256 "$SOURCE_SHA256" --wait ``` In a Git repository, Strix includes tracked files and untracked files that are not ignored. Hidden files, `.git`, symlinks, dependencies and build output, secret-like filenames, and nested archives are excluded by default. Use `.strixignore` or repeat `--exclude GLOB` for project-specific exclusions. `--include-hidden`, `--include-sensitive`, and `--include-archives` are explicit opt-ins. The CLI limits individual files, total expanded bytes, archive bytes, and file count. For an agent or CI handoff, repeat the same `--source`, `--exclude`, and `--include-*` flags with `--approve-sha256`; Strix refuses the upload if the rebuilt archive differs from the reviewed digest. `--yes` is a one-invocation approval for the snapshot built at that moment, not a digest-bound two-step approval. The temporary local archive is always removed. After a definitive launch rejection, Strix also deletes the staged remote upload. If a network error, server error, or interruption makes the launch outcome ambiguous, it retains the upload and reports its ID; check `strix cloud scans list` before retrying, then delete an unlinked upload with `strix cloud uploads delete UPLOAD_ID`. Run your first pentest in minutes. --- ### Llm Providers Overview (`docs/llm-providers/overview.mdx`) --- title: "Overview" description: "Configure your AI model for Strix" --- Strix uses [LiteLLM](https://docs.litellm.ai/docs/providers) for model compatibility, supporting 100+ LLM providers. ## Configuration Set your model and API key: | Model | Provider | Configuration | | -------------------- | ----------------- | -------------------------------- | | GLM-5.3 (default) | Z.ai (OpenRouter) | `openrouter/z-ai/glm-5.3` | | GPT-5.4 | OpenAI | `openai/gpt-5.4` | | Claude Sonnet 4.6 | Anthropic | `anthropic/claude-sonnet-4-6` | | Gemini 3 Pro | Google Vertex | `vertex_ai/gemini-3-pro-preview` | | DeepSeek V4 Pro | DeepSeek | `deepseek/deepseek-v4-pro` | | Kimi K3 | Moonshot | `moonshot/kimi-k3` | ```bash export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" ``` ## Local Models Run models locally with [Ollama](https://ollama.com), [LM Studio](https://lmstudio.ai), or any OpenAI-compatible server: ```bash export STRIX_LLM="ollama/llama4" export LLM_API_BASE="http://localhost:11434" ``` See the [Local Models guide](/llm-providers/local) for setup instructions and recommended models. ## Provider Guides GPT-5.4 models. Claude Opus, Sonnet, and Haiku. Access 100+ models through a single API. Access models from multiple providers through one endpoint. Gemini 3 models via Google Cloud. Claude and Titan models via AWS. GPT-5.4 via Azure. Llama 4, Mistral, and self-hosted models. ## Model Format Use LiteLLM's `provider/model-name` format: ``` openrouter/z-ai/glm-5.3 openai/gpt-5.4 anthropic/claude-sonnet-4-6 vertex_ai/gemini-3-pro-preview bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0 ollama/llama4 ``` --- ### Tools Overview (`docs/tools/overview.mdx`) --- title: "Agent Tools" description: "How Strix agents interact with targets" --- Strix agents use specialized tools to test your applications like a real penetration tester would. ## Core Tools Playwright-powered Chrome for interacting with web UIs. Caido-powered proxy for intercepting and replaying requests. Bash shell for running commands and security tools. Pre-installed security tools: Nuclei, ffuf, and more. ## Additional Tools | Tool | Purpose | | -------------- | ---------------------------------------- | | Python Runtime | Write and execute custom exploit scripts | | File Editor | Read and modify source code | | Web Search | Real-time OSINT with Exa or Perplexity | | Notes | Document findings during the scan | | Reporting | Generate vulnerability reports with PoCs | --- ### Contributing (`docs/contributing.mdx`) --- title: "Contributing" description: "Contribute to Strix development" --- ## Development Setup ### Prerequisites - Python 3.12+ - Latest Go 1.24.x patch (only for Bubble Tea TUI development and release artifacts) - Docker (running) - [uv](https://docs.astral.sh/uv/) - Git ### Local Development ```bash git clone https://github.com/usestrix/strix.git cd strix ``` ```bash make setup-dev # or manually: uv sync uv run pre-commit install ``` ```bash export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" ``` ```bash uv run strix --target https://example.com ``` ## Contributing Skills Skills are specialized knowledge packages that enhance agent capabilities. They live in `strix/skills/` ### Creating a Skill 1. Choose the right category 2. Create a `.md` file with YAML frontmatter (`name` and `description` fields) 3. Include practical examples—working payloads, commands, test cases 4. Provide validation methods to confirm findings 5. Submit via PR ## Contributing Code ### Pull Request Process 1. **Create an issue first** — Describe the problem or feature 2. **Fork and branch** — Work from `main` 3. **Make changes** — Follow existing code style 4. **Write tests** — Ensure coverage for new features 5. **Run checks** — `make check-all` should pass 6. **Submit PR** — Link to issue and provide context ### Code Style - PEP 8 with 100-character line limit - Type hints for all functions - Docstrings for public methods - Small, focused functions - Meaningful variable names ## Package Builds Editable installs do not require Go; they run the TUI from source (`go run`). Wheels are intentionally strict: they always bundle the matching Go sidecar and are platform-specific. ```bash make wheel ``` The build hook (`scripts/tui_sidecar_hook.py`) requires Go 1.24.x or newer, embeds the sidecar as `strix/bin/strix-tui`, and assigns the current platform tag. Frozen releases built by `scripts/build.sh` and `strix.spec` also require the sidecar. ## Reporting Issues Include: - Python version and OS - Strix version (`strix --version`) - LLM being used - Full error traceback - Steps to reproduce ## Community Join the community for help and discussion. Report bugs and request features. --- ### Docs.Json (`docs/docs.json`) { "$schema": "https://mintlify.com/docs.json", "theme": "maple", "name": "Strix", "colors": { "primary": "#000000", "light": "#ffffff", "dark": "#000000" }, "favicon": "/images/favicon-48.ico", "navigation": { "tabs": [ { "tab": "Documentation", "groups": [ { "group": "Getting Started", "pages": [ "index", "quickstart" ] }, { "group": "Usage", "pages": [ "usage/cli", "usage/scan-modes", "usage/instructions", "usage/viewer" ] }, { "group": "LLM Providers", "pages": [ "llm-providers/overview", "llm-providers/openai", "llm-providers/anthropic", "llm-providers/openrouter", "llm-providers/vercel-ai-gateway", "llm-providers/vertex", "llm-providers/bedrock", "llm-providers/azure", "llm-providers/novita", "llm-providers/local" ] }, { "group": "Integrations", "pages": [ "integrations/github-actions", "integrations/ci-cd", "integrations/coding-agents", "integrations/mcp" ] }, { "group": "Tools", "pages": [ "tools/overview", "tools/browser", "tools/proxy", "tools/terminal", "tools/sandbox" ] }, { "group": "Advanced", "pages": [ "advanced/configuration", "advanced/skills", "contributing" ] } ] }, { "tab": "Cloud", "groups": [ { "group": "Strix Cloud", "pages": [ "cloud/overview", "cloud/cli" ] } ] } ], "global": { "anchors": [ { "anchor": "GitHub", "href": "https://github.com/usestrix/strix", "icon": "github" }, { "anchor": "Discord", "href": "https://discord.gg/strix-ai", "icon": "discord" } ] } }, "navbar": { "links": [], "primary": { "type": "button", "label": "Try Strix Cloud", "href": "https://app.strix.ai" } }, "footer": { "socials": { "x": "https://x.com/strix_ai", "github": "https://github.com/usestrix", "discord": "https://discord.gg/strix-ai" } }, "fonts": { "family": "Geist", "heading": { "family": "Geist" }, "body": { "family": "Geist" } }, "appearance": { "default": "dark" }, "description": "Open-source AI Hackers to secure your Apps", "background": { "decoration": "grid" } } --- ### Advanced Configuration (`docs/advanced/configuration.mdx`) --- title: "Configuration" description: "Environment variables for Strix" --- Configure Strix using environment variables or a config file. ## LLM Configuration Model name in LiteLLM format (e.g., `openrouter/z-ai/glm-5.3`, `openai/gpt-5.4`). API key for your LLM provider. Not required for local models or cloud provider auth (Vertex AI, AWS Bedrock). Custom API base URL. Also accepts `OPENAI_API_BASE`, `LITELLM_BASE_URL`, or `OLLAMA_API_BASE`. Select the OpenAI API path for the model: `responses` or `chat_completions`. By default, a custom `LLM_API_BASE` uses chat completions. Set this variable when your gateway requires the other API. Also accepts `STRIX_FORCE_API`. Extra HTTP headers sent on every LLM request, as a JSON object (e.g. `{"X-Feature-Key":"value","X-Tenant":"acme"}`). Useful for OpenAI-compatible gateways that require attribution or routing headers in addition to the bearer token. The bearer token itself still comes from `LLM_API_KEY`. Applies to both the LiteLLM and native OpenAI routing paths. Extra fields merged into the JSON body of every request to the main model, as a JSON object (e.g. `{"service_tier":"flex","safety_identifier":"9f86d081..."}`). Use it for provider parameters Strix doesn't expose, such as OpenAI's `service_tier` or `safety_identifier`. Applies to both the LiteLLM and native OpenAI routing paths. Fields are not validated, so the provider or gateway must accept them; unknown fields are usually rejected. Extra fields can override fields Strix sends and break requests, so don't set request-shaping fields such as `model`, `messages`, `input`, `tools` or `stream`, and use `STRIX_REASONING_EFFORT` rather than `reasoning_effort`. Request timeout in seconds for LLM calls. Seconds the startup connection check waits for the model to answer before failing with `LLM CONNECTION FAILED`. Scan requests use `LLM_TIMEOUT`. Maximum number of retries for LLM API calls on transient failures. Control thinking effort for reasoning models. Valid values: `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`. Defaults to `medium` for quick scan mode. Timeout in seconds for memory compression operations (context summarization). Send a per-agent `session_id` on OpenRouter requests, so each agent's calls stay on one upstream provider and its prompt cache carries over between turns. When unset, OpenRouter routes every request freely. Token block size that providers cache prompts in. A turn counts as a cache miss in the run report only when the cached tokens fall at least this many tokens short of the previous prompt and the prompt did not shrink. Lower it for providers with smaller blocks (DeepSeek and GLM use 64; vLLM defaults to 16). ### Dedicated deduplication model Finding deduplication is a cheap, structured classification task. By default it runs on the main model, but you can route it to a smaller/cheaper model without affecting the agents that do the actual testing. Model used to judge whether a candidate finding duplicates an existing report. Falls back to `STRIX_LLM` when unset. Optional provider key for the deduplication model. Optional custom API base URL for the deduplication model. Use when the dedupe model runs on a different endpoint than the main model. Optional JSON object of extra HTTP headers sent on every deduplication-model request, e.g. `{"X-Feature-Key":"value"}`. A dedicated dedupe model never inherits `LLM_EXTRA_HEADERS`; set this when its endpoint needs custom headers. Optional JSON object of extra request-body fields sent on every deduplication-model request. A dedicated dedupe model never inherits `LLM_EXTRA_BODY`; set this when its endpoint needs them too. Reasoning effort for the deduplication model. Defaults to the model's own baseline when unset. ## Optional Features API key for Perplexity AI. Enables real-time web search during scans for OSINT and vulnerability research. API key for Exa. Enables real-time web search through the Exa `/search` endpoint. Exa also powers the `web_get_contents` tool, which fetches the full text of a page through the Exa `/contents` endpoint. This is the preferred web search provider. Web search provider: `auto`, `perplexity`, or `exa`. With `auto`, Strix uses Exa when `EXA_API_KEY` is set, and Perplexity otherwise. Set an explicit provider to pin one when you configure both keys. Exa search mode: `auto`, `fast`, `instant`, `deep-lite`, `deep`, or `deep-reasoning`. Lower modes return results faster. Higher modes plan across more steps and take more time. This setting applies only to the Exa provider. Number of Exa results to return, from `1` to `100`. Each result includes a title, a URL, and a short security-focused summary. To read a full page, the agent calls `web_get_contents` with the result URL. This setting applies only to the Exa provider. Postman API key (`PMAK-…`). Enables fetching Postman collections by id as a target (`postman://`), and Postman environments (`postman://?env=`) to resolve collection variables. Not needed when passing a local collection export file. Telemetry toggle. Set to `0`, `false`, `no`, or `off` to disable telemetry (PostHog, Scarf, OTEL). Record every LLM request's and tool call's timing in `run.json`, under `llm_requests` and `tool_calls`. Adds about 0.5 MB to a typical scan's `run.json`. OTLP/Traceloop base URL for remote OpenTelemetry export. If unset, Strix keeps traces local only. API key used for remote trace export. Remote export is enabled only when both `TRACELOOP_BASE_URL` and `TRACELOOP_API_KEY` are set. Optional custom OTEL headers (JSON object or `key=value,key2=value2`). Useful for Langfuse or custom/self-hosted OTLP gateways. When remote OTEL vars are not set, Strix still writes complete run telemetry locally to: ```bash strix_runs//events.jsonl ``` When remote vars are set, Strix dual-writes telemetry to both local JSONL and the remote OTEL endpoint. ## Docker Configuration Docker image to use for the sandbox container. Docker daemon address, for example `unix:///var/run/docker.sock` or `tcp://10.0.0.5:2375`. When not set, Strix connects to the same daemon as the `docker` CLI: the current docker context (`docker context use`), then the default socket. Docker Desktop, OrbStack and Colima register their sockets as contexts, so no extra configuration is needed for them. Runtime backend for the sandbox environment. ## Sandbox Configuration Maximum execution time in seconds for sandbox operations. Timeout in seconds for connecting to the sandbox container. ## Config File Strix stores configuration in `~/.strix/cli-config.json`. You can also specify a custom config file: ```bash strix --target ./app --config /path/to/config.json ``` **Config file format:** ```json { "env": { "STRIX_LLM": "openrouter/z-ai/glm-5.3", "LLM_API_KEY": "sk-...", "STRIX_REASONING_EFFORT": "high" } } ``` ## Example Setup ```bash # Required export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="sk-..." # Optional: Enable web search (Exa preferred, Perplexity supported) export EXA_API_KEY="..." export PERPLEXITY_API_KEY="pplx-..." # Optional: Custom timeouts export LLM_TIMEOUT="600" export STRIX_SANDBOX_EXECUTION_TIMEOUT="300" ``` --- ### Advanced Skills (`docs/advanced/skills.mdx`) --- title: "Skills" description: "Specialized knowledge packages that enhance agent capabilities" --- Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methodologies. ## The Idea LLMs have broad but shallow security knowledge. They know _about_ SQL injection, but lack the nuanced techniques that experienced pentesters use—parser quirks, bypass methods, validation tricks, and chain attacks. Skills inject this deep, specialized knowledge directly into the agent's context, transforming it from a generalist into a specialist for the task at hand. ## How They Work When Strix spawns an agent for a specific task, it selects up to 5 relevant skills based on the context: ```python # Agent created for JWT testing automatically loads relevant skills create_agent( task="Test authentication mechanisms", skills=["authentication_jwt", "business_logic"] ) ``` The skills are injected into the agent's system prompt, giving it access to: - **Advanced techniques** — Non-obvious methods beyond standard testing - **Working payloads** — Practical examples with variations - **Validation methods** — How to confirm findings and avoid false positives ## Skill Categories ### Vulnerabilities Core vulnerability classes with deep exploitation techniques. | Skill | Coverage | | ------------------------------------- | ------------------------------------------------------ | | `authentication_jwt` | JWT attacks, algorithm confusion, claim tampering | | `idor` | Object reference attacks, horizontal/vertical access | | `sql_injection` | SQL injection variants, WAF bypasses, blind techniques | | `xss` | XSS types, filter bypasses, DOM exploitation | | `ssrf` | Server-side request forgery, protocol handlers | | `csrf` | Cross-site request forgery, token bypasses | | `xxe` | XML external entities, OOB exfiltration | | `rce` | Remote code execution vectors | | `business_logic` | Logic flaws, state manipulation, race conditions | | `race_conditions` | TOCTOU, parallel request attacks | | `path_traversal_lfi_rfi` | File inclusion, path traversal | | `open_redirect` | Redirect bypasses, URL parsing tricks | | `mass_assignment` | Attribute injection, hidden parameter pollution | | `insecure_file_uploads` | Upload bypasses, extension tricks | | `information_disclosure` | Data leakage, error-based enumeration | | `subdomain_takeover` | Dangling DNS, cloud resource claims | | `broken_function_level_authorization` | Privilege escalation, role bypasses | ### Frameworks Framework-specific testing patterns. | Skill | Coverage | | --------- | -------------------------------------------- | | `fastapi` | FastAPI security patterns, Pydantic bypasses | | `nextjs` | Next.js SSR/SSG issues, API route security | ### Technologies Third-party service and platform security. | Skill | Coverage | | ---------- | ------------------------------------------------------ | | `supabase` | Supabase RLS bypasses, auth issues | | `firebase` | Firebase Firestore, Storage rules, Auth, and Functions | ### Protocols Protocol-specific testing techniques. | Skill | Coverage | | --------- | ------------------------------------------------ | | `graphql` | GraphQL introspection, batching, resolver issues | ### Reconnaissance Passive discovery and attack-surface mapping techniques. | Skill | Coverage | | ----------------- | --------------------------------------------------------------- | | `asset_discovery` | CT, TLS SAN pivoting, passive DNS, and ASN/IP asset enumeration | ### Tooling Sandbox CLI playbooks for core recon and scanning tools. | Skill | Coverage | | ----------- | ------------------------------------------------------- | | `nmap` | Port/service scan syntax and high-signal scan patterns | | `nuclei` | Template selection, severity filtering, and rate tuning | | `httpx` | HTTP probing and fingerprint output patterns | | `ffuf` | Wordlist fuzzing, matcher/filter strategy, recursion | | `subfinder` | Passive subdomain enumeration and source control | | `naabu` | Fast port scanning with explicit rate/verify controls | | `katana` | Crawl depth/JS/known-files behavior and pitfalls | | `sqlmap` | SQLi workflow for enumeration and controlled extraction | ## Skill Structure Each skill is a Markdown file with YAML frontmatter for metadata: ```markdown --- name: skill_name description: Brief description of the skill's coverage --- # Skill Title Key insight about this vulnerability or technique. ## Attack Surface What this skill covers and where to look. ## Methodology Step-by-step testing approach. ## Techniques How to discover and exploit the vulnerability. ## Bypass Methods How to bypass common protections. ## Validation How to confirm findings and avoid false positives. ``` ## Contributing Skills Community contributions are welcome. Create a `.md` file in the appropriate category with YAML frontmatter (`name` and `description` fields). Good skills include: 1. **Real-world techniques** — Methods that work in practice 2. **Practical payloads** — Working examples with variations 3. **Validation steps** — How to confirm without false positives 4. **Context awareness** — Version/environment-specific behavior --- ### Cloud Cli (`docs/cloud/cli.mdx`) --- title: "Cloud CLI" description: "Drive app.strix.ai from the terminal with strix cloud" --- The `strix cloud` commands drive the managed platform ([app.strix.ai](https://app.strix.ai)) from the terminal. You do not need Docker or an LLM key. ## Sign In Sign in once with the browser device flow. The sign-in creates your account and workspace on first use, and it stores a personal API token in `~/.strix/platform-auth.json`. ```bash strix cloud login # browser approval, then workspace and scope profile strix cloud login --workspace "My Team" # select a workspace by name or ID strix cloud whoami # local account and workspace status strix cloud session # verify the remote session and consent ceiling strix cloud logout # revoke remotely, then remove the local token ``` A browser sign-in creates one reusable credential for each CLI installation. A second sign-in on the same installation replaces the secret instead of adding another key. `strix cloud logout` revokes the server session before it deletes the local token. Use `--local-only` when you cannot reach the server. ## Scopes The default **Recommended** preset covers normal scan work, local source uploads, workspace switching, and user-approved credit top-ups. It excludes credential creation, so request `tokens:write` when you need it. ```bash strix cloud login --scopes scans:read scans:write uploads:write billing:read strix cloud login --scope-profile minimal # also accepts recommended or full strix cloud session scopes # granted scopes and the login ceiling strix cloud session scopes set minimal # narrow without another browser sign-in ``` A workspace switch keeps the credential and its expiry, preserves the server-side scope preference, and caps access by the target role. A switch can never exceed the login consent ceiling. Each process pins the workspace it started with, so a concurrent switch fails safely instead of sending a stale command to another organization. ## Commands Every operation of the [REST API](https://docs.app.strix.ai) has a matching command in the form `strix cloud `. ```bash strix cloud # list all resources strix cloud scans # run the safe default (scans list) strix cloud scans help # list the verbs of a resource strix cloud domains add --domain example.com --asset-type web_app strix cloud scans start --engagement-type live_test --domain-ids --wait strix cloud vulns list --severity critical strix cloud credits # credit balance ``` Write commands take request fields as flags. Every write command also accepts one JSON object with `--data`: ```bash strix cloud scans start --data '{"engagement_type":"code_review"}' # literal JSON strix cloud scans start --data @request.json # read a file cat request.json | strix cloud scans start --data - # read standard input ``` `--token` and `STRIX_API_TOKEN` are stateless overrides for a single command, and they never replace the stored sign-in. Pair a CLI-session override with `--workspace-id` or `STRIX_WORKSPACE_ID`. ## Workspaces And Account Setup ```bash strix cloud workspaces list # numbered list; workspace is also accepted strix cloud workspaces create --name "My Team" # needs admin and organizations:write strix cloud workspaces use 2 # switch by list number, exact name, or ID strix cloud billing topup --credits 20 --yes # approve an agent payment after HTTP 402 strix cloud billing subscribe --plan strix_cloud # opens the hosted checkout page strix cloud billing portal # opens the billing portal strix cloud integrations install github # opens the app installation page strix cloud domains verify # prints the DNS record to add ``` The last four commands end at a person. Strix creates the link, opens the browser for an interactive terminal, and always prints the URL. The user enters the card, approves the installation, or adds the DNS record. Pass `--no-browser` to print the URL only. ## Output And Exit Codes The commands work for people and for agents. Terminal output favors names, branches, lifecycle states, and numbered selectors. Redirected output, and `--json`, preserve the complete machine-readable record. - Human lists keep the selectors that follow-up commands need, and they omit internal organization and user IDs. A selector that is too long for the compact table is repeated losslessly in a copyable block. - Paginated lists print the next `--page` or `--offset`. Detail views keep useful prose within a safe terminal bound, so use `--json` for the complete record. - Token lists separate API keys from named CLI device sessions. - Binary downloads are the exception to JSON output. Redirect the raw bytes on purpose, or use `--output FILE --json` to write the file and receive structured download metadata. - There are no prompts when stdin is not a terminal. Exit codes: `0` success, `1` error, `2` invalid usage, `4` authentication or plan limit, `5` payment required. ## Credits And Plan Limits Non-Enterprise scans consume the deterministic estimate shown for their scope. A source-only code review at the default `ultra` tier currently starts at 60 credits. Enterprise scans are plan-included and do not consume the credit wallet. Report downloads need Enterprise, schedules need Pro, and billing writes need an admin token. A plan block exits `4`. An insufficient credit wallet exits `5` without the creation of a scan and without a charge. ## Local Source Scans See [Scan Local Source](/cloud/overview#scan-local-source) for the upload approval flow, the exclusion rules, and the size limits. ## Tab Completion Enable native tab completion once for each shell session: ```bash source <(strix completions zsh) # use bash instead of zsh when appropriate strix completions fish | source ``` --- ### Integrations Ci Cd (`docs/integrations/ci-cd.mdx`) --- title: "CI/CD Integration" description: "Run Strix in any CI/CD pipeline" --- Strix runs in headless mode for automated pipelines. ## Headless Mode Use the `-n` or `--non-interactive` flag: ```bash strix -n --target ./app --scan-mode quick ``` For pull-request style CI runs, Strix automatically scopes quick scans to changed files. You can force this behavior and set a base ref explicitly: ```bash strix -n --target ./app --scan-mode quick --scope-mode diff --diff-base origin/main ``` ## Exit Codes | Code | Meaning | |------|---------| | 0 | No vulnerabilities found (with `--fail-on`, none at or above the threshold) | | 1 | Execution error | | 2 | Vulnerabilities found (with `--fail-on`, at least one at or above the threshold) | To fail only on serious findings, pass `--fail-on` with a minimum severity. Lower findings are still reported but exit `0`, so a passing job does not mean the report is empty.: ```bash strix -n --target ./app --scan-mode quick --fail-on high ``` ## GitLab CI ```yaml .gitlab-ci.yml security-scan: image: docker:latest services: - docker:dind variables: STRIX_LLM: $STRIX_LLM LLM_API_KEY: $LLM_API_KEY script: - curl -sSL https://strix.ai/install | bash - strix -n -t ./ --scan-mode quick ``` ## Jenkins ```groovy Jenkinsfile pipeline { agent any environment { STRIX_LLM = credentials('strix-llm') LLM_API_KEY = credentials('llm-api-key') } stages { stage('Security Scan') { steps { sh 'curl -sSL https://strix.ai/install | bash' sh 'strix -n -t ./ --scan-mode quick' } } } } ``` ## CircleCI ```yaml .circleci/config.yml version: 2.1 jobs: security-scan: docker: - image: cimg/base:current steps: - checkout - setup_remote_docker - run: name: Install Strix command: curl -sSL https://strix.ai/install | bash - run: name: Run Scan command: strix -n -t ./ --scan-mode quick ``` All CI platforms require Docker access. Ensure your runner has Docker available. If diff-scope fails in CI, fetch full git history (for example, `fetch-depth: 0` in GitHub Actions) so merge-base and branch comparison can be resolved. --- ### Integrations Coding Agents (`docs/integrations/coding-agents.mdx`) --- title: "Coding Agents" description: "Use Strix from Claude Code, Cursor, Codex, and other AI agents" --- Strix is built to be driven by AI coding agents. Install the official agent skills and your agent knows how to run pentests, remediate findings, and wire Strix into CI. ## Install the Skills Works with any agent that supports the open [SKILL.md standard](https://agentskills.io) — Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and dozens more: ```bash npx skills add usestrix/strix ``` | Skill | What your agent learns | |-------|------------------------| | `penetration-testing-with-strix` | Run headless scans against code, URLs, domains, or IPs — self-hosted CLI or managed cloud — with budget caps, and read the results | | `managed-pentesting-with-strix` | Drive the managed [app.strix.ai](https://app.strix.ai) platform over REST — no local Docker or LLM key needed | | `fix-security-vulnerabilities-with-strix` | Triage findings, fix root causes, and re-run Strix to verify each fix | | `ci-security-scanning-with-strix` | Add PR security scanning to GitHub Actions or any CI (self-hosted CLI or managed app) | | `application-security-testing` | Assess a whole product: choose the right test for each asset, then rank the findings into one remediation plan | | `web-app-penetration-testing` | Black-box pentest of a live web app or staging site — scope, credentials, and multi-account access-control testing | | `api-security-testing` | Test a REST/GraphQL API against the OWASP API Security Top 10 — schema-driven enumeration, BOLA/IDOR, authz | | `owasp-top-10-testing` | Systematic OWASP Top 10 assessment with honest per-category coverage | | `find-security-vulnerabilities-in-code` | White-box security review of a repo or working tree, with exploits to confirm findings | Install a single skill with `npx skills add usestrix/strix --skill penetration-testing-with-strix`, or use one without installing: ```bash npx skills use usestrix/strix@penetration-testing-with-strix | claude ``` ## Two ways to run — self-hosted or managed Both use the same engine and produce the same validated findings and SARIF, so agents can pick per situation or combine them: - **Open-source CLI (self-hosted)** — runs locally in a Docker sandbox with your own LLM key. Free, fully local, air-gap capable. Best for local dev loops and full control. - **Managed cloud** — runs on Strix's infrastructure. Drive it with the `strix cloud` CLI (every REST operation has a `strix cloud ` command) or the [app.strix.ai REST API](https://docs.app.strix.ai) directly. No Docker, no LLM key; adds team dashboards, scheduling, PR reviews, and downloadable PDF/DOCX reports (Enterprise plan). Best in sandboxed/CI environments and for teams. Sign in with `strix cloud login` (browser device sign-in, account created on first use) or create a token in the dashboard under **Settings → API Access**. The `managed-pentesting-with-strix` skill has the full flow. ## Agent-Friendly Interfaces Everything an agent needs is machine-readable: - **Headless CLI** — `strix -n` runs without the TUI and exits with `0` (clean), `1` (error), or `2` (vulnerabilities found). - **Cloud CLI** — `strix cloud` prints JSON when stdout is not a terminal (or with `--json`), never prompts without a TTY, and exits with `0` (success), `1` (error), `2` (usage), `4` (authentication required), or `5` (payment required). Credit top-ups pay the Stripe machine-payment challenge with an agent wallet (`strix cloud billing topup --credits N --yes`). Account setup also runs from the CLI: `strix cloud workspaces list|create|use`, `strix cloud org members invite`, `strix cloud billing subscribe`, `strix cloud billing portal`, and `strix cloud integrations install github`. The last three print a hosted link the user opens to finish the payment or approve the installation. - **REST API** — the managed platform exposes a documented [OpenAPI](https://docs.app.strix.ai/openapi.json) at `https://app.strix.ai/api/v1` (scans, vulnerabilities, assets, PR reviews, schedules, webhooks) with bearer tokens and scopes. - **Structured results** — every run writes `vulnerabilities.json`, `vulnerabilities.csv`, `findings.sarif` (SARIF 2.1.0), and per-finding Markdown under `strix_runs//`; the cloud exposes the same as JSON plus SARIF export. - **Budget controls** — `--max-budget` and `--max-turns` give agents hard cost/time caps. - **`AGENTS.md`** — the [repository's agent guide](https://github.com/usestrix/strix/blob/main/AGENTS.md) with a quick reference. - **`llms.txt`** — this documentation is indexed at [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) and fully exported at [docs.strix.ai/llms-full.txt](https://docs.strix.ai/llms-full.txt); every page is also available as Markdown by appending `.md` to its URL. ## Example Prompts Once the skills are installed, prompts like these just work: ```text Pentest this repo with Strix (quick mode, $10 budget) and summarize the findings. ``` ```text Fix all critical and high findings from the last Strix run, then re-scan to verify. ``` ```text Add Strix security scanning to our GitHub Actions so every PR gets tested. ``` --- ### Integrations Github Actions (`docs/integrations/github-actions.mdx`) --- title: "GitHub Actions" description: "Run Strix security scans on every pull request" --- Integrate Strix into your GitHub workflow to catch vulnerabilities before they reach production. ## Basic Workflow ```yaml .github/workflows/security.yml name: Security Scan on: pull_request: jobs: strix-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Install Strix run: curl -sSL https://strix.ai/install | bash - name: Run Security Scan env: STRIX_LLM: ${{ secrets.STRIX_LLM }} LLM_API_KEY: ${{ secrets.LLM_API_KEY }} run: strix -n -t ./ --scan-mode quick ``` ## Required Secrets Add these secrets to your repository: | Secret | Description | |--------|-------------| | `STRIX_LLM` | Model name (e.g., `openrouter/z-ai/glm-5.3`) | | `LLM_API_KEY` | API key for your LLM provider | ## Exit Codes The workflow fails when vulnerabilities are found: | Code | Result | |------|--------| | 0 | Pass — No vulnerabilities (with `--fail-on`, none at or above the threshold) | | 2 | Fail — Vulnerabilities found | Add `--fail-on high` (or `critical`, `medium`, `low`) to fail only on findings at or above that severity. Lower findings still appear in the report, so a passing run is not necessarily finding-free. ## Scan Modes for CI | Mode | Duration | Use Case | |------|----------|----------| | `quick` | Minutes | Every PR | | `standard` | ~30 min | Nightly builds | | `deep` | 1-4 hours | Release candidates | Use `quick` mode for PRs to keep feedback fast. Schedule `deep` scans nightly. For pull_request workflows, Strix automatically uses changed-files diff-scope in CI/headless runs. If diff resolution fails, ensure full history is fetched (`fetch-depth: 0`) or set `--diff-base`. --- ### Integrations Mcp (`docs/integrations/mcp.mdx`) --- title: "MCP Servers" description: "Connect your own MCP servers and expose their tools to the agent" --- Strix can connect to [Model Context Protocol (MCP)](https://modelcontextprotocol.io) servers you list and expose their tools to the agent during a run. Use this to let the agent read how your system is actually built instead of inferring it from the outside. A few things it pays off for: - **A database server.** The agent can read the schema and access policies and see tables left readable without them, rather than guessing from responses. - **A hosting or infrastructure server.** Deployments, domains and environment variable names tell it what is really running, so it tests what exists instead of what it discovered by crawling. - **An issue tracker.** Known and accepted risks stop the agent re-reporting findings you already triaged. - **A logging server.** Reading logs lets it confirm an exploit attempt actually landed instead of inferring it from a status code. ## Setup Create the file `~/.strix/mcp-servers.json`. It holds a JSON list of the servers you want the agent to reach. Each entry is either a local `stdio` server that Strix launches as a subprocess, or a remote `http` server. Create the directory if it does not exist, then write the file: ```bash mkdir -p ~/.strix ``` Paste the servers you want into `~/.strix/mcp-servers.json`. The example below shows one of each transport: a local filesystem server over `stdio` and a remote GitHub server over `http` with a bearer token: ```json [ { "name": "local_fs", "transport": "stdio", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"] }, { "name": "github", "transport": "http", "url": "https://api.githubcopilot.com/mcp/", "auth": { "kind": "bearer", "token": "your-token" }, "allowed_tools": ["list_issues"] } ] ``` Strix reads this file at the start of each run. There is no default file, so no MCP tools are loaded until you create it. Edit `command`, `args`, `url`, and `token` to match your own servers. ## Fields A short label for the connection. Each server's tools are namespaced by `name` (for example `local_fs_read_file`), so two servers can offer the same tool name without colliding. `stdio` for a local subprocess server, or `http` for a remote server. For `stdio` servers: the executable Strix launches (for example `npx`). For `stdio` servers: the arguments passed to `command`. For `http` servers: the server endpoint URL. For `http` servers that need a bearer token: `{ "kind": "bearer", "token": "your-token" }`. Restrict which tools the agent can call. Omit it to expose every tool the server offers, or set it to a list of tool names to allow only those. Strix does not decide for you which of a server's tools only read and which change things, so run the server in its own read-only mode if it has one. Free-text notes for the agent about what this connection is and how you want it used, for example "Staging analytics database, read-only, prefer aggregate queries." When set, the notes are given to the agent at the start of the run as a description of the connection. ## Choosing connections per run By default every connection in the file is used on each run. To narrow it for a single run without editing the file, use either flag (both repeatable): ```bash strix --mcp-server github -t ... # use only the named connection(s) strix --mcp-exclude staging-db -t ... # use everything except the named one(s) ``` `--mcp-server` keeps only the connections you name; `--mcp-exclude` drops the ones you name. Connection names must be unique in the file; if two entries share a name, the first is kept and the rest are ignored. ## Pointing at a different file To read the config from another path instead of `~/.strix/mcp-servers.json`, either pass `--mcp-config ` on the command line: ```bash strix --mcp-config ./mcp-servers.json -t ... ``` or set the `STRIX_MCP_CONFIG` environment variable to that path. The flag takes precedence when both are given. ## Startup confirmation When servers are configured, Strix prints a one-line summary at scan startup, for example `MCP: connected 1 server (14 tools): local_fs`, so you can confirm your servers connected. ## Seeing the calls Each call the agent makes to one of your servers is shown with its own icon and labelled with the connection it went out to, in the terminal and in the run viewer (`strix view`), so a call that left Strix for a server you connected is easy to pick out of a transcript. The terminal shows the call and its arguments; results can be large and arbitrary, so read them in the viewer, which shows a preview you can expand. ## Behavior - The config file is optional. Without it, a run simply gets no MCP tools. - A server that fails to connect is skipped and logged, and the run continues without it. - A single malformed entry is skipped without blocking the valid ones. --- ### Llm Providers Anthropic (`docs/llm-providers/anthropic.mdx`) --- title: "Anthropic" description: "Configure Strix with Claude models" --- ## Setup ```bash export STRIX_LLM="anthropic/claude-sonnet-4-6" export LLM_API_KEY="sk-ant-..." ``` ## Available Models | Model | Description | |-------|-------------| | `anthropic/claude-sonnet-4-6` | Best balance of intelligence and speed | | `anthropic/claude-opus-4-6` | Maximum capability for deep analysis | ## Get API Key 1. Go to [console.anthropic.com](https://console.anthropic.com) 2. Navigate to API Keys 3. Create a new key --- ### Llm Providers Azure (`docs/llm-providers/azure.mdx`) --- title: "Azure OpenAI" description: "Configure Strix with OpenAI models via Azure" --- ## Setup ```bash export STRIX_LLM="azure/your-gpt5-deployment" export AZURE_API_KEY="your-azure-api-key" export AZURE_API_BASE="https://your-resource.openai.azure.com" export AZURE_API_VERSION="2025-11-01-preview" ``` ## Configuration | Variable | Description | |----------|-------------| | `STRIX_LLM` | `azure/` | | `AZURE_API_KEY` | Your Azure OpenAI API key | | `AZURE_API_BASE` | Your Azure OpenAI endpoint URL | | `AZURE_API_VERSION` | API version (e.g., `2025-11-01-preview`) | ## Example ```bash export STRIX_LLM="azure/gpt-5.4-deployment" export AZURE_API_KEY="abc123..." export AZURE_API_BASE="https://mycompany.openai.azure.com" export AZURE_API_VERSION="2025-11-01-preview" ``` ## Prerequisites 1. Create an Azure OpenAI resource 2. Deploy a model (e.g., GPT-5.4) 3. Get the endpoint URL and API key from the Azure portal --- ### Llm Providers Bedrock (`docs/llm-providers/bedrock.mdx`) --- title: "AWS Bedrock" description: "Configure Strix with models via AWS Bedrock" --- ## Setup ```bash export STRIX_LLM="bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0" ``` No API key required—uses AWS credentials from environment. ## Authentication ### Option 1: AWS CLI Profile ```bash export AWS_PROFILE="your-profile" export AWS_REGION="us-east-1" ``` ### Option 2: Access Keys ```bash export AWS_ACCESS_KEY_ID="AKIA..." export AWS_SECRET_ACCESS_KEY="..." export AWS_REGION="us-east-1" ``` ### Option 3: IAM Role (EC2/ECS) Automatically uses instance role credentials. ## Available Models | Model | Description | |-------|-------------| | `bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0` | Claude 4.5 Sonnet | | `bedrock/anthropic.claude-4-5-opus-20251022-v1:0` | Claude 4.5 Opus | | `bedrock/anthropic.claude-4-5-haiku-20251022-v1:0` | Claude 4.5 Haiku | | `bedrock/amazon.titan-text-premier-v2:0` | Amazon Titan Premier v2 | ## Prerequisites 1. Enable model access in the AWS Bedrock console 2. Ensure your IAM role/user has `bedrock:InvokeModel` permission --- ### Llm Providers Local (`docs/llm-providers/local.mdx`) --- title: "Local Models" description: "Run Strix with self-hosted LLMs for privacy and air-gapped testing" --- Running Strix with local models allows for completely offline, privacy-first security assessments. Data never leaves your machine, making this ideal for sensitive internal networks or air-gapped environments. ## Privacy vs Performance | Feature | Local Models | Cloud Models (GPT-5/Claude 4.5) | |---------|--------------|--------------------------------| | **Privacy** | 🔒 Data stays local | Data sent to provider | | **Cost** | Free (hardware only) | Pay-per-token | | **Reasoning** | Lower (struggles with agents) | State-of-the-art | | **Setup** | Complex (GPU required) | Instant | **Compatibility Note**: Strix relies on advanced agentic capabilities (tool use, multi-step planning, self-correction). Most local models, especially those under 70B parameters, struggle with these complex tasks. For critical assessments, we strongly recommend using state-of-the-art cloud models like **Claude 4.5 Sonnet** or **GPT-5**. Use local models only when privacy is the absolute priority. ## Ollama [Ollama](https://ollama.ai) is the easiest way to run local models on macOS, Linux, and Windows. ### Setup 1. Install Ollama from [ollama.ai](https://ollama.ai) 2. Pull a high-performance model: ```bash ollama pull qwen3-vl ``` 3. Configure Strix: ```bash export STRIX_LLM="ollama/qwen3-vl" export LLM_API_BASE="http://localhost:11434" ``` ### Recommended Models We recommend these models for the best balance of reasoning and tool use: **Recommended models:** - **Qwen3 VL** (`ollama pull qwen3-vl`) - **DeepSeek V3.1** (`ollama pull deepseek-v3.1`) - **Devstral 2** (`ollama pull devstral-2`) ## LM Studio / OpenAI Compatible If you use LM Studio, vLLM, or other runners: ```bash export STRIX_LLM="openai/local-model" export LLM_API_BASE="http://localhost:1234/v1" # Adjust port as needed ``` ### Gateways that require custom headers Some OpenAI-compatible gateways require extra HTTP headers (for attribution or tenant routing) alongside the bearer token. Set them with `LLM_EXTRA_HEADERS` as a JSON object — they are sent on every request: ```bash export STRIX_LLM="openai/your-model" export LLM_API_BASE="https://your-gateway.example/v1" export LLM_API_KEY="your-bearer-token" # sent as Authorization: Bearer ... export LLM_EXTRA_HEADERS='{"X-Feature-Key":"value","X-Tenant":"acme"}' ``` ### Extra request-body fields Some provider parameters go in the request body rather than a header, and Strix has no dedicated setting for them. Set them with `LLM_EXTRA_BODY` as a JSON object — they are merged into the body of every request to the model. For example, to use OpenAI's cheaper flex processing and attribute requests to a user with a safety identifier (a hash, never a raw email): ```bash export LLM_EXTRA_BODY='{"service_tier":"flex","safety_identifier":"9f86d081884c7d65"}' ``` Fields aren't validated, so use only fields your provider accepts, and don't set fields Strix already sends, such as `model`, `messages` or `stream`. For endpoints behind a private CA, point Strix at your certificate bundle with the standard `SSL_CERT_FILE=/path/to/ca-bundle.pem` — never disable TLS verification against a real endpoint. ## Tool calling must return structured `tool_calls` Strix is entirely tool-driven: every working turn must be a **native** function/tool call. If your inference server returns the tool call as plain assistant text instead of a structured `tool_calls` field, Strix never sees a call it can execute, so the agent makes no real progress — it re-prompts the model for a tool call and gives up once its recovery attempts are exhausted. This is almost always an **inference-server configuration** problem, not a model or Strix problem. Common symptoms are the model printing a call as text such as: ```text {"name": "exec_command", "arguments": {"cmd": "nmap ..."}} exec_command(cmd="nmap ...", timeout=180) {"action": "exec_command", "params": {"cmd": "nmap ..."}} ``` The fix belongs on the inference server: it must be configured to parse the model's tool tokens into structured `tool_calls`. A correctly configured endpoint either returns a structured call or rejects the request outright — it never leaks the call as text. ### Fixes by server **llama.cpp (`llama-server`)** - Run with `--jinja` and a correct tool-use chat template (`--chat-template` / `--chat-template-file` matching the model). Recent builds enable `--jinja` by default — **upgrade** if yours doesn't. - For thinking models, align or disable reasoning (`--reasoning-format`, `-rea off`) so it doesn't break tool-call parsing. - A low temperature (e.g. `--temp 0.2`) improves tool-call reliability. **Ollama** - Use a recent Ollama and a model whose template wires tools. Modern Ollama refuses tools (`tools param requires --jinja flag`) if the template lacks tool support. - For reasoning models (e.g. qwen3), disable the model's **thinking** mode — thinking left on frequently pushes the tool call into the text `content` instead of the structured `tool_calls` field. Turn it off on the Ollama side (a non-thinking model variant, or `think: false` in the model's parameters / `Modelfile`). - Raise **`num_ctx`** to at least 16k–32k. Strix sends a large system prompt plus many tool schemas; at Ollama's small default context the tool definitions are truncated out of the prompt and the model stops emitting valid calls. A short test prompt can look fine while a real scan fails, so set this explicitly rather than inferring it from a quick check. **vLLM** - Start with `--enable-auto-tool-choice`, a matching `--tool-call-parser` (`hermes`, `qwen3_xml`, or `llama3_json`), and a matching `--reasoning-parser` for reasoning models. A low sampling temperature (roughly 0.2–0.6, depending on the family) also measurably reduces malformed tool calls on open-weight models. Set it on the server or in your model's parameters. Even correctly configured, small models (< ~30B) emit malformed or text-form tool calls far more often than frontier models. Prefer a capable model for reliable agentic behavior. --- ### Llm Providers Novita (`docs/llm-providers/novita.mdx`) --- title: "Novita AI" description: "Configure Strix with Novita AI models" --- [Novita AI](https://novita.ai) provides fast, cost-efficient inference for open-source models via an OpenAI-compatible API. ## Setup ```bash export STRIX_LLM="openai/moonshotai/kimi-k2.5" export LLM_API_KEY="your-novita-api-key" export LLM_API_BASE="https://api.novita.ai/openai" ``` ## Available Models | Model | Configuration | |-------|---------------| | GLM-5.3 | `openai/zai-org/glm-5.3` | | Kimi K3 | `openai/moonshotai/kimi-k3` | | DeepSeek V4 Pro | `openai/deepseek/deepseek-v4-pro` | | Kimi K2.5 | `openai/moonshotai/kimi-k2.5` | | GLM-5 | `openai/zai-org/glm-5` | | MiniMax M2.5 | `openai/minimax/minimax-m2.5` | ## Get API Key 1. Sign up at [novita.ai](https://novita.ai) 2. Navigate to **API Keys** in your dashboard 3. Create a new key and copy it ## Benefits - **Cost-efficient** — Competitive pricing with per-token billing - **OpenAI-compatible** — Drop-in replacement using `LLM_API_BASE` - **Large context** — Models support up to 262k token context windows - **Function calling** — All listed models support tool/function calling --- ### Llm Providers Openai (`docs/llm-providers/openai.mdx`) --- title: "OpenAI" description: "Configure Strix with OpenAI models" --- ## Setup ```bash export STRIX_LLM="openai/gpt-5.4" export LLM_API_KEY="sk-..." ``` ## Available Models See [OpenAI Models Documentation](https://platform.openai.com/docs/models) for the full list of available models. ## Get API Key 1. Go to [platform.openai.com](https://platform.openai.com) 2. Navigate to API Keys 3. Create a new secret key ## Custom Base URL For OpenAI-compatible APIs: ```bash export STRIX_LLM="openai/gpt-5.4" export LLM_API_KEY="your-key" export LLM_API_BASE="https://your-proxy.com/v1" ``` --- ### Llm Providers Openrouter (`docs/llm-providers/openrouter.mdx`) --- title: "OpenRouter" description: "Configure Strix with models via OpenRouter" --- [OpenRouter](https://openrouter.ai) provides access to 100+ models from multiple providers through a single API. ## Setup ```bash export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="sk-or-..." ``` ## Available Models Access any model on OpenRouter using the format `openrouter//`: | Model | Configuration | |-------|---------------| | GLM-5.3 (default) | `openrouter/z-ai/glm-5.3` | | GPT-5.4 | `openrouter/openai/gpt-5.4` | | Claude Sonnet 4.6 | `openrouter/anthropic/claude-sonnet-4.6` | | Gemini 3 Pro | `openrouter/google/gemini-3-pro-preview` | | DeepSeek V4 Pro | `openrouter/deepseek/deepseek-v4-pro` | | Kimi K3 | `openrouter/moonshotai/kimi-k3` | | GLM-4.7 | `openrouter/z-ai/glm-4.7` | ## Get API Key 1. Go to [openrouter.ai](https://openrouter.ai) 2. Sign in and navigate to Keys 3. Create a new API key ## Benefits - **Single API** — Access models from OpenAI, Anthropic, Google, Meta, and more - **Fallback routing** — Automatic failover between providers - **Cost tracking** — Monitor usage across all models - **Higher rate limits** — OpenRouter handles provider limits for you --- ### Llm Providers Vercel Ai Gateway (`docs/llm-providers/vercel-ai-gateway.mdx`) --- title: "Vercel AI Gateway" description: "Configure Strix with models via Vercel AI Gateway" --- [Vercel AI Gateway](https://vercel.com/docs/ai-gateway) provides an OpenAI-compatible API for models from multiple providers. ## Setup Create an [AI Gateway API key](https://vercel.com/docs/ai-gateway/authentication-and-byok), then configure Strix: ```bash export STRIX_LLM="openai/anthropic/claude-opus-5" export LLM_API_KEY="your-ai-gateway-api-key" export LLM_API_BASE="https://ai-gateway.vercel.sh/v1" ``` The first `openai/` segment tells Strix to use its OpenAI-compatible client. The remaining value is the [AI Gateway model ID](https://vercel.com/docs/ai-gateway/models-and-providers). ## Available Models Use any language model returned by the AI Gateway models endpoint: ```text https://ai-gateway.vercel.sh/v1/models ``` Prefix its model ID with `openai/` when setting `STRIX_LLM`. For example, the Gateway model ID `anthropic/claude-opus-5` becomes `openai/anthropic/claude-opus-5` in Strix. ## Get API Key 1. Open the [AI Gateway API key settings](https://vercel.com/docs/ai-gateway/authentication-and-byok) 2. Create an API key 3. Set the key as `LLM_API_KEY` ## Benefits - Access models from multiple providers through one endpoint - Track Gateway usage and cost in Vercel --- ### Llm Providers Vertex (`docs/llm-providers/vertex.mdx`) --- title: "Google Vertex AI" description: "Configure Strix with Gemini models via Google Cloud" --- ## Setup ```bash export STRIX_LLM="vertex_ai/gemini-3-pro-preview" ``` No API key required—uses Google Cloud Application Default Credentials. ## Authentication ### Option 1: gcloud CLI ```bash gcloud auth application-default login ``` ### Option 2: Service Account ```bash export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json" ``` ## Available Models | Model | Description | |-------|-------------| | `vertex_ai/gemini-3-pro-preview` | Best overall performance for security testing | | `vertex_ai/gemini-3-flash-preview` | Faster and cheaper | ## Project Configuration ```bash export VERTEXAI_PROJECT="your-project-id" export VERTEXAI_LOCATION="global" ``` ## Prerequisites 1. Enable the Vertex AI API in your Google Cloud project 2. Ensure your account has the `Vertex AI User` role --- ### Tools Browser (`docs/tools/browser.mdx`) --- title: "Browser" description: "Playwright-powered Chrome for web application testing" --- Strix uses a headless Chrome browser via Playwright to interact with web applications exactly like a real user would. ## How It Works All browser traffic is automatically routed through the Caido proxy, giving Strix full visibility into every request and response. This enables: - Testing client-side vulnerabilities (XSS, DOM manipulation) - Navigating authenticated flows (login, OAuth, MFA) - Triggering JavaScript-heavy functionality - Capturing dynamically generated requests ## Capabilities | Action | Description | | ---------- | ------------------------------------------- | | Navigate | Go to URLs, follow links, handle redirects | | Click | Interact with buttons, links, form elements | | Type | Fill in forms, search boxes, input fields | | Execute JS | Run custom JavaScript in the page context | | Screenshot | Capture visual state for reports | | Multi-tab | Test across multiple browser tabs | ## Example Flow 1. Agent launches browser and navigates to login page 2. Fills in credentials and submits form 3. Proxy captures the authentication request 4. Agent navigates to protected areas 5. Tests for IDOR by replaying requests with modified IDs --- ### Tools Proxy (`docs/tools/proxy.mdx`) --- title: "HTTP Proxy" description: "Caido-powered proxy for request interception and replay" --- Strix includes [Caido](https://caido.io), a modern HTTP proxy built for security testing. All browser traffic flows through Caido, giving the agent full control over requests and responses. ## Capabilities | Feature | Description | | ---------------- | -------------------------------------------- | | Request Capture | Log all HTTP/HTTPS traffic automatically | | Request Replay | Repeat any request with modifications | | HTTPQL | Query captured traffic with powerful filters | | Scope Management | Focus on specific domains or paths | | Sitemap | Visualize the discovered attack surface | ## HTTPQL Filtering Query captured requests using Caido's HTTPQL syntax ## Request Replay The agent can take any captured request and replay it with modifications: - Change path parameters (test for IDOR) - Modify request body (test for injection) - Add/remove headers (test for auth bypass) - Alter cookies (test for session issues) ## Python Integration Proxy helpers are available to sandbox Python scripts through the image-baked `caido_api` module. This enables powerful scripted security testing: ```python import asyncio from caido_api import list_requests, repeat_request, view_request async def main(): # List recent POST requests post_requests = await list_requests( httpql_filter='req.method.eq:"POST"', first=20, ) # View a specific request request_details = await view_request("req_123", part="request") # Replay with modified payload response = await repeat_request( "req_123", modifications={"body": '{"user_id": "admin"}'}, ) print(response["status"], request_details is not None, len(post_requests.edges)) asyncio.run(main()) ``` ### Available Functions | Function | Description | | ---------------------- | ------------------------------------------ | | `list_requests()` | Query captured traffic with HTTPQL filters | | `view_request()` | Get full request/response details | | `repeat_request()` | Replay a request with modifications | | `list_sitemap()` | Browse the request-tree view of discovered surface | | `view_sitemap_entry()` | Inspect one sitemap entry + its related requests | | `scope_rules()` | Manage proxy scope (allowlist/denylist) | For one-off arbitrary requests, use shell tooling like `curl` — the sandbox's `HTTP_PROXY` env routes the traffic through Caido automatically, so it lands in `list_requests` and can be replayed via `repeat_request`. ### Example: Automated IDOR Testing ```python import asyncio # Get all requests to user endpoints from caido_api import list_requests, repeat_request async def main(): user_requests = await list_requests(httpql_filter='req.path.cont:"/users/"') for edge in user_requests.edges: req = edge.node.request scheme = "https" if req.is_tls else "http" for test_id in ["1", "2", "admin", "../admin"]: url = f"{scheme}://{req.host}{req.path.replace('/users/1', f'/users/{test_id}')}" response = await repeat_request( req.id, modifications={"url": url}, ) print(req.id, test_id, response["status"]) if response["status"] == "DONE": print(f"Replay completed for candidate {test_id}") asyncio.run(main()) ``` ## Human-in-the-Loop Strix exposes the Caido proxy to your host machine, so you can interact with it alongside the automated scan. When the sandbox starts, the Caido URL is displayed in the TUI sidebar — click it to copy, then open it in Caido Desktop. ### Accessing Caido 1. Start a scan as usual 2. Look for the **Caido** URL in the sidebar stats panel (e.g. `localhost:52341`) 3. Open the URL in Caido Desktop 4. Click **Continue as guest** to access the instance ### What You Can Do - **Inspect traffic** — Browse all HTTP/HTTPS requests the agent is making in real time - **Replay requests** — Take any captured request and resend it with your own modifications - **Intercept and modify** — Pause requests mid-flight, edit them, then forward - **Explore the sitemap** — See the full attack surface the agent has discovered - **Manual testing** — Use Caido's tools to test findings the agent reports, or explore areas it hasn't reached This turns Strix from a fully automated scanner into a collaborative tool — the agent handles the heavy lifting while you focus on the interesting parts. ## Scope Create scopes to filter traffic to relevant domains: ``` Allowlist: ["api.example.com", "*.example.com"] Denylist: ["*.gif", "*.jpg", "*.png", "*.css", "*.js"] ``` --- ### Tools Sandbox (`docs/tools/sandbox.mdx`) --- title: "Sandbox Tools" description: "Pre-installed security tools in the Strix container" --- Strix runs inside a Kali Linux-based Docker container with a comprehensive set of security tools pre-installed. The agent can use any of these tools through the [terminal](/tools/terminal). ## Reconnaissance | Tool | Description | | ---------------------------------------------------------- | -------------------------------------- | | [Subfinder](https://github.com/projectdiscovery/subfinder) | Subdomain discovery | | [Naabu](https://github.com/projectdiscovery/naabu) | Fast port scanner | | [httpx](https://github.com/projectdiscovery/httpx) | HTTP probing and analysis | | [Katana](https://github.com/projectdiscovery/katana) | Web crawling and spidering | | [ffuf](https://github.com/ffuf/ffuf) | Fast web fuzzer | | [Nmap](https://nmap.org) | Network scanning and service detection | ## Web Testing | Tool | Description | | ------------------------------------------------------ | -------------------------------- | | [Arjun](https://github.com/s0md3v/Arjun) | HTTP parameter discovery | | [Dirsearch](https://github.com/maurosoria/dirsearch) | Directory and file brute-forcing | | [wafw00f](https://github.com/EnableSecurity/wafw00f) | WAF fingerprinting | | [GoSpider](https://github.com/jaeles-project/gospider) | Web spider for link extraction | ## Automated Scanners | Tool | Description | | ---------------------------------------------------- | -------------------------------------------------- | | [Nuclei](https://github.com/projectdiscovery/nuclei) | Template-based vulnerability scanner | | [SQLMap](https://sqlmap.org) | Automatic SQL injection detection and exploitation | | [Wapiti](https://wapiti-scanner.github.io) | Web application vulnerability scanner | | [ZAP](https://zaproxy.org) | OWASP Zed Attack Proxy | ## JavaScript Analysis | Tool | Description | | -------------------------------------------------------- | ------------------------------ | | [JS-Snooper](https://github.com/aravind0x7/JS-Snooper) | JavaScript reconnaissance | | [jsniper](https://github.com/xchopath/jsniper.sh) | JavaScript file analysis | | [Retire.js](https://retirejs.github.io/retire.js) | Detect vulnerable JS libraries | | [ESLint](https://eslint.org) | JavaScript static analysis | | [js-beautify](https://github.com/beautifier/js-beautify) | JavaScript deobfuscation | | [JSHint](https://jshint.com) | JavaScript code quality tool | ## Source-Aware Analysis | Tool | Description | | ------------------------------------------------------- | --------------------------------------------- | | [Semgrep](https://github.com/semgrep/semgrep) | Fast SAST and custom rule matching | | [ast-grep](https://ast-grep.github.io) | Structural AST/CST-aware code search (`sg`) | | [Tree-sitter](https://tree-sitter.github.io/tree-sitter/) | Syntax tree parsing and symbol extraction (Java/JS/TS/Python/Go/Bash/JSON/YAML grammars pre-configured) | | [Bandit](https://bandit.readthedocs.io) | Python security linter | ## Secret Detection | Tool | Description | | ----------------------------------------------------------- | ------------------------------------- | | [TruffleHog](https://github.com/trufflesecurity/trufflehog) | Find secrets in code and history | | [Gitleaks](https://github.com/gitleaks/gitleaks) | Detect hardcoded secrets in repositories | ## Authentication Testing | Tool | Description | | ------------------------------------------------------------ | ---------------------------------- | | [jwt_tool](https://github.com/ticarpi/jwt_tool) | JWT token testing and exploitation | | [Interactsh](https://github.com/projectdiscovery/interactsh) | Out-of-band interaction detection | ## Container & Supply Chain | Tool | Description | | -------------------------- | ---------------------------------------------- | | [Trivy](https://trivy.dev) | Filesystem/container scanning for vulns, misconfigurations, secrets, and licenses | ## HTTP Proxy | Tool | Description | | ------------------------- | --------------------------------------------- | | [Caido](https://caido.io) | Modern HTTP proxy for interception and replay | ## Browser | Tool | Description | | ------------------------------------ | --------------------------- | | [Playwright](https://playwright.dev) | Headless browser automation | All tools are pre-configured and ready to use. The agent selects the appropriate tool based on the vulnerability being tested. --- ### Tools Terminal (`docs/tools/terminal.mdx`) --- title: "Terminal" description: "Bash shell for running commands and security tools" --- Strix has access to a persistent bash terminal running inside the Docker sandbox. This gives the agent access to all [pre-installed security tools](/tools/sandbox). ## Capabilities | Feature | Description | | ----------------- | ---------------------------------------------------------- | | Persistent state | Working directory and environment persist between commands | | Multiple sessions | Run parallel terminals for concurrent operations | | Background jobs | Start long-running processes without blocking | | Interactive | Respond to prompts and control running processes | ## Common Uses ### Running Security Tools ```bash # Subdomain enumeration subfinder -d example.com # Vulnerability scanning nuclei -u https://example.com # SQL injection testing sqlmap -u "https://example.com/page?id=1" ``` ### Code Analysis ```bash # Fast SAST triage semgrep --config auto ./src # Structural AST search sg scan ./src # Secret detection gitleaks detect --source ./ trufflehog filesystem ./ # Supply-chain and misconfiguration checks trivy fs ./ ``` ### Custom Scripts ```bash # Run Python exploits python3 exploit.py # Execute shell scripts ./test_auth_bypass.sh ``` ## Session Management The agent can run multiple terminal sessions concurrently, for example: - Main session for primary testing - Secondary session for monitoring - Background processes for servers or watchers --- ### Usage Cli (`docs/usage/cli.mdx`) --- title: "CLI Reference" description: "Command-line options for Strix" --- ## Basic Usage ```bash strix (--target | --target-list ) [options] ``` ## Options Target to test. Accepts URLs, repositories, local directories, domains, IP addresses, API spec files (OpenAPI/Swagger `.json`/`.yaml`, a Postman collection export), or a live Postman collection by id (`postman://`). Can be specified multiple times. Fresh runs require at least one target source: `--target` or `--target-list`. When the target is an API spec, Strix copies it into the agent's workspace and authorizes the base URLs it declares (including those resolved from a Postman environment) as in-scope hosts - so the agent reads the contract and tests the full declared surface instead of discovering endpoints by crawling. Pair the spec with the deployed base URL (e.g. `--target ./openapi.yaml --target https://api.example.com`) so the agent has a reachable host to attack. A local directory is mounted into the sandbox live and **writable**, so the agent edits your real files (`.git` excepted). Commit or stash first. Fetching a Postman collection by id requires `POSTMAN_API_KEY`. Add `?env=` to also pull a Postman environment, which resolves `{{baseUrl}}` / token variables the collection references (e.g. `postman://?env=`). Path to a file containing targets, one per non-empty, non-comment line. Lines starting with `#` are ignored. Can be specified multiple times and combined with `--target`. Custom instructions for the scan. Use for credentials, focus areas, or specific testing approaches. Path to a file containing detailed instructions. Path to a file on your machine to place into the sandbox workspace before the scan starts. Repeat the option for more files. Write `PATH:DEST` to choose the destination inside `/workspace`. `DEST` defaults to the file name. See [Workspace files](/usage/instructions#workspace-files). Scan depth: `quick`, `standard`, or `deep`. Code scope mode: `auto` (enable PR diff-scope in CI/headless runs), `diff` (force changed-files scope), or `full` (disable diff-scope). Target branch or commit to compare against (e.g., `origin/main`). Defaults to the repository's default branch. Run in headless mode without TUI. Ideal for CI/CD. When no terminal is attached (CI, `nohup`, pipes) and a target is given, Strix runs headless automatically and says so on one line. Headless mode only (requires `-n`). Minimum severity that makes the run exit `2`: `critical`, `high`, `medium`, `low`, or `info`. Findings below the threshold are still written to every report artifact. A finding whose severity Strix does not recognize always counts, so the gate never passes on a value it cannot rank. Omit the flag to exit `2` on any finding. Path to a custom config file (JSON) to use instead of `~/.strix/cli-config.json`. Maximum LLM spend in USD for the whole scan, counted cumulatively across the root agent and every child agent. The budget is checked after each model response. In non-interactive mode (`-n`), once the running cost reaches the threshold, the scan stops cleanly with a `stopped` status (not a failure) and the sandbox is torn down. Sub-agents are stopped early, at 90% of the budget, reserving the final slice for the root agent to wind down and produce the final report. In interactive mode, reaching the budget pauses the scan instead of ending it: every agent parks, and sending any message resumes the scan with the cap extended by the original budget amount. There is no sub-agent reserve in interactive mode. As the budget is approached, graduated wrap-up warnings are surfaced to **every** agent so they can finish their work and call their lifecycle tool before the hard stop. The bands sit just below each role's own stop point: the root is warned at **70%, 85% and 95%** (it stops at 100%), while sub-agents are warned at **75%, 80% and 85%** (they stop at the 90% reserve). In interactive mode every agent uses the **70%, 85% and 95%** bands. Percentages shown in the warnings are the real cumulative spend against the full budget. Must be greater than `0`. Omit the flag for no limit. **Limitations** - The check fires *after* a response is returned, so the final spend can slightly overshoot the limit by any calls already in flight when the threshold is crossed (most relevant with several child agents running concurrently). - Cost is a best-effort estimate derived from token usage and model pricing; providers that do not expose priced usage may under-count. - For LiteLLM-routed models, Strix enables streaming success callbacks to capture provider-reported cost. Message content remains excluded, but third-party LiteLLM callbacks configured in the same process can receive other streaming metadata such as model names, request IDs, and token counts. Maximum number of turns (one model response plus its tool round) allotted to **each** agent, applied per run. When an agent reaches this limit it is force-stopped. As the limit is approached, graduated wrap-up warnings (at 70%, 85% and 95%) are injected into that agent's next model turn so it can prioritise its remaining work and call its lifecycle tool (`finish_scan` for the root agent, `agent_finish` for sub-agents) before the hard stop. Must be greater than `0`. ## Examples ```bash # Basic scan strix --target https://example.com # Authenticated testing strix --target https://app.com --instruction "Use credentials: user:pass" # Focused testing strix --target api.example.com --instruction "Focus on IDOR and auth bypass" # CI/CD mode strix -n --target ./ --scan-mode quick # CI/CD mode, failing only on high or critical findings strix -n --target ./ --scan-mode quick --fail-on high # Cap cost and per-agent turns strix --target https://example.com --max-budget 25 --max-turns 300 # Force diff-scope against a specific base ref strix -n --target ./ --scan-mode quick --scope-mode diff --diff-base origin/main # Multi-target white-box testing strix -t https://github.com/org/app -t https://staging.example.com # API spec + live target (OpenAPI/Swagger file or Postman collection) strix -t ./openapi.yaml -t https://api.example.com # Postman collection pulled live by id (+ optional environment) strix -t "postman://?env=" # Targets from a file strix --target-list ./targets.txt # Extra files placed in the sandbox workspace strix --target ./my-project --workspace-file ./wordlist.txt strix --target https://app.com --workspace-file ./openapi.yaml:specs/openapi.yaml ``` ## Exit Codes | Code | Meaning | |------|---------| | 0 | Scan completed successfully (interactive mode always exits `0`; in headless mode, `0` means no vulnerabilities were found, or with `--fail-on`, none at or above the threshold; lower findings are still in the report) | | 1 | A fatal error occurred before or during the scan (e.g. missing environment variables, Docker unavailable, invalid config file, diff-scope resolution failure, or an unhandled error) | | 2 | Vulnerabilities found (headless mode only; with `--fail-on`, at least one finding at or above that severity) | --- ### Usage Instructions (`docs/usage/instructions.mdx`) --- title: "Custom Instructions" description: "Guide Strix with custom testing instructions" --- Use instructions to provide context, credentials, or focus areas for your scan. ## Inline Instructions ```bash strix --target https://app.com --instruction "Focus on authentication vulnerabilities" ``` ## File-Based Instructions For complex instructions, use a file: ```bash strix --target https://app.com --instruction-file ./pentest-instructions.md ``` ## Common Use Cases ### Authenticated Testing ```bash strix --target https://app.com \ --instruction "Login with email: test@example.com, password: TestPass123" ``` ### Focused Scope ```bash strix --target https://api.example.com \ --instruction "Focus on IDOR vulnerabilities in the /api/users endpoints" ``` ### Exclusions ```bash strix --target https://app.com \ --instruction "Do not test /admin or /internal endpoints" ``` ### API Testing ```bash strix --target https://api.example.com \ --instruction "Use API key header: X-API-Key: abc123. Focus on rate limiting bypass." ``` ## Instruction File Example ```markdown instructions.md # Penetration Test Instructions ## Credentials - Admin: admin@example.com / AdminPass123 - User: user@example.com / UserPass123 ## Focus Areas 1. IDOR in user profile endpoints 2. Privilege escalation between roles 3. JWT token manipulation ## Out of Scope - /health endpoints - Third-party integrations ``` Be specific. Good instructions help Strix prioritize the most valuable attack paths. ## Workspace files Instructions become part of the prompt. To give Strix a file to work with, such as a wordlist, an API specification, or notes, use `--workspace-file`. Strix places the file into the sandbox workspace before the scan starts. ```bash strix --target https://app.com --workspace-file ./wordlist.txt ``` The file lands at `/workspace/`. To choose the destination, write `PATH:DEST`. `DEST` is a path inside `/workspace`. ```bash strix --target https://app.com \ --workspace-file ./openapi.yaml:specs/openapi.yaml \ --workspace-file ./notes.md ``` Repeat the option for every file you want to place. Strix lists the files in the agent task, so the agent knows where to read them. Rules that apply to every workspace file: - Strix copies the file into the sandbox. The agent can edit the copy, but the file on your machine does not change. - The destination must stay inside `/workspace`. - The destination must not fall inside a target directory, because target files come from the target itself. Strix skips such a file and logs a warning. - Two files cannot claim the same destination. A workspace file is data for the agent to use. It is not a scan target, and its contents do not change the instructions. Do not place secrets in a workspace file. The sandbox runs untrusted target code, so treat anything you place there as readable by the target. --- ### Usage Scan Modes (`docs/usage/scan-modes.mdx`) --- title: "Scan Modes" description: "Choose the right scan depth for your use case" --- Strix offers three scan modes to balance speed and thoroughness. ## Quick ```bash strix --target ./app --scan-mode quick ``` Fast checks for obvious vulnerabilities. Best for: - CI/CD pipelines - Pull request validation - Rapid smoke tests **Duration**: Minutes ## Standard ```bash strix --target ./app --scan-mode standard ``` Balanced testing for routine security reviews. Best for: - Regular security assessments - Pre-release validation - Development milestones **Duration**: 30 minutes to 1 hour **White-box behavior**: Uses source-aware mapping and static triage to prioritize dynamic exploit validation paths. ## Deep ```bash strix --target ./app --scan-mode deep ``` Thorough penetration testing. Best for: - Comprehensive security audits - Pre-production reviews - Critical application assessments **Duration**: 1-4 hours depending on target complexity **White-box behavior**: Runs broad source-aware triage (`semgrep`, AST structural search, secrets, supply-chain checks) and then systematically validates top candidates dynamically. Deep mode is the default. It explores edge cases, chained vulnerabilities, and complex attack paths. ## Choosing a Mode | Scenario | Recommended Mode | |----------|------------------| | Every PR | Quick | | Weekly scans | Standard | | Before major release | Deep | | Bug bounty hunting | Deep | --- ### Usage Viewer (`docs/usage/viewer.mdx`) --- title: "Local Web Viewer" description: "Browse a run in a local dashboard with strix view" --- Every scan writes its results to disk as it runs. `strix view` serves those files in a local dashboard, for a live run or a finished one. ```bash strix view # the most recent run strix view my-run-name # a specific run under ./strix_runs strix view --host 0.0.0.0 --port 8080 --no-open ``` The UI ships prebuilt with Strix, so there is no extra install and no JavaScript build step. The dashboard reads the run files straight off disk. Nothing leaves your machine, and you do not need a cloud account. ## Options Run name under `./strix_runs`. Defaults to the most recent run. Host to bind to. Use `0.0.0.0` to reach the viewer from other machines. Port to serve on. The default selects an available ephemeral port. Do not open the browser automatically. ## What Is In The Dashboard - **Overview** — run status, target, and a severity breakdown of everything found so far. - **Vulnerabilities** — each validated finding with its severity, details, and reproduction steps. - **Agent graph** — a live map of the multi-agent team, and what each agent is doing. - **Steering** — send instructions to a live scan to redirect the agents during the run. Steering works only in the dashboard the running scan opens. A standalone `strix view` has no live scan to steer. - **History** — browse past runs on this machine and move between them. Verify your email address in the dashboard to unlock the other runs. - **Reports** — generate a shareable report and send it by email. Verify your email address first. ## Sharing The Link The token in the printed URL grants access to the run data, and to the steering of a live scan. Share it only with trusted users. To reach the viewer from another machine, start it with `--host 0.0.0.0` and replace `0.0.0.0` in the printed URL with a reachable IP address or hostname. Restrict the port with your firewall. A request without the token-derived session cannot read run data. --- --- METRICS --- - Files Extracted: 40 - Estimated Token Budget: ~32400 tokens - Canonical Reference: https://codewiki.google/github.com/usestrix/strix