Strix：把 AI Agent 推進滲透測試 runtime

Strix 的重點是把 AI agent 放進一套完整的安全測試 runtime 裡，讓它不只看程式碼，也能操作瀏覽器、攔截 HTTP request、跑 shell、寫 PoC、驗證漏洞，最後產出報告。

官方網站在 strix.ai，文件在 docs.strix.ai。它的定位很清楚：開源 AI penetration testing tool。也就是讓 AI agent 扮演一組自動化 pentester，幫你找出 app 裡的安全問題，並盡量用可重現的方式驗證，而不是只丟一份靜態掃描清單。

Strix 解的是什麼問題

一般安全檢查常見有幾種方式。

第一種是 SAST。它掃 code pattern，速度快，也適合 CI，但常見問題是 false positive 多。它可能告訴你「這裡疑似 SQL injection」，但不一定能證明真的能打。

第二種是 DAST 或弱掃。它從外部打 web app，能看到 runtime 行為，但對程式碼脈絡、商業邏輯、權限流程的理解有限。

第三種是人工 pentest。效果最好，但貴、慢、排程成本高，而且很難每次 PR 都做一輪。

Strix 想切的位置在中間：用 AI agent 把 source code、runtime 行為、安全工具和報告流程串起來。

它不是只讓模型讀 repo，然後產生一份「可能有風險」的建議。它會把 agent 放進 sandbox，給它瀏覽器、proxy、terminal、Python runtime、notes、reporting 等工具，讓它像安全測試人員一樣一步步驗證。

它能做什麼

Strix 的 README 和官方文件反覆強調一件事：validated findings with PoCs。

也就是它不只列出問題，而是希望產出：

• 可重現步驟
• proof-of-concept
• request / response 證據
• 影響範圍
• 修補建議
• 最後報告

它支援幾種測試方式：

# 掃本地 codebase
strix --target ./app-directory

# 掃 GitHub repository
strix --target https://github.com/org/repo

# 掃線上 web app
strix --target https://your-app.com

# repo + live URL 一起給，做灰箱 / 白箱測試
strix -t https://github.com/org/app -t https://your-app.com

這個多 target 設計是它比較值得看的地方。只給 live URL，它偏黑箱測試；只給 repo，它缺 runtime 驗證。repo 和 staging URL 一起給，agent 就能用 code context 找出高風險路徑，再回到真實 app 上驗證。

安裝方式

官方 quick start 很簡單：

curl -sSL https://strix.ai/install | bash

也可以用 pipx：

pipx install strix-agent

基本需求：

• Docker 要跑著
• 需要 LLM API key
• 第一次跑會自動拉 sandbox Docker image
• 掃描結果會存到 strix_runs/<run-name>

設定模型：

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

然後執行：

strix --target ./app-directory

Strix 的工具鏈

Strix 的重點不是包一層 prompt，而是它有自己的 agent runtime。

官方文件裡的核心工具包括：

其中最值得注意的是 Caido proxy。

Strix 不是只讓 agent 開瀏覽器逛網站，而是把瀏覽器流量接進 proxy。這代表 agent 可以看到每個 request / response，然後針對 request 做 replay、改 header、改 body、改 cookie。

這對幾種漏洞特別有用：

• IDOR
• auth bypass
• broken access control
• business logic flaw
• CSRF
• API 權限錯誤
• session / JWT 問題

這也是它跟一般 coding agent 做 security review 最大的差別。Claude Code 或 Codex 可以看 code，但 Strix 給 agent 的是安全測試 runtime。

Scan modes：quick、standard、deep

Strix 有三種掃描深度：

deep 是預設模式。官方文件提到 deep mode 會跑更廣的 source-aware triage，包含 semgrep、AST structural search、secrets、supply-chain checks，再挑高價值候選做動態驗證。

如果只是每個 PR 都跑，quick 比較合理。如果是 release 前或 staging 環境測試，才適合用 standard 或 deep。

CI/CD 怎麼接

Strix 支援 headless mode：

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

GitHub Actions 可以這樣接：

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

Exit code 也適合接 CI：

在 PR 裡跑 quick scan 時，Strix 會嘗試自動 scope 到 changed files。如果 diff resolution 失敗，文件建議 actions/checkout 要設 fetch-depth: 0，或手動給 --diff-base。

支援哪些模型

Strix 透過 LiteLLM 做模型相容，所以支援範圍很廣。官方文件寫支援 100+ LLM providers。

常見格式是：

export STRIX_LLM="provider/model-name"
export LLM_API_KEY="your-api-key"

官方推薦例子包括：

本地模型也能接，例如 Ollama：

export STRIX_LLM="ollama/qwen3-vl"
export LLM_API_BASE="http://localhost:11434"

不過官方對本地模型講得很直接：Strix 很吃 tool use、多步推理和自我修正。多數 70B 以下的 local model，在這種 agentic security testing 場景會比較吃力。

所以如果是正式安全檢查，還是比較適合用 Claude / GPT 這類強模型。本地模型適合 privacy-first、內網、air-gapped 或低敏測試環境。

成本控制：--max-budget-usd

AI pentesting 很容易燒 token，尤其是 deep mode、多 agent、長時間掃描。

Strix 有一個實用參數：

strix --target ./app --max-budget-usd 20

它會限制整個 scan 的 LLM 成本，包含 root agent 和 child agents。

幾個細節要注意：

• 成本達標後會 clean stop。
• 狀態是 stopped，不是 failure。
• 成本檢查發生在 response 回來後，所以最後可能略超過限制。
• 成本估算依賴 provider token usage 和 pricing；不是所有 provider 都能準確回報。

這個設計很重要。安全測試不像一般聊天，agent 會連續查、試、跑工具、整理報告。如果沒有 cost guard，很容易一輪 deep scan 就燒掉一筆。

Repo 架構看起來怎麼設計

從 repo 結構看，Strix 已經不是玩具 demo。

主要模組包括：

strix/core       runner、execution、sessions、inputs
strix/runtime    Docker session manager、Caido bootstrap、runtime backend
strix/tools      browser、proxy、shell、reporting、notes、web_search
strix/skills     內建安全技能
strix/report     報告、SARIF、usage/cost、dedupe
strix/interface  CLI 和 Textual TUI

它內建很多 security skills，例如：

• Django
• FastAPI
• NestJS
• Next.js
• GraphQL
• OAuth
• AWS
• Kubernetes
• nmap
• nuclei
• sqlmap
• ffuf
• httpx
• katana
• subfinder
• semgrep
• IDOR
• SSRF
• SQL injection
• XSS
• RCE
• SSTI
• XXE
• CSRF
• race condition
• prototype pollution
• mass assignment
• business logic

這裡最值得看的是：Strix 把安全知識拆成 skills，而不是全部壓在模型 prompt 裡。

這跟很多 agent 產品的方向一致。模型本身負責推理和決策，但工具、流程、知識庫、報告格式都要產品化。不然 agent 每次都從零開始猜，穩定性會很差。

Strix 適合放在哪些場景

我會把 Strix 放在五種場景。

1. PR 安全守門

用 quick mode 跑 changed files。目標不是完整 pentest，而是抓明顯風險：

• auth logic 改壞
• dangerous route
• secrets
• injection candidate
• 權限檢查漏掉

2. Release 前安全檢查

用 standard 或 deep，搭配 staging URL 和 repo。這比較接近灰箱測試，agent 可以看 code，也能打真實環境。

3. 內部工具 / SaaS 灰箱測試

給 Strix：

• repo
• staging URL
• 測試帳號
• scope 說明
• 不可測項目

讓 agent 用 code context 找高風險流程，再用 browser / proxy 驗證。

4. Bug bounty 初步研究

只限授權範圍。它適合拿來做 recon、request replay、PoC 草稿，但不能把它當成無限制自動攻擊工具。

5. 安全報告產線

Strix 的價值不只在找問題，也在把過程整理成 report。如果它的報告品質穩，對內部 security review 很有幫助。

要注意的邊界

Strix 很有潛力，但不能把它當成「一鍵取代 pentester」。

幾個限制要先講清楚：

• 只能測自己或已授權資產。
• 高風險系統還是需要人工 review。
• business logic、金流、權限設計，仍然要人判斷。
• LLM 成本可能很高。
• 本地模型效果有限。
• Docker / sandbox 是必要條件。
• production target 要非常小心，最好先用 staging。
• instruction-file 要明確寫 scope、帳號、禁止 destructive action。

它比較適合做「第一輪高強度自動驗證」和「CI 裡的安全 agent」，不是完全取代人工安全測試。

跟 Cloudflare security-audit-skill、Claude Code、Codex 的差異

如果把 Strix 放進現在 AI coding / security tool 的光譜，它的位置會比較清楚。

Strix 最突出的不是「模型會看 code」，而是它有完整 runtime。它讓 agent 可以真正操作目標、攔截 request、寫 PoC、保存證據。

我最在意的點：這是 agent 產品化的範本

Strix 值得研究，不只因為它是安全工具。

它示範了一個專業 agent 產品該有的結構：

1. 任務不是單輪問答，而是一條 workflow

• recon
• exploration
• exploitation
• validation
• reporting

1. 模型不是唯一核心，runtime 同樣重要

• browser
• proxy
• terminal
• Python
• notes
• report writer

1. 知識不能只靠 prompt，要拆成 skills

• framework skills
• vulnerability skills
• tooling skills
• scan mode skills

1. 結果要能驗證

• PoC
• reproduction steps
• request evidence
• SARIF / report

這套思路不只適用安全測試。法律 AI、RAG 查證、財報研究、商業情報、自動化資料分析都可以參考同一個架構。

不要把所有事情塞給聊天模型。更好的做法是拆成：

資料取得 → 工具驗證 → 證據整理 → 結論生成 → 報告輸出

Strix 只是把這套架構落在 pentesting 上。

我的判斷

Strix 的價值不在「AI 幫你找漏洞」這句話。真正有價值的是它把安全測試拆成一套可執行系統：

• sandbox
• browser
• proxy
• terminal
• Python runtime
• security tools
• vulnerability skills
• report
• CI mode
• budget guard

如果後續穩定性夠，它會是 DevSecOps 裡很有代表性的 agent-native 工具。

我會把它定位成：

介於弱掃、SAST、coding agent、人工 pentest 之間的 AI 安全驗證層。

它不一定取代安全工程師，但可以讓安全檢查更早進入 PR 和 staging 流程。對一般開發團隊來說，這比一年一次人工 pentest 更有即時價值。

可以怎麼實際試

如果要試，我會先用這個順序。

第一輪：本地 demo app

strix --target ./demo-app --scan-mode quick --max-budget-usd 5

先看：

• 會不會順利跑完
• findings 是否有證據
• false positive 多不多
• 報告格式是否可用

第二輪：staging + repo

strix -t ./repo -t https://staging.example.com \
  --scan-mode standard \
  --instruction-file ./scope.md \
  --max-budget-usd 20

scope.md 裡要寫：

• 測試帳號
• 可測功能
• 禁止 destructive action
• out-of-scope endpoints
• 測試時間與環境限制

第三輪：CI quick scan

等前兩輪確認結果品質，再放進 GitHub Actions。不要一開始就直接塞進 production CI gate，不然可能會被成本、誤報、時間卡住。

結論

Strix 是我最近看到比較完整的 AI security agent 專案。

它不是只做 code review，也不是傳統弱掃器。它真正值得看的地方，是把 agent 放進一套安全測試 runtime：瀏覽器、proxy、shell、Python、skills、報告、CI 都接在一起。

如果只用一句話講：

Strix 把 AI coding agent 往 pentesting runtime 推進了一步。

它目前最適合的使用方式，是放在 staging、PR、release 前檢查，用來做第一輪自動化安全驗證。高風險漏洞和業務邏輯還是要人判斷，但 Strix 可以先幫你把大量探索、重放、PoC 和報告工作接起來。

對我來說，這個專案最值得借鏡的不是安全掃描本身，而是它的 agent 產品架構：專業知識 skills 化、工具 runtime 化、驗證流程證據化、最後報告格式化。

這會是很多專業 AI 工具接下來要走的方向。

參考來源

• Strix GitHub
• 官方網站
• 官方文件
• Quick Start
• CLI Reference
• Scan Modes
• Tools Overview
• LLM Providers
• Cloud Platform