https://yennj12.js.org/yennj12_blog_V4/tags/adversarial/Recent content in Adversarial on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part2-agent-design-zh/Mon, 29 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/cloudflare-security-audit-skill-part2-agent-design-zh/單一 agent 做安全稽核，最大的問題不是「能力不夠」， 而是「confirmation bias」——它既找漏洞，又驗證自己找到的漏洞。 Cloudflare 的解法是：讓找漏洞的 agent 和否定漏洞的 agent 永遠是不同的人。 一、為什麼 Multi-Agent 在安全稽核場景特別有價值 安全稽核和一般的「讓 AI 寫程式」任務有一個關鍵差異： 一般 AI 任務的正確性標準： 輸出可以被執行 → 執行結果符合預期 安全稽核的正確性標準： 找到的漏洞可以被 exploit → exploit 確實成功 沒找到的地方確實沒有漏洞 第二個標準極難用單一 agent 達到，原因有三： 原因 1：Context window 污染 一個 agent 如果既做 Recon 又做 Hunt，它已經建立了對這個系統的「地圖」。這個地圖讓它不容易發現地圖之外的東西——因為它不會主動去懷疑自己的地圖。 原因 2：Confirmation bias 找到「可能的漏洞」之後，同一個 agent 驗證時會下意識地尋找支持的證據，而不是反駁的證據。 原因 3：Context 深度 vs 廣度的矛盾 深入追蹤一條可疑的程式碼路徑，和廣泛掃描整個 codebase，是兩種相互競爭的任務——在同一個 context window 裡很難同時做好。 Multi-agent 架構解決了這三個問題。 二、Hunt Phase 的 Agent 分配策略 按什麼維度分 Agent？ 維度 1：攻擊類別（Attack Class） ┌──────────────────────────────────────────────────────────────┐ │ Agent-Injection → 追蹤所有 untrusted input 到 sink │ │ Agent-AccessCtrl → 越權、IDOR、privilege escalation │ │ Agent-Crypto → 弱隨機數、hardcoded secrets、timing │ │ Agent-BusinessLogic → 狀態機、競爭條件、數值邊界 │ │ Agent-FeatureAbuse → 合法功能被惡用的路徑 │ │ Agent-Chained → 多步驟組合攻擊 │ │ Agent-Wildcard → 探索意外的地方 │ └──────────────────────────────────────────────────────────────┘ 維度 2：子系統（Subsystem） ┌──────────────────────────────────────────────────────────────┐ │ Agent-Auth-Injection → auth 子系統 × injection │ │ Agent-Auth-AccessCtrl → auth 子系統 × 越權 │ │ Agent-Plugin-Injection → plugin 系統 × injection │ │ Agent-Media-Resource → media pipeline × file handling│ └──────────────────────────────────────────────────────────────┘ 兩個維度可以組合。系統的設計原則是：當子系統有明顯的安全邊界時，按子系統切分比只按攻擊類別更有效。