CrabTrap：一個用於保護生產環境 Agent 的 LLM-as-a-judge HTTP Proxy
CrabTrap：一個用於保護生產環境 Agent 的 LLM-as-a-judge HTTP Proxy
使用 LLM 來判斷 AI Agent 的網路流量
在 Brex，我們的 AI Agent 會在生產環境中執行實際任務。在將 OpenClaw 這類 harness 部署到生產環境的過程中，Brex 面臨著與業界其他公司相同的困境：Agent 需要真實的憑證（API 金鑰、OAuth token 和服務帳號），但它們可能會產生破壞性動作的幻覺，或是遭到 prompt injection（提示詞注入）攻擊。一旦這些請求離開了處理程序，就會直接觸發具有生產環境影響的 API 呼叫。
最顯而易見的解決方案是防護機制（guardrails）。早期的許多工作都集中在範圍受限的工具、針對特定動作的權限控制，以及人機協作（human-in-the-loop）的審核流程。挑戰在於，隨著 Agent 的能力越來越強，每一項新功能都意味著需要額外手動調整 API token 或增加需要審核的介面。現有的防護機制往往走向兩個極端：要麼限制過多導致 Agent 無法完成工作，要麼過於客製化而難以擴展。
因此，我們打造了 CrabTrap：一個開源的 HTTP/HTTPS proxy，它會攔截 AI Agent 發出的每一個請求，並使用 LLM-as-a-judge 來判斷該請求是否符合該 Agent 的流量許可政策。目前的結果相當令人期待；我們相信這是提升生產環境中 Agent harness 安全性的一大進步。
為什麼現有的方法不足夠
現有的方法只能解決部分問題。MCP gateway 在協定層強制執行政策，但僅限於使用 MCP 的流量。來自 LLM 提供商的防護機制則綁定在單一模型上，且無法透明地使用你自己的政策進行自訂。像 NVIDIA OpenShell 這樣的解決方案雖然強大，但更偏向於針對每個沙盒（Sandbox）的出口控制。我們需要的是一個能介於每個 Agent 與每個網路請求之間，並能針對允許哪些行為做出細緻判斷的解決方案。
最終的結果是，儘管 OpenClaw 是 GitHub 上成長最快的專案，但企業部署成功的案例卻寥寥無幾。Brex 決定改變這種現狀。
運作原理
為了保護我們的 Agent，我們做出的核心架構決策是在傳輸層進行操作。透過這種方式，proxy 對於所涉及的框架、程式語言和 API 都是無感的（agnostic）。
你只需在 Agent 的環境中設定 HTTP_PROXY 和 HTTPS_PROXY，每個對外請求在到達目的地之前都會先經過 CrabTrap。不需要 SDK、不需要封裝器（wrappers），也不需要針對每個工具進行整合。對於 HTTPS，CrabTrap 會執行 TLS 攔截：為每個主機產生一個由其自身 CA 簽署的憑證，與客戶端協商 TLS，然後向上游開啟一個獨立的 TLS 連線。部署人員還可以在 Agent 的容器中加入 iptables 規則，封鎖非導向至 proxy 的直接對外連線，作為額外的強制執行層。
在底層，Agent 發出的每個請求都會經過兩個階段的評估：
首先是靜態規則：針對 URL 進行確定性的模式比對（例如前綴、精確匹配或 glob），並可選擇性地限制在特定的 HTTP 方法。拒絕規則（Deny rules）永遠具有最高優先權。靜態規則會編譯為快取的正規表示式（regexps），並在微秒內執行。
但單純的靜態規則無法處理長尾需求。如果沒有匹配到任何靜態規則，請求就會交給 LLM-as-a-judge。判斷器會收到完整的請求上下文，以及分配給該 Agent 的自然語言政策，並回傳一個結構化的 JSON 決策（ALLOW 或 DENY）以及理由。
這種方法既能確保已知模式的處理速度，又能為其他所有情況提供判斷能力。
使用 LLM 從網路流量產生政策
這引出了一個自然的問題：你該如何為 Agent 定義有效的自然語言政策？正如我們從費用報銷政策中學到的，撰寫好的政策很困難。聽起來合理的內容，往往會阻擋了不該阻擋的動作。那麼，你該如何預測 Agent 的實際政策應該是什麼樣子呢？
我們建立了兩個系統來縮小這個差距。
首先是政策產生器（policy builder），它本身就是由一個 Agent 循環所驅動。與其先撰寫政策規則並祈禱它們符合現實，我們的理念是觀察現實並從中推斷出適當的政策。政策產生器會分析 Agent 的歷史流量，抽樣具代表性的網路呼叫，並草擬出一份符合 Agent 真實行為的政策。
第二個是評估系統（eval system），用於在政策變更上線前進行測試。CrabTrap 可以將歷史審核記錄重新執行（replay）在草擬的政策上，並報告任何政策更新會帶來的變更。結果可以按方法、URL、原始決策和同意狀態進行切分。評估過程會並發執行判斷器呼叫，因此重新執行數千個請求只需幾分鐘即可完成。所有過去的請求都會記錄在 PostgreSQL 中，並可透過管理 API 和網頁儀表板進行索引與查詢。
判斷器實際看到的內容
建構 LLM 判斷器意味著要解決一個特定的 prompt engineering 問題：在不讓請求本身成為攻擊向量的前提下，提供模型足夠的 HTTP 請求上下文來做出安全決策。
CrabTrap 會將完整請求以結構化 JSON 物件（方法、URL、標頭、主體）的形式傳送給判斷器，因此所有使用者可控的內容都會經過跳脫處理（escaped），而不是作為原始文字插入。這可以防止透過精心設計的 URL、標頭或主體內容進行 prompt injection。與安全性相關的標頭會被優先處理，且標頭總內容限制在 4KB 以內，防止透過在標頭中填充垃圾資訊來擠壓上下文視窗（context window）中的政策內容，進而發動 prompt inflation（提示詞膨脹）攻擊。請求主體會被截斷至 16KB，並向模型發出明確警告。多部分（Multipart）請求會被替換為每個部分的結構化摘要，而不是直接傳送原始資料。
在生產環境執行 CrabTrap 的心得
Brex 在我們的企業環境中執行 CrabTrap 與 OpenClaw Agent，處理實際任務。到目前為止，有幾點心得特別突出：
從流量中推導出的政策非常強大。我們原先預期政策產生器只能產生一個粗略的起點，需要大量手動編輯（請觀看示範影片）。但在實務上，將其指向幾天的真實流量後，產生的政策在絕大多數被保留的請求中，都與人類的判斷相符。從觀察到的行為開始並進行刪減，遠比從空白頁開始要有效得多。
延遲是每個人問的第一個問題，但結果證明這根本不是問題。對於在 Agent 和每個 API 之間放置一個 proxy，最顯而易見的擔憂是每個請求都會增加延遲。但在實務上，Agent 很快就會進入可預測的流量模式，一旦觀察到這些模式，高頻率的流量就會變成靜態規則。LLM 判斷器只會在遇到不熟悉的端點或異常請求形狀的長尾情況時才會啟動。在一個生產環境的案例中，我們發現 LLM 在不到 3% 的請求中被啟用。
Proxy 不僅僅是強制執行工具，更成為了發現工具。在生產環境的 Agent 上部署 CrabTrap，揭示了 Agent 產生了多少雜訊。審核軌跡（audit trail）讓這一切首次變得可見。我們開始使用拒絕日誌和流量分析，不僅是為了調整政策，還回過頭來優化 Agent 本身，透過移除工具並切斷整類浪費時間與 token 的請求。
為什麼要開源
CrabTrap 目前仍處於實驗階段。它現在對我們來說運作良好，但這個領域還很年輕，攻擊面也在不斷演變，我們認為沒有任何單一方法能成為 Agent 安全性的最終定論。我們將 CrabTrap 開源的原因有三：
首先，CrabTrap 是有用的基礎設施。當我們剛開始時，我們找不到任何解決方案來安全地部署像 OpenClaw 這樣的 harness。與其等待業界跟上，我們決定主動承擔問題並發明必要的工具。
其次，CrabTrap 會隨著使用者的增加而變得更好。我們的 Agent 與特定的 API 集合進行對話。各個團隊在不同的 Agent、服務和政策需求前使用並部署 CrabTrap，將會浮現出我們單獨無法遇到的邊緣案例（edge cases）和模式。
第三，我們對它的未來發展有宏大的計畫，我們寧願與你一起在開放環境中進行建構。改進方向包括更深入的身份驗證功能（如 SSO、細粒度 RBAC）、允許 Agent 請求額外權限的升級工作流程，以及根據拒絕模式提供政策建議。
試用看看
若要部署 CrabTrap 或查看儲存庫，請參考快速入門指南。若要觀看 CrabTrap 的互動式示範，請造訪我們的登陸頁面。
加入我們一起建構
在 Brex，我們建構 AI Agent 運行的基礎設施，因為其中大部分尚未存在。如果你想參與解決那些還沒人解決過的難題，歡迎加入我們：brex.com/careers。