mirror of
https://github.com/usestrix/strix.git
synced 2026-08-16 01:16:40 +02:00
Compare commits
2
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
056ccd5fed | ||
|
|
79630f9ba0 |
@@ -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 (for example, `openai/gpt-5.4`, `anthropic/claude-sonnet-4-6`).
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="LLM_API_KEY" type="string">
|
||||
@@ -20,7 +20,7 @@ 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.
|
||||
Extra HTTP headers sent on every LLM request, as a JSON object (for example
|
||||
`{"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
|
||||
@@ -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, for example `{"X-Feature-Key":"value"}`. A dedicated dedupe model never
|
||||
inherits `LLM_EXTRA_HEADERS`. Set this when its endpoint needs custom headers.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_DEDUPE_REASONING_EFFORT" type="string">
|
||||
|
||||
@@ -7,7 +7,7 @@ Skills are structured knowledge packages that give Strix agents deep expertise i
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
@@ -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/environment-specific behavior
|
||||
|
||||
@@ -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**: 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
|
||||
|
||||
|
||||
@@ -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 examples—working payloads, commands, test cases
|
||||
3. Include practical examples: working payloads, commands, test cases
|
||||
4. Provide validation methods to confirm findings
|
||||
5. Submit via PR
|
||||
5. Submit through 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
|
||||
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
|
||||
|
||||
@@ -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.
|
||||
|
||||
+12
-12
@@ -3,7 +3,7 @@ title: "Introduction"
|
||||
description: "Open-source AI hackers to secure your apps"
|
||||
---
|
||||
|
||||
Strix are autonomous AI agents that act like real hackers—they run your code dynamically, find vulnerabilities, and validate them with proof-of-concepts. Built for developers and security teams who need fast, accurate security testing without the overhead of manual pentesting or the false positives of static analysis tools.
|
||||
Strix 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.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/screenshot.png" alt="Strix Demo" />
|
||||
@@ -26,17 +26,17 @@ 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 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
|
||||
- **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
|
||||
|
||||
@@ -67,9 +67,9 @@ Strix agents come equipped with a comprehensive toolkit:
|
||||
|
||||
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
|
||||
- **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
|
||||
|
||||
|
||||
@@ -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:
|
||||
Works with any agent that supports the open [SKILL.md standard](https://agentskills.io): Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and dozens more:
|
||||
|
||||
```bash
|
||||
npx skills add usestrix/strix
|
||||
@@ -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 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) |
|
||||
|
||||
@@ -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: 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 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 own LLM key. Free, fully local, air-gap capable. Best for local dev loops and full control.
|
||||
- **Managed cloud**: runs on Strix's infrastructure through 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.
|
||||
|
||||
## 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 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.
|
||||
|
||||
## Example Prompts
|
||||
|
||||
|
||||
@@ -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 (for example, `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 |
|
||||
| 2 | Fail: Vulnerabilities found |
|
||||
|
||||
## Scan Modes for CI
|
||||
|
||||
|
||||
@@ -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 (for example, `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 (for example, GPT-5.4)
|
||||
3. Get the endpoint URL and API key from the Azure portal
|
||||
|
||||
@@ -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.
|
||||
No API key required: uses AWS credentials from environment.
|
||||
|
||||
## Authentication
|
||||
|
||||
|
||||
@@ -59,7 +59,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. They are sent on every request:
|
||||
|
||||
```bash
|
||||
export STRIX_LLM="openai/your-model"
|
||||
@@ -69,12 +69,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`: 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.
|
||||
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:
|
||||
|
||||
@@ -84,19 +84,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.
|
||||
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.
|
||||
- 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 does not.
|
||||
- For thinking models, align or disable reasoning (`--reasoning-format`, `-rea off`) so it does not break tool-call parsing.
|
||||
- A low temperature (for example `--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.
|
||||
- For reasoning models (for example 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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
No API key required: uses Google Cloud Application Default Credentials.
|
||||
|
||||
## Authentication
|
||||
|
||||
|
||||
+1
-1
@@ -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 any [supported provider](/llm-providers/overview) (OpenAI, Anthropic, Google)
|
||||
|
||||
## Installation
|
||||
|
||||
|
||||
@@ -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 exactly like a real user would.
|
||||
|
||||
## How It Works
|
||||
|
||||
|
||||
@@ -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 |
|
||||
|
||||
+10
-10
@@ -70,9 +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
|
||||
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
|
||||
automatically, so it lands in `list_requests` and can be replayed through
|
||||
`repeat_request`.
|
||||
|
||||
### Example: Automated IDOR Testing
|
||||
@@ -106,24 +106,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 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`)
|
||||
2. Look for the **Caido** URL in the sidebar stats panel (for example `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 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 has not 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.
|
||||
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
|
||||
|
||||
|
||||
+7
-7
@@ -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'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 (for example `--target ./openapi.yaml --target https://api.example.com`) so the agent has a reachable host to attack.
|
||||
|
||||
<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 also pull a Postman environment, which resolves `{{baseUrl}}` / token variables the collection references (for example `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 (for example, `origin/main`). Defaults to the repository's default branch.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="--non-interactive, -n" type="boolean">
|
||||
@@ -88,8 +88,8 @@ 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;
|
||||
providers that do not expose priced usage may under-count.
|
||||
- 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
|
||||
@@ -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 (interactive mode always exits `0`, in headless mode, `0` means no vulnerabilities were found) |
|
||||
| 1 | A fatal error occurred before or during the scan (for example missing environment variables, Docker unavailable, invalid config file, diff-scope resolution failure, or an unhandled error) |
|
||||
| 2 | Vulnerabilities found (headless mode only) |
|
||||
|
||||
Reference in New Issue
Block a user