# 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., `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`.
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.
API key for Exa. Enables real-time web search through the Exa `/search` endpoint. Exa also powers the `web_get_contents` tool, which fetches the full text of a page through the Exa `/contents` endpoint. This is the preferred web search provider.
Web search provider: `auto`, `perplexity`, or `exa`. With `auto`, Strix uses Exa when `EXA_API_KEY` is set, and Perplexity otherwise. Set an explicit provider to pin one when you configure both keys.
Exa search mode: `auto`, `fast`, `instant`, `deep-lite`, `deep`, or `deep-reasoning`. Lower modes return results faster. Higher modes plan across more steps and take more time. This setting applies only to the Exa provider.
Number of Exa results to return, from `1` to `100`. Each result includes a title, a URL, and a short security-focused summary. To read a full page, the agent calls `web_get_contents` with the result URL. This setting applies only to the Exa provider.
Postman API key (`PMAK-…`). Enables fetching Postman collections by id as a target (`postman://`), and Postman environments (`postman://?env=`) to resolve collection variables. Not needed when passing a local collection export file.
Telemetry toggle. Set to `0`, `false`, `no`, or `off` to disable telemetry (PostHog, Scarf, OTEL).
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": "openrouter/z-ai/glm-5.3",
"LLM_API_KEY": "sk-...",
"STRIX_REASONING_EFFORT": "high"
}
}
```
## Example Setup
```bash theme={null}
# 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"
```
# 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` | Firebase Firestore, Storage rules, Auth, and Functions |
### Protocols
Protocol-specific testing techniques.
| Skill | Coverage |
| --------- | ------------------------------------------------ |
| `graphql` | GraphQL introspection, batching, resolver issues |
### Reconnaissance
Passive discovery and attack-surface mapping techniques.
| Skill | Coverage |
| ----------------- | --------------------------------------------------------------- |
| `asset_discovery` | CT, TLS SAN pivoting, passive DNS, and ASN/IP asset enumeration |
### Tooling
Sandbox CLI playbooks for core recon and scanning tools.
| Skill | Coverage |
| ----------- | ------------------------------------------------------- |
| `nmap` | Port/service scan syntax and high-signal scan patterns |
| `nuclei` | Template selection, severity filtering, and rate tuning |
| `httpx` | HTTP probing and fingerprint output patterns |
| `ffuf` | Wordlist fuzzing, matcher/filter strategy, recursion |
| `subfinder` | Passive subdomain enumeration and source control |
| `naabu` | Fast port scanning with explicit rate/verify controls |
| `katana` | Crawl depth/JS/known-files behavior and pitfalls |
| `sqlmap` | SQLi workflow for enumeration and controlled extraction |
## Skill Structure
Each skill is a Markdown file with YAML frontmatter for metadata:
```markdown 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
# Cloud CLI
Source: https://docs.strix.ai/cloud/cli
Drive app.strix.ai from the terminal with strix cloud
The `strix cloud` commands drive the managed platform ([app.strix.ai](https://app.strix.ai)) from the terminal. You do not need Docker or an LLM key.
## Sign In
Sign in once with the browser device flow. The sign-in creates your account and workspace on first use, and it stores a personal API token in `~/.strix/platform-auth.json`.
```bash theme={null}
strix cloud login # browser approval, then workspace and scope profile
strix cloud login --workspace "My Team" # select a workspace by name or ID
strix cloud whoami # local account and workspace status
strix cloud session # verify the remote session and consent ceiling
strix cloud logout # revoke remotely, then remove the local token
```
A browser sign-in creates one reusable credential for each CLI installation. A second sign-in on the same installation replaces the secret instead of adding another key. `strix cloud logout` revokes the server session before it deletes the local token. Use `--local-only` when you cannot reach the server.
## Scopes
The default **Recommended** preset covers normal scan work, local source uploads, workspace switching, and user-approved credit top-ups. It excludes credential creation, so request `tokens:write` when you need it.
```bash theme={null}
strix cloud login --scopes scans:read scans:write uploads:write billing:read
strix cloud login --scope-profile minimal # also accepts recommended or full
strix cloud session scopes # granted scopes and the login ceiling
strix cloud session scopes set minimal # narrow without another browser sign-in
```
A workspace switch keeps the credential and its expiry, preserves the server-side scope preference, and caps access by the target role. A switch can never exceed the login consent ceiling. Each process pins the workspace it started with, so a concurrent switch fails safely instead of sending a stale command to another organization.
## Commands
Every operation of the [REST API](https://docs.app.strix.ai) has a matching command in the form `strix cloud `.
```bash theme={null}
strix cloud # list all resources
strix cloud scans # run the safe default (scans list)
strix cloud scans help # list the verbs of a resource
strix cloud domains add --domain example.com --asset-type web_app
strix cloud scans start --engagement-type live_test --domain-ids --wait
strix cloud vulns list --severity critical
strix cloud credits # credit balance
```
Write commands take request fields as flags. Every write command also accepts one JSON object with `--data`:
```bash theme={null}
strix cloud scans start --data '{"engagement_type":"code_review"}' # literal JSON
strix cloud scans start --data @request.json # read a file
cat request.json | strix cloud scans start --data - # read standard input
```
`--token` and `STRIX_API_TOKEN` are stateless overrides for a single command, and they never replace the stored sign-in. Pair a CLI-session override with `--workspace-id` or `STRIX_WORKSPACE_ID`.
## Workspaces And Account Setup
```bash theme={null}
strix cloud workspaces list # numbered list; workspace is also accepted
strix cloud workspaces create --name "My Team" # needs admin and organizations:write
strix cloud workspaces use 2 # switch by list number, exact name, or ID
strix cloud billing topup --credits 20 --yes # approve an agent payment after HTTP 402
strix cloud billing subscribe --plan strix_cloud # opens the hosted checkout page
strix cloud billing portal # opens the billing portal
strix cloud integrations install github # opens the app installation page
strix cloud domains verify # prints the DNS record to add
```
The last four commands end at a person. Strix creates the link, opens the browser for an interactive terminal, and always prints the URL. The user enters the card, approves the installation, or adds the DNS record. Pass `--no-browser` to print the URL only.
## Output And Exit Codes
The commands work for people and for agents. Terminal output favors names, branches, lifecycle states, and numbered selectors. Redirected output, and `--json`, preserve the complete machine-readable record.
* Human lists keep the selectors that follow-up commands need, and they omit internal organization and user IDs. A selector that is too long for the compact table is repeated losslessly in a copyable block.
* Paginated lists print the next `--page` or `--offset`. Detail views keep useful prose within a safe terminal bound, so use `--json` for the complete record.
* Token lists separate API keys from named CLI device sessions.
* Binary downloads are the exception to JSON output. Redirect the raw bytes on purpose, or use `--output FILE --json` to write the file and receive structured download metadata.
* There are no prompts when stdin is not a terminal.
Exit codes: `0` success, `1` error, `2` invalid usage, `4` authentication or plan limit, `5` payment required.
## Credits And Plan Limits
Non-Enterprise scans consume the deterministic estimate shown for their scope. A source-only code review at the default `ultra` tier currently starts at 60 credits. Enterprise scans are plan-included and do not consume the credit wallet.
Report downloads need Enterprise, schedules need Pro, and billing writes need an admin token. A plan block exits `4`. An insufficient credit wallet exits `5` without the creation of a scan and without a charge.
## Local Source Scans
See [Scan Local Source](/cloud/overview#scan-local-source) for the upload approval flow, the exclusion rules, and the size limits.
## Tab Completion
Enable native tab completion once for each shell session:
```bash theme={null}
source <(strix completions zsh) # use bash instead of zsh when appropriate
strix completions fish | source
```
# 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
## Scan Local Source
Send a local working tree to the managed white-box scanner without connecting a source-control provider:
```bash theme={null}
# Review the exact file manifest and capture source.archive_sha256. Nothing is uploaded.
strix cloud scans start --source . --dry-run --show-files --json
SOURCE_SHA256=""
# Repeat the same source-selection flags and approve that exact snapshot.
strix cloud scans start --source . --approve-sha256 "$SOURCE_SHA256" --wait
```
In a Git repository, Strix includes tracked files and untracked files that are not ignored. Hidden files, `.git`, symlinks, dependencies and build output, secret-like filenames, and nested archives are excluded by default. Use `.strixignore` or repeat `--exclude GLOB` for project-specific exclusions. `--include-hidden`, `--include-sensitive`, and `--include-archives` are explicit opt-ins.
The CLI limits individual files, total expanded bytes, archive bytes, and file count. For an agent or CI handoff, repeat the same `--source`, `--exclude`, and `--include-*` flags with `--approve-sha256`; Strix refuses the upload if the rebuilt archive differs from the reviewed digest. `--yes` is a one-invocation approval for the snapshot built at that moment, not a digest-bound two-step approval.
The temporary local archive is always removed. After a definitive launch rejection, Strix also deletes the staged remote upload. If a network error, server error, or interruption makes the launch outcome ambiguous, it retains the upload and reports its ID; check `strix cloud scans list` before retrying, then delete an unlinked upload with `strix cloud uploads delete UPLOAD_ID`.
Run your first pentest in minutes.
# 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="openrouter/z-ai/glm-5.3"
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="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="your-api-key"
# Scan
strix --target ./your-app
```
## Community
Join the community for help and discussion.
Star the repo and contribute.
Only test applications you own or have explicit permission to test.
# 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.
# Coding Agents
Source: https://docs.strix.ai/integrations/coding-agents
Use Strix from Claude Code, Cursor, Codex, and other AI agents
Strix is built to be driven by AI coding agents. Install the official agent skills and your agent knows how to run pentests, remediate findings, and wire Strix into CI.
## Install the Skills
Works with any agent that supports the open [SKILL.md standard](https://agentskills.io) — Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and dozens more:
```bash theme={null}
npx skills add usestrix/strix
```
| Skill | What your agent learns |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `penetration-testing-with-strix` | Run headless scans against code, URLs, domains, or IPs — self-hosted CLI or managed cloud — with budget caps, and read the results |
| `managed-pentesting-with-strix` | Drive the managed [app.strix.ai](https://app.strix.ai) platform over REST — no local Docker or LLM key needed |
| `fix-security-vulnerabilities-with-strix` | Triage findings, fix root causes, and re-run Strix to verify each fix |
| `ci-security-scanning-with-strix` | Add PR security scanning to GitHub Actions or any CI (self-hosted CLI or managed app) |
| `application-security-testing` | Assess a whole product: choose the right test for each asset, then rank the findings into one remediation plan |
| `web-app-penetration-testing` | Black-box pentest of a live web app or staging site — scope, credentials, and multi-account access-control testing |
| `api-security-testing` | Test a REST/GraphQL API against the OWASP API Security Top 10 — schema-driven enumeration, BOLA/IDOR, authz |
| `owasp-top-10-testing` | Systematic OWASP Top 10 assessment with honest per-category coverage |
| `find-security-vulnerabilities-in-code` | White-box security review of a repo or working tree, with exploits to confirm findings |
Install a single skill with `npx skills add usestrix/strix --skill penetration-testing-with-strix`, or use one without installing:
```bash theme={null}
npx skills use usestrix/strix@penetration-testing-with-strix | claude
```
## Two ways to run — self-hosted or managed
Both use the same engine and produce the same validated findings and SARIF, so agents can pick per situation or combine them:
* **Open-source CLI (self-hosted)** — runs locally in a Docker sandbox with your own LLM key. Free, fully local, air-gap capable. Best for local dev loops and full control.
* **Managed cloud** — runs on Strix's infrastructure. Drive it with the `strix cloud` CLI (every REST operation has a `strix cloud ` command) or the [app.strix.ai REST API](https://docs.app.strix.ai) directly. No Docker, no LLM key; adds team dashboards, scheduling, PR reviews, and downloadable PDF/DOCX reports (Enterprise plan). Best in sandboxed/CI environments and for teams. Sign in with `strix cloud login` (browser device sign-in, account created on first use) or create a token in the dashboard under **Settings → API Access**. The `managed-pentesting-with-strix` skill has the full flow.
## Agent-Friendly Interfaces
Everything an agent needs is machine-readable:
* **Headless CLI** — `strix -n` runs without the TUI and exits with `0` (clean), `1` (error), or `2` (vulnerabilities found).
* **Cloud CLI** — `strix cloud` prints JSON when stdout is not a terminal (or with `--json`), never prompts without a TTY, and exits with `0` (success), `1` (error), `2` (usage), `4` (authentication required), or `5` (payment required). Credit top-ups pay the Stripe machine-payment challenge with an agent wallet (`strix cloud billing topup --credits N --yes`). Account setup also runs from the CLI: `strix cloud workspaces list|create|use`, `strix cloud org members invite`, `strix cloud billing subscribe`, `strix cloud billing portal`, and `strix cloud integrations install github`. The last three print a hosted link the user opens to finish the payment or approve the installation.
* **REST API** — the managed platform exposes a documented [OpenAPI](https://docs.app.strix.ai/openapi.json) at `https://app.strix.ai/api/v1` (scans, vulnerabilities, assets, PR reviews, schedules, webhooks) with bearer tokens and scopes.
* **Structured results** — every run writes `vulnerabilities.json`, `vulnerabilities.csv`, `findings.sarif` (SARIF 2.1.0), and per-finding Markdown under `strix_runs//`; the cloud exposes the same as JSON plus SARIF export.
* **Budget controls** — `--max-budget` and `--max-turns` give agents hard cost/time caps.
* **`AGENTS.md`** — the [repository's agent guide](https://github.com/usestrix/strix/blob/main/AGENTS.md) with a quick reference.
* **`llms.txt`** — this documentation is indexed at [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) and fully exported at [docs.strix.ai/llms-full.txt](https://docs.strix.ai/llms-full.txt); every page is also available as Markdown by appending `.md` to its URL.
## Example Prompts
Once the skills are installed, prompts like these just work:
```text theme={null}
Pentest this repo with Strix (quick mode, $10 budget) and summarize the findings.
```
```text theme={null}
Fix all critical and high findings from the last Strix run, then re-scan to verify.
```
```text theme={null}
Add Strix security scanning to our GitHub Actions so every PR gets tested.
```
# 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., `openrouter/z-ai/glm-5.3`) |
| `LLM_API_KEY` | API key for your LLM provider |
## Exit Codes
The workflow fails when vulnerabilities are found:
| Code | Result |
| ---- | ---------------------------- |
| 0 | Pass — No vulnerabilities |
| 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`.
# MCP Servers
Source: https://docs.strix.ai/integrations/mcp
Connect your own MCP servers and expose their tools to the agent
Strix can connect to [Model Context Protocol (MCP)](https://modelcontextprotocol.io) servers you list and expose their tools to the agent during a run. Use this to let the agent read how your system is actually built instead of inferring it from the outside.
A few things it pays off for:
* **A database server.** The agent can read the schema and access policies and see tables left readable without them, rather than guessing from responses.
* **A hosting or infrastructure server.** Deployments, domains and environment variable names tell it what is really running, so it tests what exists instead of what it discovered by crawling.
* **An issue tracker.** Known and accepted risks stop the agent re-reporting findings you already triaged.
* **A logging server.** Reading logs lets it confirm an exploit attempt actually landed instead of inferring it from a status code.
## Setup
Create the file `~/.strix/mcp-servers.json`. It holds a JSON list of the servers you want the agent to reach. Each entry is either a local `stdio` server that Strix launches as a subprocess, or a remote `http` server.
Create the directory if it does not exist, then write the file:
```bash theme={null}
mkdir -p ~/.strix
```
Paste the servers you want into `~/.strix/mcp-servers.json`. The example below shows one of each transport: a local filesystem server over `stdio` and a remote GitHub server over `http` with a bearer token:
```json theme={null}
[
{
"name": "local_fs",
"transport": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
},
{
"name": "github",
"transport": "http",
"url": "https://api.githubcopilot.com/mcp/",
"auth": { "kind": "bearer", "token": "your-token" },
"allowed_tools": ["list_issues"]
}
]
```
Strix reads this file at the start of each run. There is no default file, so no MCP tools are loaded until you create it. Edit `command`, `args`, `url`, and `token` to match your own servers.
## Fields
A short label for the connection. Each server's tools are namespaced by
`name` (for example `local_fs_read_file`), so two servers can offer the same
tool name without colliding.
`stdio` for a local subprocess server, or `http` for a remote server.
For `stdio` servers: the executable Strix launches (for example `npx`).
For `stdio` servers: the arguments passed to `command`.
For `http` servers: the server endpoint URL.
For `http` servers that need a bearer token:
`{ "kind": "bearer", "token": "your-token" }`.
Restrict which tools the agent can call. Omit it to expose every tool the
server offers, or set it to a list of tool names to allow only those. Strix
does not decide for you which of a server's tools only read and which change
things, so run the server in its own read-only mode if it has one.
Free-text notes for the agent about what this connection is and how you want
it used, for example "Staging analytics database, read-only, prefer aggregate
queries." When set, the notes are given to the agent at the start of the run
as a description of the connection.
## Choosing connections per run
By default every connection in the file is used on each run. To narrow it for a
single run without editing the file, use either flag (both repeatable):
```bash theme={null}
strix --mcp-server github -t ... # use only the named connection(s)
strix --mcp-exclude staging-db -t ... # use everything except the named one(s)
```
`--mcp-server` keeps only the connections you name; `--mcp-exclude` drops the
ones you name. Connection names must be unique in the file; if two entries share
a name, the first is kept and the rest are ignored.
## Pointing at a different file
To read the config from another path instead of `~/.strix/mcp-servers.json`, either pass `--mcp-config ` on the command line:
```bash theme={null}
strix --mcp-config ./mcp-servers.json -t ...
```
or set the `STRIX_MCP_CONFIG` environment variable to that path. The flag takes precedence when both are given.
## Startup confirmation
When servers are configured, Strix prints a one-line summary at scan startup, for example `MCP: connected 1 server (14 tools): local_fs`, so you can confirm your servers connected.
## Seeing the calls
Each call the agent makes to one of your servers is shown with its own icon and
labelled with the connection it went out to, in the terminal and in the run
viewer (`strix view`), so a call that left Strix for a server you connected is
easy to pick out of a transcript. The terminal shows the call and its arguments;
results can be large and arbitrary, so read them in the viewer, which shows a
preview you can expand.
## Behavior
* The config file is optional. Without it, a run simply gets no MCP tools.
* A server that fails to connect is skipped and logged, and the run continues without it.
* A single malformed entry is skipped without blocking the valid ones.
# 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 |
| --------------- | --------------------------------- |
| GLM-5.3 | `openai/zai-org/glm-5.3` |
| Kimi K3 | `openai/moonshotai/kimi-k3` |
| DeepSeek V4 Pro | `openai/deepseek/deepseek-v4-pro` |
| Kimi K2.5 | `openai/moonshotai/kimi-k2.5` |
| GLM-5 | `openai/zai-org/glm-5` |
| MiniMax M2.5 | `openai/minimax/minimax-m2.5` |
## Get API Key
1. Sign up at [novita.ai](https://novita.ai)
2. Navigate to **API Keys** in your dashboard
3. Create a new key and copy it
## Benefits
* **Cost-efficient** — Competitive pricing with per-token billing
* **OpenAI-compatible** — Drop-in replacement using `LLM_API_BASE`
* **Large context** — Models support up to 262k token context windows
* **Function calling** — All listed models support tool/function calling
# 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/z-ai/glm-5.3"
export LLM_API_KEY="sk-or-..."
```
## Available Models
Access any model on OpenRouter using the format `openrouter//`:
| Model | Configuration |
| ----------------- | ---------------------------------------- |
| GLM-5.3 (default) | `openrouter/z-ai/glm-5.3` |
| GPT-5.4 | `openrouter/openai/gpt-5.4` |
| Claude Sonnet 4.6 | `openrouter/anthropic/claude-sonnet-4.6` |
| Gemini 3 Pro | `openrouter/google/gemini-3-pro-preview` |
| DeepSeek V4 Pro | `openrouter/deepseek/deepseek-v4-pro` |
| Kimi K3 | `openrouter/moonshotai/kimi-k3` |
| GLM-4.7 | `openrouter/z-ai/glm-4.7` |
## Get API Key
1. Go to [openrouter.ai](https://openrouter.ai)
2. Sign in and navigate to Keys
3. Create a new API key
## Benefits
* **Single API** — Access models from OpenAI, Anthropic, Google, Meta, and more
* **Fallback routing** — Automatic failover between providers
* **Cost tracking** — Monitor usage across all models
* **Higher rate limits** — OpenRouter handles provider limits for you
# 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 |
| ----------------- | ----------------- | -------------------------------- |
| GLM-5.3 (default) | Z.ai (OpenRouter) | `openrouter/z-ai/glm-5.3` |
| GPT-5.4 | OpenAI | `openai/gpt-5.4` |
| Claude Sonnet 4.6 | Anthropic | `anthropic/claude-sonnet-4-6` |
| Gemini 3 Pro | Google Vertex | `vertex_ai/gemini-3-pro-preview` |
| DeepSeek V4 Pro | DeepSeek | `deepseek/deepseek-v4-pro` |
| Kimi K3 | Moonshot | `moonshot/kimi-k3` |
```bash theme={null}
export STRIX_LLM="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="your-api-key"
```
## Local Models
Run models locally with [Ollama](https://ollama.com), [LM Studio](https://lmstudio.ai), or any OpenAI-compatible server:
```bash 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.
Access models from multiple providers through one endpoint.
Gemini 3 models via Google Cloud.
Claude and Titan models via AWS.
GPT-5.4 via Azure.
Llama 4, Mistral, and self-hosted models.
## Model Format
Use LiteLLM's `provider/model-name` format:
```
openrouter/z-ai/glm-5.3
openai/gpt-5.4
anthropic/claude-sonnet-4-6
vertex_ai/gemini-3-pro-preview
bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0
ollama/llama4
```
# Vercel AI Gateway
Source: https://docs.strix.ai/llm-providers/vercel-ai-gateway
Configure Strix with models via Vercel AI Gateway
[Vercel AI Gateway](https://vercel.com/docs/ai-gateway) provides an OpenAI-compatible API for models from multiple providers.
## Setup
Create an [AI Gateway API key](https://vercel.com/docs/ai-gateway/authentication-and-byok), then configure Strix:
```bash theme={null}
export STRIX_LLM="openai/anthropic/claude-opus-5"
export LLM_API_KEY="your-ai-gateway-api-key"
export LLM_API_BASE="https://ai-gateway.vercel.sh/v1"
```
The first `openai/` segment tells Strix to use its OpenAI-compatible client. The remaining value is the [AI Gateway model ID](https://vercel.com/docs/ai-gateway/models-and-providers).
## Available Models
Use any language model returned by the AI Gateway models endpoint:
```text theme={null}
https://ai-gateway.vercel.sh/v1/models
```
Prefix its model ID with `openai/` when setting `STRIX_LLM`. For example, the Gateway model ID `anthropic/claude-opus-5` becomes `openai/anthropic/claude-opus-5` in Strix.
## Get API Key
1. Open the [AI Gateway API key settings](https://vercel.com/docs/ai-gateway/authentication-and-byok)
2. Create an API key
3. Set the key as `LLM_API_KEY`
## Benefits
* Access models from multiple providers through one endpoint
* Track Gateway usage and cost in Vercel
# 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="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="your-api-key"
```
For best results, use `openrouter/z-ai/glm-5.3` (the default pick), `openai/gpt-5.4`, `anthropic/claude-opus-4-6`, or `openai/gpt-5.2`.
## Run Your First Scan
```bash 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 with Exa or 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.
Path to a file on your machine to place into the sandbox workspace before the
scan starts. Repeat the option for more files. Write `PATH:DEST` to choose the
destination inside `/workspace`. `DEST` defaults to the file name. See
[Workspace files](/usage/instructions#workspace-files).
Scan depth: `quick`, `standard`, or `deep`.
Code scope mode: `auto` (enable PR diff-scope in CI/headless runs), `diff` (force changed-files scope), or `full` (disable diff-scope).
Target branch or commit to compare against (e.g., `origin/main`). Defaults to the repository's default branch.
Run in headless mode without TUI. Ideal for CI/CD.
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
# Extra files placed in the sandbox workspace
strix --target ./my-project --workspace-file ./wordlist.txt
strix --target https://app.com --workspace-file ./openapi.yaml:specs/openapi.yaml
```
## Exit Codes
| Code | Meaning |
| ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | Scan completed successfully (interactive mode always exits `0`; in headless mode, `0` means no vulnerabilities were found) |
| 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.
## Workspace files
Instructions become part of the prompt. To give Strix a file to work with, such
as a wordlist, an API specification, or notes, use `--workspace-file`. Strix
places the file into the sandbox workspace before the scan starts.
```bash theme={null}
strix --target https://app.com --workspace-file ./wordlist.txt
```
The file lands at `/workspace/`. To choose the destination, write
`PATH:DEST`. `DEST` is a path inside `/workspace`.
```bash theme={null}
strix --target https://app.com \
--workspace-file ./openapi.yaml:specs/openapi.yaml \
--workspace-file ./notes.md
```
Repeat the option for every file you want to place. Strix lists the files in the
agent task, so the agent knows where to read them.
Rules that apply to every workspace file:
* The file is read-only inside the sandbox.
* The destination must stay inside `/workspace`.
* The destination must not fall inside a target directory, because target files
come from the target itself. Strix skips such a file and logs a warning.
* Two files cannot claim the same destination.
A workspace file is data for the agent to use. It is not a scan target, and its
contents do not change the instructions.
Do not place secrets in a workspace file. The sandbox runs untrusted target
code, so treat anything you place there as readable by the target.
# 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 |
# Local Web Viewer
Source: https://docs.strix.ai/usage/viewer
Browse a run in a local dashboard with strix view
Every scan writes its results to disk as it runs. `strix view` serves those files in a local dashboard, for a live run or a finished one.
```bash theme={null}
strix view # the most recent run
strix view my-run-name # a specific run under ./strix_runs
strix view --host 0.0.0.0 --port 8080 --no-open
```
The UI ships prebuilt with Strix, so there is no extra install and no JavaScript build step. The dashboard reads the run files straight off disk. Nothing leaves your machine, and you do not need a cloud account.
## Options
Run name under `./strix_runs`. Defaults to the most recent run.
Host to bind to. Use `0.0.0.0` to reach the viewer from other machines.
Port to serve on. The default selects an available ephemeral port.
Do not open the browser automatically.
## What Is In The Dashboard
* **Overview** — run status, target, and a severity breakdown of everything found so far.
* **Vulnerabilities** — each validated finding with its severity, details, and reproduction steps.
* **Agent graph** — a live map of the multi-agent team, and what each agent is doing.
* **Steering** — send instructions to a live scan to redirect the agents during the run. Steering works only in the dashboard the running scan opens. A standalone `strix view` has no live scan to steer.
* **History** — browse past runs on this machine and move between them. Verify your email address in the dashboard to unlock the other runs.
* **Reports** — generate a shareable report and send it by email. Verify your email address first.
## Sharing The Link
The token in the printed URL grants access to the run data, and to the steering of a live scan. Share it only with trusted users.
To reach the viewer from another machine, start it with `--host 0.0.0.0` and replace `0.0.0.0` in the printed URL with a reachable IP address or hostname. Restrict the port with your firewall. A request without the token-derived session cannot read run data.