Rewrite OSS docs for ASD-STE100 Simplified Technical English

This commit is contained in:
Alex Schapiro
2026-08-14 17:57:14 +00:00
parent 8ca0c4a9b8
commit c8b83d91db
23 changed files with 128 additions and 131 deletions
+6 -6
View File
@@ -8,7 +8,7 @@ Configure Strix using environment variables or a config file.
## LLM Configuration
<ParamField path="STRIX_LLM" type="string" required>
Model name in LiteLLM format (e.g., `openai/gpt-5.4`, `anthropic/claude-sonnet-4-6`).
Model name in LiteLLM format, such as `openai/gpt-5.4` or `anthropic/claude-sonnet-4-6`.
</ParamField>
<ParamField path="LLM_API_KEY" type="string">
@@ -20,8 +20,8 @@ Configure Strix using environment variables or a config file.
</ParamField>
<ParamField path="LLM_EXTRA_HEADERS" type="string">
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
Extra HTTP headers sent on every LLM request as a JSON object, such as
`{"X-Feature-Key":"value","X-Tenant":"acme"}`. These headers help 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.
@@ -65,8 +65,8 @@ affecting the agents that do the actual testing.
<ParamField path="DEDUPE_LLM_EXTRA_HEADERS" type="string">
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.
request, such as `{"X-Feature-Key":"value"}`. A dedicated dedupe model never
inherits `LLM_EXTRA_HEADERS`. Set this variable when its endpoint needs custom headers.
</ParamField>
<ParamField path="STRIX_DEDUPE_REASONING_EFFORT" type="string">
@@ -81,7 +81,7 @@ affecting the agents that do the actual testing.
</ParamField>
<ParamField path="POSTMAN_API_KEY" type="string">
Postman API key (`PMAK-…`). Enables fetching Postman collections by id as a target (`postman://<collection-uid>`), and Postman environments (`postman://<collection-uid>?env=<environment-uid>`) to resolve collection variables. Not needed when passing a local collection export file.
Postman API key (`PMAK-…`). Enables fetching Postman collections by ID as a target (`postman://<collection-uid>`), and Postman environments (`postman://<collection-uid>?env=<environment-uid>`) to resolve collection variables. Not needed when passing a local collection export file.
</ParamField>
<ParamField path="STRIX_TELEMETRY" default="1" type="string">
+10 -10
View File
@@ -3,13 +3,13 @@ title: "Skills"
description: "Specialized knowledge packages that enhance agent capabilities"
---
Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methodologies.
Skills are structured knowledge packages that give Strix agents specialized knowledge about vulnerability types, technologies, and testing methods.
## The Idea
LLMs have broad but shallow security knowledge. They know _about_ SQL injection, but lack the nuanced techniques that experienced pentesters useparser quirks, bypass methods, validation tricks, and chain attacks.
LLMs have broad but shallow security knowledge. They know _about_ SQL injection but lack the nuanced techniques that experienced pentesters use, such as 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.
Skills inject specialized knowledge into the agent's context. This knowledge helps the agent specialize in the current task.
## How They Work
@@ -25,9 +25,9 @@ create_agent(
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
- **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
@@ -138,7 +138,7 @@ How to confirm findings and avoid false positives.
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
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 and environment-specific behavior
+4 -4
View File
@@ -24,10 +24,10 @@ Skip the setup. Run Strix in the cloud at [app.strix.ai](https://app.strix.ai).
## 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
- **Penetration test reports:** Review validated findings and proofs of concept
- **Shareable dashboards:** Collaborate with your team
- **CI/CD integration:** Block risky changes automatically
- **Continuous monitoring:** Find new vulnerabilities quickly
## Getting Started
+9 -9
View File
@@ -52,20 +52,20 @@ Skills are specialized knowledge packages that enhance agent capabilities. They
1. Choose the right category
2. Create a `.md` file with YAML frontmatter (`name` and `description` fields)
3. Include practical examplesworking payloads, commands, test cases
3. Include practical examples, such as working payloads, commands, and test cases
4. Provide validation methods to confirm findings
5. Submit via PR
5. Submit a pull request
## 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
1. **Create an issue first:** Describe the problem or feature
2. **Fork and branch:** Create a branch from `main`
3. **Make changes:** Follow the existing code style
4. **Write tests:** Add coverage for new features
5. **Run checks:** Run `make check-all`
6. **Submit a pull request:** Link to the issue and provide context
### Code Style
@@ -77,7 +77,7 @@ Skills are specialized knowledge packages that enhance agent capabilities. They
## Package Builds
Editable installs do not require Go; they run the TUI from source (`go run`).
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.
+1 -1
View File
@@ -124,7 +124,7 @@
"appearance": {
"default": "dark"
},
"description": "Open-source AI Hackers to secure your Apps",
"description": "Open-source AI agents for application security",
"background": {
"decoration": "grid"
}
+15 -15
View File
@@ -1,9 +1,9 @@
---
title: "Introduction"
description: "Open-source AI hackers to secure your apps"
description: "Open-source AI agents for application security"
---
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 agents test applications like security professionals. They run code dynamically, find vulnerabilities, and validate each finding with a proof of concept. Strix helps developers and security teams test applications without manual pentesting or static-analysis false positives.
<Frame>
<img src="/images/screenshot.png" alt="Strix Demo" />
@@ -26,21 +26,21 @@ Strix are autonomous AI agents that act like real hackers—they run your code d
## 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
- **Application Security Testing:** Detect and validate critical application vulnerabilities
- **Rapid Penetration Testing:** Complete penetration tests in hours, not weeks
- **Bug Bounty Automation:** Automate research and generate PoCs for faster reports
- **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 toolkit:** Browser automation, HTTP proxy, terminal, and Python runtime
- **Finding validation:** Proofs of concept help reduce false positives
- **Multi-agent orchestration:** Specialized agents collaborate on complex targets
- **Developer-focused CLI:** Use the interactive TUI or headless mode
## Security Tools
Strix agents come equipped with a comprehensive toolkit:
Strix agents include a complete security toolkit:
| Tool | Purpose |
|------|---------|
@@ -65,11 +65,11 @@ Strix agents come equipped with a comprehensive toolkit:
## Multi-Agent Architecture
Strix uses a graph of specialized agents for comprehensive security testing:
Strix uses a graph of specialized agents for complete 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
- **Distributed Workflows:** Specialized agents test different attacks and assets
- **Scalable Testing:** Parallel execution provides broad coverage
- **Dynamic Coordination:** Agents collaborate and share discoveries
## Quick Example
+5 -5
View File
@@ -81,10 +81,10 @@ jobs:
command: strix -n -t ./ --scan-mode quick
```
<Note>
All CI platforms require Docker access. Ensure your runner has Docker available.
</Note>
<Tip>
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.
All CI platforms require Docker access. Ensure your runner has Docker available.
</Tip>
<Note>
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.
</Note>
+13 -13
View File
@@ -7,7 +7,7 @@ Strix is built to be driven by AI coding agents. Install the official agent skil
## 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:
These skills work with agents that support the open [SKILL.md standard](https://agentskills.io), including Claude Code, Cursor, Codex, Gemini CLI, and OpenCode:
```bash
npx skills add usestrix/strix
@@ -15,8 +15,8 @@ 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 |
| `penetration-testing-with-strix` | Run capped headless scans against code, URLs, domains, or IP addresses, then read results |
| `managed-pentesting-with-strix` | Use the managed [app.strix.ai](https://app.strix.ai) platform through REST without local Docker or an LLM key |
| `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) |
@@ -26,23 +26,23 @@ Install a single skill with `npx skills add usestrix/strix --skill penetration-t
npx skills use usestrix/strix@penetration-testing-with-strix | claude
```
## Two ways to run — self-hosted or managed
## Two Ways to Run Strix
Both use the same engine and produce the same validated findings and SARIF, so agents can pick per situation or combine them:
Both options provide machine-readable results. Choose the option that fits your environment.
- **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 via the [app.strix.ai REST API](https://docs.app.strix.ai). No Docker, no LLM key, no local install; adds team dashboards, scheduling, PR reviews, and downloadable PDF/DOCX reports (Enterprise plan). Best in sandboxed/CI environments and for teams. Create an API token under **Settings → API Access**; the `managed-pentesting-with-strix` skill has the full flow.
- **Open-source CLI (self-hosted):** Runs locally in a Docker sandbox with your LLM key. This option is free and local.
- **Managed cloud:** Runs on Strix infrastructure through the [app.strix.ai REST API](https://docs.app.strix.ai). This option needs no Docker, LLM key, or local installation. The Enterprise plan adds dashboards, scheduling, pull request reviews, and PDF or DOCX reports.
## 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).
- **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/<run-name>/`; the cloud exposes the same as JSON plus SARIF export.
- **Budget controls** `--max-budget` and `--max-turns` give agents hard cost/time caps.
- **`AGENTS.md`** — the [repository's agent guide](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.
- **Headless CLI:** `strix -n` runs without the TUI. It exits with `0` for a clean scan, `1` for an error, or `2` for vulnerabilities.
- **REST API:** The managed platform exposes a documented [OpenAPI](https://docs.app.strix.ai/openapi.json) at `https://app.strix.ai/api/v1`.
- **Structured results:** Each run writes reports under `strix_runs/<run-name>/`, including JSON, CSV, SARIF, and Markdown files.
- **Budget controls:** `--max-budget` and `--max-turns` set cost and turn limits.
- **`AGENTS.md`:** The [repository's agent guide](https://github.com/usestrix/strix/blob/main/AGENTS.md) provides a quick reference.
- **`llms.txt`:** The index is available at [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt). The full export is available at [docs.strix.ai/llms-full.txt](https://docs.strix.ai/llms-full.txt).
## Example Prompts
+5 -5
View File
@@ -37,7 +37,7 @@ Add these secrets to your repository:
| Secret | Description |
|--------|-------------|
| `STRIX_LLM` | Model name (e.g., `openai/gpt-5.4`) |
| `STRIX_LLM` | Model name, such as `openai/gpt-5.4` |
| `LLM_API_KEY` | API key for your LLM provider |
## Exit Codes
@@ -46,8 +46,8 @@ The workflow fails when vulnerabilities are found:
| Code | Result |
|------|--------|
| 0 | Pass No vulnerabilities |
| 2 | Fail Vulnerabilities found |
| 0 | Pass. No vulnerabilities found |
| 2 | Fail. Vulnerabilities found |
## Scan Modes for CI
@@ -61,6 +61,6 @@ The workflow fails when vulnerabilities are found:
Use `quick` mode for PRs to keep feedback fast. Schedule `deep` scans nightly.
</Tip>
<Note>
<Tip>
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`.
</Note>
</Tip>
+3 -3
View File
@@ -1,6 +1,6 @@
---
title: "Azure OpenAI"
description: "Configure Strix with OpenAI models via Azure"
description: "Configure Strix with OpenAI models through Azure"
---
## Setup
@@ -19,7 +19,7 @@ export AZURE_API_VERSION="2025-11-01-preview"
| `STRIX_LLM` | `azure/<your-deployment-name>` |
| `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`) |
| `AZURE_API_VERSION` | API version, such as `2025-11-01-preview` |
## Example
@@ -33,5 +33,5 @@ export AZURE_API_VERSION="2025-11-01-preview"
## Prerequisites
1. Create an Azure OpenAI resource
2. Deploy a model (e.g., GPT-5.4)
2. Deploy a model, such as GPT-5.4
3. Get the endpoint URL and API key from the Azure portal
+2 -2
View File
@@ -1,6 +1,6 @@
---
title: "AWS Bedrock"
description: "Configure Strix with models via AWS Bedrock"
description: "Configure Strix with models through AWS Bedrock"
---
## Installation
@@ -17,7 +17,7 @@ pipx install "strix-agent[bedrock]"
export STRIX_LLM="bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0"
```
No API key required—uses AWS credentials from environment.
Strix does not require an API key. Strix uses AWS credentials from the environment.
## Authentication
+16 -18
View File
@@ -5,7 +5,7 @@ description: "Run Strix with self-hosted LLMs for privacy and air-gapped testing
Running Strix with local models allows for completely offline, privacy-first security assessments. Data never leaves your machine, making this ideal for sensitive internal networks or air-gapped environments.
## Privacy vs Performance
## Privacy Versus Performance
| Feature | Local Models | Cloud Models (GPT-5/Claude 4.5) |
|---------|--------------|--------------------------------|
@@ -14,11 +14,11 @@ Running Strix with local models allows for completely offline, privacy-first sec
| **Reasoning** | Lower (struggles with agents) | State-of-the-art |
| **Setup** | Complex (GPU required) | Instant |
<Warning>
**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.
<Note>
Strix requires advanced agent capabilities, including tool use, multi-step planning, and self-correction. Most local models under 70B parameters struggle with these 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.
</Warning>
Critical assessments often require capable cloud models. Local models suit assessments where privacy has priority.
</Note>
## Ollama
@@ -39,9 +39,7 @@ For critical assessments, we strongly recommend using state-of-the-art cloud mod
### Recommended Models
We recommend these models for the best balance of reasoning and tool use:
**Recommended models:**
We recommend these models for a good balance of reasoning and tool use:
- **Qwen3 VL** (`ollama pull qwen3-vl`)
- **DeepSeek V3.1** (`ollama pull deepseek-v3.1`)
- **Devstral 2** (`ollama pull devstral-2`)
@@ -59,7 +57,7 @@ export LLM_API_BASE="http://localhost:1234/v1" # Adjust port as needed
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:
a JSON object. Strix sends these headers on every request:
```bash
export STRIX_LLM="openai/your-model"
@@ -69,12 +67,12 @@ 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
the standard `SSL_CERT_FILE=/path/to/ca-bundle.pem`. Do not 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.
Strix requires a **native** function or tool call during each working turn. If the inference server returns plain assistant text, Strix cannot execute the call. The agent then requests another tool call and stops after its recovery attempts end.
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:
@@ -84,19 +82,19 @@ 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.
Configure the inference server to parse tool tokens into structured `tool_calls`. A configured endpoint returns a structured call or rejects the request. It does not return 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.
- Run with `--jinja` and a tool-use chat template that matches the model. Recent builds enable `--jinja` by default. Upgrade if yours does not.
- For thinking models, align or disable reasoning with `--reasoning-format` or `-rea off`.
- Set a low temperature, such as `--temp 0.2`, to improve 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 16k32k. 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.
- Use a recent Ollama version and a model whose template supports tools. Ollama refuses tools when the template lacks tool support.
- For reasoning models such as qwen3, disable **thinking** mode. Thinking mode can move tool calls into `content` instead of `tool_calls`. Disable it in Ollama with a non-thinking model or `think: false`.
- Raise **`num_ctx`** to at least 16k. Strix sends a large system prompt and many tool schemas. A small context can truncate the tool definitions and stop valid calls.
**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.
+5 -5
View File
@@ -3,7 +3,7 @@ title: "Novita AI"
description: "Configure Strix with Novita AI models"
---
[Novita AI](https://novita.ai) provides fast, cost-efficient inference for open-source models via an OpenAI-compatible API.
[Novita AI](https://novita.ai) provides fast, cost-efficient inference for open-source models through an OpenAI-compatible API.
## Setup
@@ -29,7 +29,7 @@ export LLM_API_BASE="https://api.novita.ai/openai"
## 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
- **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
+5 -5
View File
@@ -1,6 +1,6 @@
---
title: "OpenRouter"
description: "Configure Strix with models via OpenRouter"
description: "Configure Strix with models through OpenRouter"
---
[OpenRouter](https://openrouter.ai) provides access to 100+ models from multiple providers through a single API.
@@ -31,7 +31,7 @@ Access any model on OpenRouter using the format `openrouter/<provider>/<model>`:
## 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
- **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
+3 -3
View File
@@ -44,13 +44,13 @@ See the [Local Models guide](/llm-providers/local) for setup instructions and re
Access 100+ models through a single API.
</Card>
<Card title="Google Vertex AI" href="/llm-providers/vertex">
Gemini 3 models via Google Cloud.
Gemini 3 models through Google Cloud.
</Card>
<Card title="AWS Bedrock" href="/llm-providers/bedrock">
Claude and Titan models via AWS.
Claude and Titan models through AWS.
</Card>
<Card title="Azure OpenAI" href="/llm-providers/azure">
GPT-5.4 via Azure.
GPT-5.4 through Azure.
</Card>
<Card title="Local Models" href="/llm-providers/local">
Llama 4, Mistral, and self-hosted models.
+2 -2
View File
@@ -1,6 +1,6 @@
---
title: "Google Vertex AI"
description: "Configure Strix with Gemini models via Google Cloud"
description: "Configure Strix with Gemini models through Google Cloud"
---
## Installation
@@ -17,7 +17,7 @@ pipx install "strix-agent[vertex]"
export STRIX_LLM="vertex_ai/gemini-3-pro-preview"
```
No API key required—uses Google Cloud Application Default Credentials.
Strix does not require an API key. Strix uses Google Cloud Application Default Credentials.
## Authentication
+2 -2
View File
@@ -6,7 +6,7 @@ description: "Install Strix and run your first security scan"
## Prerequisites
- Docker (running)
- An LLM API key from any [supported provider](/llm-providers/overview) (OpenAI, Anthropic, Google, etc.)
- An LLM API key from a [supported provider](/llm-providers/overview), such as OpenAI, Anthropic, or Google
## Installation
@@ -43,7 +43,7 @@ strix --target ./your-app
```
<Note>
First run pulls the Docker sandbox image automatically. Results are saved to `strix_runs/<run-name>`.
The first run pulls the Docker sandbox image automatically. Strix saves results to `strix_runs/<run-name>`.
</Note>
## Target Types
+1 -1
View File
@@ -3,7 +3,7 @@ title: "Browser"
description: "Playwright-powered Chrome for web application testing"
---
Strix uses a headless Chrome browser via Playwright to interact with web applications exactly like a real user would.
Strix uses a headless Chrome browser through Playwright to interact with web applications.
## How It Works
+1 -1
View File
@@ -28,6 +28,6 @@ Strix agents use specialized tools to test your applications like a real penetra
| -------------- | ---------------------------------------- |
| Python Runtime | Write and execute custom exploit scripts |
| File Editor | Read and modify source code |
| Web Search | Real-time OSINT via Perplexity |
| Web Search | Real-time OSINT through Perplexity |
| Notes | Document findings during the scan |
| Reporting | Generate vulnerability reports with PoCs |
+12 -13
View File
@@ -3,7 +3,7 @@ title: "HTTP Proxy"
description: "Caido-powered proxy for request interception and replay"
---
Strix includes [Caido](https://caido.io), a modern HTTP proxy built for security testing. All browser traffic flows through Caido, giving the agent full control over requests and responses.
Strix includes [Caido](https://caido.io), a modern HTTP proxy for security testing. Strix routes browser traffic through Caido, so the agent can inspect and modify requests and responses.
## Capabilities
@@ -70,10 +70,9 @@ asyncio.run(main())
| `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`.
For one-off requests, use shell tools such as `curl`.
The sandbox routes traffic through Caido with the `HTTP_PROXY` variable.
Caido then adds each request to `list_requests` for replay through `repeat_request`.
### Example: Automated IDOR Testing
@@ -106,24 +105,24 @@ 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.
Strix exposes the Caido proxy to the host machine during automated scans. The TUI displays the Caido URL in the sidebar.
### Accessing Caido
1. Start a scan as usual
2. Look for the **Caido** URL in the sidebar stats panel (e.g. `localhost:52341`)
2. Find the **Caido** URL in the sidebar stats panel, such as `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
- **Inspect traffic:** Browse HTTP/HTTPS requests that the agent makes
- **Replay requests:** Resend captured requests after you modify them
- **Intercept and modify:** Pause requests, edit them, and forward them
- **Explore the sitemap:** Review the attack surface that the agent discovered
- **Manual testing:** Use Caido tools to test reported findings or unexplored areas
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.
Strix supports collaborative testing. The agent performs automated work while you investigate important areas.
## Scope
+1 -1
View File
@@ -3,7 +3,7 @@ title: "Sandbox Tools"
description: "Pre-installed security tools in the Strix container"
---
Strix runs inside a Kali Linux-based Docker container with a comprehensive set of security tools pre-installed. The agent can use any of these tools through the [terminal](/tools/terminal).
Strix runs inside a Kali Linux-based Docker container with a complete set of security tools. The agent can use these tools through the [terminal](/tools/terminal).
## Reconnaissance
+6 -6
View File
@@ -14,14 +14,14 @@ strix (--target <target> | --target-list <path>) [options]
<ParamField path="--target, -t" type="string">
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://<collection-uuid>`). 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.
When the target is an API spec, Strix copies it into the agent workspace and authorizes its declared base URLs. Strix also resolves base URLs from a Postman environment. The agent reads the contract and tests the declared surface. Pair the spec with a deployed base URL, such as `--target ./openapi.yaml --target https://api.example.com`.
<Note>
A local directory is mounted into the sandbox live and **writable**, so the agent edits your real files (`.git` excepted). Commit or stash first.
</Note>
<Note>
Fetching a Postman collection by id requires `POSTMAN_API_KEY`. Add `?env=<environment-uuid>` to also pull a Postman environment, which resolves `{{baseUrl}}` / token variables the collection references (e.g. `postman://<collection-uuid>?env=<environment-uid>`).
Fetching a Postman collection by ID requires `POSTMAN_API_KEY`. Add `?env=<environment-uuid>` to fetch a Postman environment. Use a target such as `postman://<collection-uuid>?env=<environment-uid>`.
</Note>
</ParamField>
@@ -46,7 +46,7 @@ strix (--target <target> | --target-list <path>) [options]
</ParamField>
<ParamField path="--diff-base" type="string">
Target branch or commit to compare against (e.g., `origin/main`). Defaults to the repository's default branch.
Target branch or commit to compare against, such as `origin/main`. Defaults to the repository's default branch.
</ParamField>
<ParamField path="--non-interactive, -n" type="boolean">
@@ -88,7 +88,7 @@ strix (--target <target> | --target-list <path>) [options]
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;
- 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
@@ -148,6 +148,6 @@ strix --target-list ./targets.txt
| 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) |
| 0 | Scan completed successfully. In headless mode, no vulnerabilities were found. |
| 1 | A fatal error occurred before or during the scan, such as missing variables, unavailable Docker, invalid configuration, or an unhandled error. |
| 2 | Vulnerabilities found (headless mode only) |
+1 -1
View File
@@ -3,7 +3,7 @@ title: "Scan Modes"
description: "Choose the right scan depth for your use case"
---
Strix offers three scan modes to balance speed and thoroughness.
Strix offers three scan modes to balance speed and coverage.
## Quick