# Configuration
Source: https://docs.strix.ai/advanced/configuration
Environment variables for Strix
Configure Strix using environment variables or a config file.
## LLM Configuration
Model name in LiteLLM format (e.g., `openai/gpt-5.4`, `anthropic/claude-sonnet-4-6`).
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`.
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.
Request timeout in seconds for LLM calls.
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).
### 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.
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.
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).
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 theme={null}
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 socket path. Use for remote Docker hosts or custom configurations.
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 theme={null}
strix --target ./app --config /path/to/config.json
```
**Config file format:**
```json theme={null}
{
"env": {
"STRIX_LLM": "openai/gpt-5.4",
"LLM_API_KEY": "sk-...",
"STRIX_REASONING_EFFORT": "high"
}
}
```
## Example Setup
```bash theme={null}
# Required
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="sk-..."
# Optional: Enable web search
export PERPLEXITY_API_KEY="pplx-..."
# Optional: Custom timeouts
export LLM_TIMEOUT="600"
export STRIX_SANDBOX_EXECUTION_TIMEOUT="300"
```
# Skills
Source: https://docs.strix.ai/advanced/skills
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 theme={null}
# 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_firestore` | Firestore rules, Firebase auth |
### 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 theme={null}
---
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
# Introduction
Source: https://docs.strix.ai/cloud/overview
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
Run your first pentest in minutes.
# Contributing
Source: https://docs.strix.ai/contributing
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 theme={null}
git clone https://github.com/usestrix/strix.git
cd strix
```
```bash theme={null}
make setup-dev
# or manually:
uv sync
uv run pre-commit install
```
```bash theme={null}
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
```
```bash theme={null}
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 theme={null}
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.
# Introduction
Source: https://docs.strix.ai/index
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 theme={null}
# Install
curl -sSL https://strix.ai/install | bash
# Configure
export STRIX_LLM="openai/gpt-5.4"
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.
# CI/CD Integration
Source: https://docs.strix.ai/integrations/ci-cd
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 theme={null}
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 theme={null}
strix -n --target ./app --scan-mode quick --scope-mode diff --diff-base origin/main
```
## Exit Codes
| Code | Meaning |
| ---- | ------------------------ |
| 0 | No vulnerabilities found |
| 1 | Execution error |
| 2 | Vulnerabilities found |
## GitLab CI
```yaml .gitlab-ci.yml theme={null}
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 theme={null}
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 theme={null}
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.
# GitHub Actions
Source: https://docs.strix.ai/integrations/github-actions
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 theme={null}
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., `openai/gpt-5.4`) |
| `LLM_API_KEY` | API key for your LLM provider |
## Exit Codes
The workflow fails when vulnerabilities are found:
| Code | Result |
| ---- | ---------------------------- |
| 0 | Pass — No vulnerabilities |
| 2 | Fail — Vulnerabilities found |
## 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`.
# Anthropic
Source: https://docs.strix.ai/llm-providers/anthropic
Configure Strix with Claude models
## Setup
```bash theme={null}
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
# Azure OpenAI
Source: https://docs.strix.ai/llm-providers/azure
Configure Strix with OpenAI models via Azure
## Setup
```bash theme={null}
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 theme={null}
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
# AWS Bedrock
Source: https://docs.strix.ai/llm-providers/bedrock
Configure Strix with models via AWS Bedrock
## Installation
Bedrock requires the AWS SDK dependency. Install Strix with the bedrock extra:
```bash theme={null}
pipx install "strix-agent[bedrock]"
```
## Setup
```bash theme={null}
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 theme={null}
export AWS_PROFILE="your-profile"
export AWS_REGION="us-east-1"
```
### Option 2: Access Keys
```bash theme={null}
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
# Local Models
Source: https://docs.strix.ai/llm-providers/local
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 theme={null}
ollama pull qwen3-vl
```
3. Configure Strix:
```bash theme={null}
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 theme={null}
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 theme={null}
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"}'
```
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 theme={null}
{"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.
# Novita AI
Source: https://docs.strix.ai/llm-providers/novita
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 theme={null}
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 |
| ------------ | ----------------------------- |
| 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
# OpenAI
Source: https://docs.strix.ai/llm-providers/openai
Configure Strix with OpenAI models
## Setup
```bash theme={null}
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 theme={null}
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-key"
export LLM_API_BASE="https://your-proxy.com/v1"
```
# OpenRouter
Source: https://docs.strix.ai/llm-providers/openrouter
Configure Strix with models via OpenRouter
[OpenRouter](https://openrouter.ai) provides access to 100+ models from multiple providers through a single API.
## Setup
```bash theme={null}
export STRIX_LLM="openrouter/openai/gpt-5.4"
export LLM_API_KEY="sk-or-..."
```
## Available Models
Access any model on OpenRouter using the format `openrouter//`:
| Model | Configuration |
| ----------------- | ---------------------------------------- |
| 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` |
| 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
# Overview
Source: https://docs.strix.ai/llm-providers/overview
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 |
| ----------------- | ------------- | -------------------------------- |
| 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` |
```bash theme={null}
export STRIX_LLM="openai/gpt-5.4"
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 theme={null}
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.
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:
```
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
```
# Google Vertex AI
Source: https://docs.strix.ai/llm-providers/vertex
Configure Strix with Gemini models via Google Cloud
## Installation
Vertex AI requires the Google Cloud dependency. Install Strix with the vertex extra:
```bash theme={null}
pipx install "strix-agent[vertex]"
```
## Setup
```bash theme={null}
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 theme={null}
gcloud auth application-default login
```
### Option 2: Service Account
```bash theme={null}
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 theme={null}
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
# Quick Start
Source: https://docs.strix.ai/quickstart
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 theme={null}
curl -sSL https://strix.ai/install | bash
```
```bash theme={null}
pipx install strix-agent
```
## Configuration
Set your LLM provider:
```bash theme={null}
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
```
For best results, use `openai/gpt-5.4`, `anthropic/claude-opus-4-6`, or `openai/gpt-5.2`.
## Run Your First Scan
```bash theme={null}
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 theme={null}
# 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.
# Browser
Source: https://docs.strix.ai/tools/browser
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
# Agent Tools
Source: https://docs.strix.ai/tools/overview
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 via Perplexity |
| Notes | Document findings during the scan |
| Reporting | Generate vulnerability reports with PoCs |
# HTTP Proxy
Source: https://docs.strix.ai/tools/proxy
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 theme={null}
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 theme={null}
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"]
```
# Sandbox Tools
Source: https://docs.strix.ai/tools/sandbox
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.
# Terminal
Source: https://docs.strix.ai/tools/terminal
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 theme={null}
# 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 theme={null}
# 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 theme={null}
# 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
# CLI Reference
Source: https://docs.strix.ai/usage/cli
Command-line options for Strix
## Basic Usage
```bash theme={null}
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.
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.
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 theme={null}
# 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
# 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
```
## Exit Codes
| Code | Meaning |
| ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | Scan completed successfully (interactive mode always exits `0`; in headless mode, `0` means no vulnerabilities were found) |
| 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) |
# Custom Instructions
Source: https://docs.strix.ai/usage/instructions
Guide Strix with custom testing instructions
Use instructions to provide context, credentials, or focus areas for your scan.
## Inline Instructions
```bash theme={null}
strix --target https://app.com --instruction "Focus on authentication vulnerabilities"
```
## File-Based Instructions
For complex instructions, use a file:
```bash theme={null}
strix --target https://app.com --instruction-file ./pentest-instructions.md
```
## Common Use Cases
### Authenticated Testing
```bash theme={null}
strix --target https://app.com \
--instruction "Login with email: test@example.com, password: TestPass123"
```
### Focused Scope
```bash theme={null}
strix --target https://api.example.com \
--instruction "Focus on IDOR vulnerabilities in the /api/users endpoints"
```
### Exclusions
```bash theme={null}
strix --target https://app.com \
--instruction "Do not test /admin or /internal endpoints"
```
### API Testing
```bash theme={null}
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 theme={null}
# 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.
# Scan Modes
Source: https://docs.strix.ai/usage/scan-modes
Choose the right scan depth for your use case
Strix offers three scan modes to balance speed and thoroughness.
## Quick
```bash theme={null}
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 theme={null}
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 theme={null}
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 |