strix Documentation

Technical Documentation: usestrix/strix

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

[!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.

Strix Overview Copy Chapter

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

Use Cases Copy Chapter

• 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 Copy Chapter

Prerequisites:

• Docker (running)
• An LLM API key from any supported provider (OpenAI, Anthropic, Google, etc.)

Installation & First Scan Copy Section

# 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/<run-name>

Updating Copy Section

# 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 Copy Chapter

• Open Source - free, runs locally with Docker and your own LLM key. Quick Start
• Strix Cloud - no setup, validated findings, one-click autofix, and PR reviews. Run a pentest →
• Enterprise - SSO, compliance-ready reports, VPC or self-hosted deployment. Try Strix Enterprise →

☁️ Strix Cloud Copy Chapter

Try the Strix full-stack penetration testing platform at app.strix.ai - 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 →

🏢 Enterprise Copy Chapter

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 →

🤖 Use Strix from Your Coding Agent Copy Chapter

Strix is agent-ready. Give Claude Code, Cursor, Codex, or any SKILL.md-compatible agent the ability to run pentests, fix findings, and set up CI scanning:

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 for the quick reference, docs.strix.ai/llms.txt for the CLI, and docs.app.strix.ai for the API.

✨ Features Copy Chapter

Agentic Pentesting Tools Copy Section

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 Copy Section

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) Copy Section

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 Copy Chapter

Every scan writes its results to disk as it runs. Bring them up in a local dashboard with a single command:

# 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 for the options and for reaching the viewer from another machine.

Usage Examples Copy Chapter

Basic Usage Copy Section

# 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) Copy Section

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:

# OpenAPI / Swagger file, Postman export, or a live collection by id
strix --target ./openapi.yaml --target https://api.your-app.com
strix --target postman://<collection-uuid> --target https://api.your-app.com

Advanced Testing Scenarios Copy Section

# 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 for every option, including scan modes, diff scope, instruction files, and budgets.

Headless Mode Copy Section

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.

strix -n --target https://your-app.com

CI/CD (GitHub Actions) Copy Section

Strix can be added to your pipeline to run a security test on pull requests with a lightweight GitHub Actions workflow:

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 for the details.

Configuration Copy Section

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 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:

strix auth login chatgpt             # sign in with your ChatGPT account
export STRIX_LLM="chatgpt/gpt-5.4"   # chatgpt/<model> 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 from the terminal, without Docker or an LLM key:

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 <uuid> --wait
strix cloud vulns list --severity critical

Every REST API operation has a matching strix cloud <resource> <verb> 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 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:

[
  {
    "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 for the full schema, tool filtering, and stdio servers.

Recommended models for best results:

• Z.ai GLM-5.3 on OpenRouter - openrouter/z-ai/glm-5.3 (the default pick)
• OpenAI GPT-5.4 - openai/gpt-5.4
• Anthropic Claude Sonnet 4.6 - anthropic/claude-sonnet-4-6
• Google Gemini 3 Pro Preview - vertex_ai/gemini-3-pro-preview
• DeepSeek V4 Pro - deepseek/deepseek-v4-pro
• Moonshot Kimi K3 - moonshot/kimi-k3

See the LLM Providers documentation for all supported providers including Vertex AI, Bedrock, Azure, and local models.

Documentation Copy Chapter

Full documentation is available at docs.strix.ai - including detailed guides for usage, CI/CD integrations, skills, and advanced configuration.

Contributing Copy Chapter

We welcome contributions of code, docs, and new skills - check out our Contributing Guide to get started or open a pull request/issue.

Join Our Community Copy Chapter

Have questions? Found a bug? Want to contribute? Join our Discord!

Support the Project Copy Chapter

Love Strix? Give us a ⭐ on GitHub!

Acknowledgements Copy Chapter

Strix builds on the incredible work of open-source projects like LiteLLM, Caido, Nuclei, Playwright, and Bubble Tea. 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`) Copy Section

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 Copy Chapter

For the complete benchmark results, evaluation scripts, and run data, see the usestrix/benchmarks repository.

[!NOTE]
We are actively adding more benchmarks to our evaluation suite.

Results Copy Chapter

XBEN Copy Section

The XBOW benchmark 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.

%%{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:

Resource Usage:

• Average solve time: ~19 minutes
• Total cost: ~$337 for 100 challenges

Overview (`docs/README.md`) Copy Section

Strix Documentation

Documentation source files for Strix, powered by Mintlify.

Local Preview Copy Chapter

npm i mintlify
cd docs && mintlify dev

Overview (`strix/skills/README.md`) Copy Section

📚 Strix Skills

🎯 Overview Copy Chapter

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 Copy Chapter

How Skills Work Copy Section

When an agent is created, it can load up to 5 specialized skills relevant to the specific subtask and context at hand:

# 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 Copy Chapter

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 Copy Chapter

What Should a Skill Contain? Copy Section

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 Copy Chapter

Community contributions are more than welcome — contribute new skills via pull requests or GitHub 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`) Copy Section

Overview Copy Section

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, an open-source analytics platform, for data collection and analysis, along with Scarf. Our telemetry implementation is fully transparent - you can review the source code (posthog.py, scarf.py) to see exactly what we track.

Telemetry Policy Copy Section

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 Copy Section

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 Copy Section

• 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 Copy Section

Telemetry in Strix is entirely optional:

export STRIX_TELEMETRY=0

You can set this environment variable before running Strix to disable all telemetry.

Overview (`strix/tools/agent_browser/README.md`) Copy Section

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
  [email protected] (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`) Copy Section

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`) Copy Section

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 Copy Chapter

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:

exec_command(cmd="python3", tty=true)      # start a PTY-backed process
write_stdin(session_id=<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`) Copy Section

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`) Copy Section

title: "Introduction" Copy Chapter

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.

Use Cases Copy Chapter

• 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 Copy Chapter

• 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 Copy Chapter

Strix agents come equipped with a comprehensive toolkit:

Vulnerability Coverage Copy Chapter

Multi-Agent Architecture Copy Chapter

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 Copy Chapter

# 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 Copy Chapter

Quickstart (`docs/quickstart.mdx`) Copy Section

title: "Quick Start" Copy Chapter

Prerequisites Copy Chapter

• Docker (running)
• An LLM API key from any supported provider (OpenAI, Anthropic, Google, etc.)

Installation Copy Chapter

Configuration Copy Chapter

Set your LLM provider:

export STRIX_LLM="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="your-api-key"

Run Your First Scan Copy Chapter

strix --target ./your-app

Target Types Copy Chapter

Strix accepts multiple target types:

# 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 Copy Chapter

Cloud Overview (`docs/cloud/overview.mdx`) Copy Section

title: "Introduction" Copy Chapter

Skip the setup. Run Strix in the cloud at app.strix.ai.

Features Copy Chapter

What You Get Copy Chapter

• 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 Copy Chapter

1. Sign up at app.strix.ai
2. Connect your repository or enter a target URL
3. Launch your first scan

Scan Local Source Copy Chapter

Send a local working tree to the managed white-box scanner without connecting a source-control provider:

# 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="<reviewed source.archive_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.

Llm Providers Overview (`docs/llm-providers/overview.mdx`) Copy Section

title: "Overview" Copy Chapter

Strix uses LiteLLM for model compatibility, supporting 100+ LLM providers.

Configuration Copy Chapter

Set your model and API key:

export STRIX_LLM="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="your-api-key"

Local Models Copy Chapter

Run models locally with Ollama, LM Studio, or any OpenAI-compatible server:

export STRIX_LLM="ollama/llama4"
export LLM_API_BASE="http://localhost:11434"

See the Local Models guide for setup instructions and recommended models.

Provider Guides Copy Chapter

Model Format Copy Chapter

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`) Copy Section

title: "Agent Tools" Copy Chapter

Strix agents use specialized tools to test your applications like a real penetration tester would.

Core Tools Copy Chapter

Additional Tools Copy Chapter

Contributing (`docs/contributing.mdx`) Copy Section

title: "Contributing" Copy Chapter

Development Setup Copy Chapter

Prerequisites Copy Section

• Python 3.12+
• Latest Go 1.24.x patch (only for Bubble Tea TUI development and release artifacts)
• Docker (running)
• uv
• Git

Local Development Copy Section

# or manually:
uv sync
uv run pre-commit install
```

Contributing Skills Copy Chapter

Skills are specialized knowledge packages that enhance agent capabilities. They live in strix/skills/

Creating a Skill Copy Section

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 Copy Chapter

Pull Request Process Copy Section

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 Copy Section

• PEP 8 with 100-character line limit
• Type hints for all functions
• Docstrings for public methods
• Small, focused functions
• Meaningful variable names

Package Builds Copy Chapter

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.

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 Copy Chapter

Include:

• Python version and OS
• Strix version (strix --version)
• LLM being used
• Full error traceback
• Steps to reproduce

Community Copy Chapter

Docs.Json (`docs/docs.json`) Copy Section

{
"$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`) Copy Section

title: "Configuration" Copy Chapter

Configure Strix using environment variables or a config file.

LLM Configuration Copy Chapter

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 Copy Section

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 Copy Chapter

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://<collection-uid>), and Postman environments (postman://<collection-uid>?env=<environment-uid>) 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:

strix_runs/<run_name>/events.jsonl

When remote vars are set, Strix dual-writes telemetry to both local JSONL and the remote OTEL endpoint.

Docker Configuration Copy Chapter

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 Copy Chapter

Maximum execution time in seconds for sandbox operations.

Timeout in seconds for connecting to the sandbox container.

Config File Copy Chapter

Strix stores configuration in ~/.strix/cli-config.json. You can also specify a custom config file:

strix --target ./app --config /path/to/config.json

Config file format:

{
  "env": {
    "STRIX_LLM": "openrouter/z-ai/glm-5.3",
    "LLM_API_KEY": "sk-...",
    "STRIX_REASONING_EFFORT": "high"
  }
}

Example Setup Copy Chapter

# 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`) Copy Section

title: "Skills" Copy Chapter

Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methodologies.

The Idea Copy Chapter

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 Copy Chapter

When Strix spawns an agent for a specific task, it selects up to 5 relevant skills based on the context:

# 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 Copy Chapter

Vulnerabilities Copy Section

Core vulnerability classes with deep exploitation techniques.

Frameworks Copy Section

Framework-specific testing patterns.

Technologies Copy Section

Third-party service and platform security.

Protocols Copy Section

Protocol-specific testing techniques.

Reconnaissance Copy Section

Passive discovery and attack-surface mapping techniques.

Tooling Copy Section

Sandbox CLI playbooks for core recon and scanning tools.

Skill Structure Copy Chapter

Each skill is a Markdown file with YAML frontmatter for metadata:

---
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 Copy Chapter

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`) Copy Section

title: "Cloud CLI" Copy Chapter

The strix cloud commands drive the managed platform (app.strix.ai) from the terminal. You do not need Docker or an LLM key.

Sign In Copy Chapter

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.

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 Copy Chapter

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.

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 Copy Chapter

Every operation of the REST API has a matching command in the form strix cloud <resource> <verb>.

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 <uuid> --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:

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 Copy Chapter

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 <domain-id>            # 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 Copy Chapter

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 Copy Chapter

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 Copy Chapter

See Scan Local Source for the upload approval flow, the exclusion rules, and the size limits.

Tab Completion Copy Chapter

Enable native tab completion once for each shell session:

source <(strix completions zsh)       # use bash instead of zsh when appropriate
strix completions fish | source

Integrations Ci Cd (`docs/integrations/ci-cd.mdx`) Copy Section

title: "CI/CD Integration" Copy Chapter

Strix runs in headless mode for automated pipelines.

Headless Mode Copy Chapter

Use the -n or --non-interactive flag:

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:

strix -n --target ./app --scan-mode quick --scope-mode diff --diff-base origin/main

Exit Codes Copy Chapter

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.:

strix -n --target ./app --scan-mode quick --fail-on high

GitLab CI Copy Chapter

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 Copy Chapter

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 Copy Chapter

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

Integrations Coding Agents (`docs/integrations/coding-agents.mdx`) Copy Section

title: "Coding Agents" Copy Chapter

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 Copy Chapter

Works with any agent that supports the open SKILL.md standard — Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and dozens more:

npx skills add usestrix/strix

Install a single skill with npx skills add usestrix/strix --skill penetration-testing-with-strix, or use one without installing:

npx skills use usestrix/strix@penetration-testing-with-strix | claude

Two ways to run — self-hosted or managed Copy Chapter

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 <resource> <verb> command) or the app.strix.ai REST API 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 Copy Chapter

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 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/<run-name>/; 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 with a quick reference.
• llms.txt — this documentation is indexed at docs.strix.ai/llms.txt and fully exported at docs.strix.ai/llms-full.txt; every page is also available as Markdown by appending .md to its URL.

Example Prompts Copy Chapter

Once the skills are installed, prompts like these just work:

Pentest this repo with Strix (quick mode, $10 budget) and summarize the findings.

Fix all critical and high findings from the last Strix run, then re-scan to verify.

Add Strix security scanning to our GitHub Actions so every PR gets tested.

Integrations Github Actions (`docs/integrations/github-actions.mdx`) Copy Section

title: "GitHub Actions" Copy Chapter

Integrate Strix into your GitHub workflow to catch vulnerabilities before they reach production.

Basic Workflow Copy Chapter

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 Copy Chapter

Add these secrets to your repository:

Exit Codes Copy Chapter

The workflow fails when vulnerabilities are 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 Copy Chapter

Integrations Mcp (`docs/integrations/mcp.mdx`) Copy Section

title: "MCP Servers" Copy Chapter

Strix can connect to Model Context Protocol (MCP) 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 Copy Chapter

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:

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:

[
  {
    "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 Copy Chapter

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 Copy Chapter

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):

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 Copy Chapter

To read the config from another path instead of ~/.strix/mcp-servers.json, either pass --mcp-config on the command line:

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 Copy Chapter

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 Copy Chapter

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 Copy Chapter

• 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`) Copy Section

title: "Anthropic" Copy Chapter

Setup Copy Chapter

export STRIX_LLM="anthropic/claude-sonnet-4-6"
export LLM_API_KEY="sk-ant-..."

Available Models Copy Chapter

Get API Key Copy Chapter

1. Go to console.anthropic.com
2. Navigate to API Keys
3. Create a new key

Llm Providers Azure (`docs/llm-providers/azure.mdx`) Copy Section

title: "Azure OpenAI" Copy Chapter

Setup Copy Chapter

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 Copy Chapter

Example Copy Chapter

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 Copy Chapter

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`) Copy Section

title: "AWS Bedrock" Copy Chapter

Setup Copy Chapter

export STRIX_LLM="bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0"

No API key required—uses AWS credentials from environment.

Authentication Copy Chapter

Option 1: AWS CLI Profile Copy Section

export AWS_PROFILE="your-profile"
export AWS_REGION="us-east-1"

Option 2: Access Keys Copy Section

export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION="us-east-1"

Option 3: IAM Role (EC2/ECS) Copy Section

Automatically uses instance role credentials.

Available Models Copy Chapter

Prerequisites Copy Chapter

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`) Copy Section

title: "Local Models" Copy Chapter

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 Copy Chapter

export STRIX_LLM="openai/local-model"
export LLM_API_BASE="http://localhost:1234/v1"  # Adjust port as needed

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"}'

export LLM_EXTRA_BODY='{"service_tier":"flex","safety_identifier":"9f86d081884c7d65"}'

<tool_call>{"name": "exec_command", "arguments": {"cmd": "nmap ..."}}</tool_call>
exec_command(cmd="nmap ...", timeout=180)
{"action": "exec_command", "params": {"cmd": "nmap ..."}}

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"

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="sk-..."

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-key"
export LLM_API_BASE="https://your-proxy.com/v1"

export STRIX_LLM="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="sk-or-..."

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"

https://ai-gateway.vercel.sh/v1/models

export STRIX_LLM="vertex_ai/gemini-3-pro-preview"

gcloud auth application-default login

export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"

export VERTEXAI_PROJECT="your-project-id"
export VERTEXAI_LOCATION="global"

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())

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())

Allowlist: ["api.example.com", "*.example.com"]
Denylist: ["*.gif", "*.jpg", "*.png", "*.css", "*.js"]

# Subdomain enumeration
subfinder -d example.com

# Vulnerability scanning
nuclei -u https://example.com

# SQL injection testing
sqlmap -u "https://example.com/page?id=1"

# 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 ./

# Run Python exploits
python3 exploit.py

# Execute shell scripts
./test_auth_bypass.sh

strix (--target <target> | --target-list <path>) [options]

# 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://<collection-uuid>?env=<environment-uuid>"

# 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

strix --target https://app.com --instruction "Focus on authentication vulnerabilities"

strix --target https://app.com --instruction-file ./pentest-instructions.md

strix --target https://app.com \
  --instruction "Login with email: [email protected], password: TestPass123"

strix --target https://api.example.com \
  --instruction "Focus on IDOR vulnerabilities in the /api/users endpoints"

strix --target https://app.com \
  --instruction "Do not test /admin or /internal endpoints"

strix --target https://api.example.com \
  --instruction "Use API key header: X-API-Key: abc123. Focus on rate limiting bypass."

# Penetration Test Instructions

## Credentials
- Admin: [email protected] / AdminPass123
- User: [email protected] / 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

strix --target https://app.com --workspace-file ./wordlist.txt

strix --target https://app.com \
  --workspace-file ./openapi.yaml:specs/openapi.yaml \
  --workspace-file ./notes.md

strix --target ./app --scan-mode quick

strix --target ./app --scan-mode standard

strix --target ./app --scan-mode deep

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