提示注入偵測與防護欄

自主編碼代理程式會讀取其任務擺在它面前的任何內容：原始檔、網頁、議題留言、建置輸出。這其中每一項都是攻擊者能夠直接與模型對話的管道——而模型在設計上就是會遵循指令。Bromure Agentic Coding 以兩種互補的方式守護這道邊界，兩者都在主機上、於 MITM 代理伺服器內部強制執行，任何在 VM 中執行的東西——包括已完全遭到入侵的代理程式——都無法將它們關閉：

• 提示注入偵測在裝置上以本機模型掃描代理程式的 AI 流量，並在被注入的指令抵達模型之前（或抵達當下）加以標記。
• 防護欄會分類代理程式對你基礎設施的呼叫——Kubernetes、AWS、git 託管平台、資料庫等等——並對寫入與破壞性操作進行封鎖或提示，如此一來即使代理程式成功遭到挾持，也無法悄悄地一路 kubectl delete 穿透正式環境。

本章說明此威脅、各個偵測器、命中時會發生什麼事、防護欄的政策引擎及其同意對話框，以及這一切的實務限制。兩者都以機器為單位設定（在設定編輯器中稱為工作區）。逐欄位的設定參考資料位於提示注入設定與防護欄設定。

附註： 還有第三種主機端保護作用於同樣的 AI 流量，但目的不同：個人資料保護會在請求到達模型供應商之前，把個人資料替換成替身。

攻擊手法：編碼代理程式中的提示注入

提示注入是隱藏在代理程式所讀取內容中的惡意文字，企圖操縱模型：「忽略先前的指令」、「執行此命令且不要提及」、「將 ~/.aws/credentials 的內容傳送到這個 URL」。對聊天機器人而言這是個煩擾；但對於擁有 shell、檔案存取權限與憑證的編碼代理程式而言，這是一種遠端程式碼執行的攻擊原語。攻擊路徑很短：

1. 你將代理程式指向一個並非你撰寫的儲存庫、議題追蹤系統或網頁。
2. 代理程式讀取某個檔案（或擷取某個頁面、或執行某個命令），其輸出內容含有被注入的指令。
3. 代理程式將該內容作為下一個 API 請求的一部分串流回模型——而模型可能會將攻擊者的文字當成指令而非資料來處理。

編碼代理程式還有第二種更隱蔽的變體：規則檔後門。Claude Code、Codex 與 Grok 會自動將指令檔——CLAUDE.md、AGENTS.md、GROK.md 及其巢狀與全域變體——載入系統提示中，視為可信賴的權威。被下毒的規則檔位於一個複製而來的儲存庫中，它根本不需要欺騙模型；它會被直接交付到對話中權限最高的位置。攻擊者慣於用不可見的 Unicode 將這些酬載隱藏起來，避開人工審查者：零寬字元、雙向覆寫，以及在編輯器中不會呈現任何內容卻能正常斷詞的 Unicode 標籤字元。

Bromure 的沙箱已經限制了爆炸半徑——代理程式無法觸及你的 Mac，而且它的憑證都是誘餌（參閱憑證）。提示注入偵測所處理的是沙箱無法處理的部分：代理程式本身在其獲授予的權限範圍內被反過來對付你的可能性。

Bromure 掃描的內容

偵測在主機端的代理伺服器中執行，針對代理程式的對外 AI 流量——即代理程式傳送給 Anthropic、OpenAI 或任何其他模型主機的請求。由於代理伺服器能看到完整的請求，它可以精確地檢查模型即將被告知的內容，無論該請求是由哪個代理程式產生的。掃描涵蓋兩個不同的面向，各由其專屬偵測器負責：

一切都在裝置上進行。分類器是透過 Mac 上的 ONNX Runtime 執行的本機 ONNX 模型；不會有任何內容傳送到任何雲端服務進行掃描，而在非受控安裝上，完全不會有任何偵測資料離開機器（受控安裝可將偵測結果轉發給其組織——參閱當偵測器觸發時中的附註）。

兩個偵測器都是機器設定中安全性底下提示注入窗格裡、以機器為單位的切換開關。兩者預設皆為關閉——每個偵測器在你首次啟用時都需要下載一個相當大的模型。

偵測器

原始碼偵測器（PromptGuard）

在原始碼中偵測提示注入會以本機 PromptGuard 序列分類模型（DeBERTa 家族，ONNX）為代理程式擷取的 tool_result 內容——檔案內容、網頁、議題與 PR 本文、命令輸出——評分。它旨在捕捉經典案例：植入於惡意儲存庫中、等待代理程式讀取的「忽略先前的指令／外洩密鑰」文字。

一次掃描的運作方式：

• 每一輪只掃描攜帶 tool_results 的最新訊息。代理程式在每個請求上都會重送整個對話歷史；重新掃描它只會徒增成本毫無效益，因此已看過的歷史會被略過。
• 每個區段最多掃描 16 KB 的內容，分為至多 8 個各 1,536 字元的視窗。這些視窗中的最大注入機率即為該區段的分數；當分數達到門檻（預設 0.5）時，該區段會被標記。
• 判定結果會依內容區塊快取（512 筆），因此代理程式重新讀取的檔案——或在歷史中重送的相同區段——第二次不會產生任何成本。

模型的運作參數（最大序列長度 512 個 token、注入標籤索引 1、門檻 0.5）可透過在模型資料夾中放置一個選用的 bromure-injection.json 來覆寫——參閱模型下載與儲存。

規則檔偵測器（啟發式掃描器 + ModernBERT）

在 CLAUDE.md 檔案及類似檔案中偵測惡意指令針對的是規則檔後門。它會將指令檔從系統提示中抽取出來——比對 Claude Code 的 Contents of <path> (… instructions …): 包裝結構以及廣為人知的規則檔名稱——並對它們執行兩趟掃描：

1. 確定性啟發式掃描器（不依賴任何相依項——即使在下載任何模型之前也能運作，不過切換開關會一併控制兩趟掃描）。它會標記：
   • 系統提示中任何位置的隱藏 Unicode 訊號：Unicode 標籤字元（U+E0000–E007F）、雙向覆寫，以及零寬或軟連字號字元。全部皆為高嚴重性——指令檔中基本上沒有任何正當理由需要它們。
   • 抽取出的指令檔區段中的元指令模式：「忽略先前的指令」、「不要告訴使用者」、「你現在是……」、「新指令：」——高嚴重性。
   • 能力與外洩關鍵字：憑證檔案路徑（例如 ~/.ssh 或 .aws/credentials）、.env 參照、curl 管道接 shell、base64 加管道的結構、rm -rf、強制推送、傳送至 URL 的模式——中嚴重性，僅記錄為「待審查」發現項目。
2. 經過微調的 ModernBERT ONNX 分類器（claudemd-guard）會對相同的指令檔本文執行語意掃描，捕捉不符合任何固定模式的惡意指令。

發現項目會依內容雜湊在每個工作階段內去重，因此未變更的 CLAUDE.md 只會被記錄一次——而非在工作階段的整個生命週期中每一輪都記錄一次。

附註： 在 Ask 與 Block 強制執行模式中，只有高嚴重性的啟發式發現項目（或模型判定）才會觸發暫停或封鎖。中嚴重性的「待審查」發現項目僅供記錄，即使在受控安裝上也絕不會轉發至 bromure.io。

模型下載與儲存

偵測器模型絕不隨應用程式一併封裝——它們是數百 MB 的下載檔，在你首次啟用切換開關時，會依偵測器分別從 https://dl.bromure.io/llms/<model-dir>/<file> 擷取：

下載流程：

1. 開啟某個偵測器的切換開關。一則確認警示——下載 <detector> 偵測器模型？——會說明大小：「這會從 bromure.io 下載約 <size>，並使用大致等量的磁碟空間。下載完成後偵測器即開始運作。」
2. 按一下下載。一個正在下載模型進度視窗會顯示百分比與一個取消按鈕。
3. 在下載途中取消——或拒絕警示、或下載失敗——都會將切換開關還原。沒有模型的偵測器是靜默的空操作，Bromure 不會假裝並非如此。

有幾道保護措施讓下載更為穩健：

• 可用磁碟空間預檢。 一個註定失敗的下載會事先以嚴重警示遭到拒絕：磁碟空間不足，無法下載提示注入模型。
• 最小大小下限。 每個檔案都有大小下限，因此被截斷的下載，或被存成 model.onnx 的 HTML 錯誤頁面，都會明確地失敗，而不會靜默地停用偵測器。
• 原子且可續傳。 下載對每個檔案而言都是原子操作，重試時會略過已存在且有效的檔案。同一模型的並行下載會被去重。
• 自動復原。 若某台機器已啟用偵測器，但在應用程式啟動時或在設定儲存後其模型遺失，背景下載會自動開始。進度與結果會寫入應用程式日誌。

若要移除某個模型，請刪除其位於 ~/Library/Application Support/BromureAC/Models/ 下的資料夾。放在模型資料夾中的選用 bromure-injection.json 會覆寫該偵測器的 maxLength、injectionLabelIndex 與 threshold。

附註： 窗格說明文字引用的是略小的四捨五入數字（~272 MB 與 ~571 MB）；確認對話框則從實際的位元組總量計算其大小（~298 MB 與 ~603 MB）。請以對話框為準。

當偵測器觸發時：記錄、詢問或封鎖

一個共用的各工作區回應——提示注入窗格上的偵測到注入時單選按鈕群組——同時套用於兩個偵測器。在至少啟用一個偵測器之前，此群組為停用狀態。

詢問對話框

在詢問我該怎麼做模式中，一個標題為 Possible <detector> in "<workspace>" 的嚴重對話框會在可捲動的等寬文字區域中呈現被標記的文字，本文為：「Bromure 標記了代理程式即將傳送給模型的內容（來自 <source>）。請在下方審查——放行，或封鎖此請求？」按鈕為封鎖此請求與放行此請求。

所顯示的只有出問題的那一段，而非整份被掃描的內容：原始碼偵測器只呈現得分最高的那一個掃描視窗，而規則檔偵測器則呈現觸發訊號周圍的區域（附帶少量上下文）。一份被標記的 tool_result 或 CLAUDE.md 可能長達好幾頁；只顯示觸發偵測器的那一段，能把可疑指令直接擺在你眼前，而不是把它埋起來，兩種情況的上限皆為 4 KB。

你的決定會依工作區、來源與內容記住，直到本次應用程式執行結束，因此相同的被標記文字不會在每一輪重新提示——代理程式不斷重送歷史，若沒有這項記憶，單一個被標記的檔案會中斷後續的每一個請求。此記憶僅存於記憶體中；它無法在應用程式重新啟動後留存。

當工作區透過 SSH 或 CLI 以無介面方式驅動時，同樣的問題會在工作區的 tmux 內以文字提示呈現。只有明確的放行此請求才會放行——沒有回答即代表封鎖。參閱遠端存取。

請求被封鎖時代理程式看到的內容

在一律封鎖模式中——或當你以封鎖此請求回答詢問對話框時——代理程式會收到 HTTP 451 Unavailable For Legal Reasons，本文為：

Bromure blocked this request: possible <detector> detected in <source>.

模型永遠不會收到被下毒的內容；代理程式看到的是一個乾淨、可解釋、可回報給你的失敗。已解決的結果（「allowed」或「blocked」）會記錄在安全性時間軸中，並在受控安裝上作為雲端事件轉發。

附註： 在已註冊 bromure.io 的 Mac 上，每次偵測都會作為 prompt_injection.detection 事件轉發，攜帶偵測器、方法、動作、主機、來源、分數、啟發式訊號，以及——不同於安全性時間軸的簡短預覽——整段被標記的片段，上限為 20 KB。這些事件會被機器的私密模式切換開關抑制，且絕不會在非受控安裝上傳送；本機的安全性時間軸無論如何都會記錄它們。參閱追蹤與稽核與企業版。

觀察偵測結果：安全性時間軸

每一次偵測與強制執行結果都會出現在安全性時間軸中——開啟視窗 → 安全性…，再在時間軸分頁的引擎篩選器中選擇提示注入。每一列會顯示偵測器與文字的來源，接著在條件欄顯示被標記文字的前 90 個字元，並在判定欄顯示結果：在記錄但繼續模式下為 log（綠色），做出詢問或封鎖的決定後則為 allowed（綠色）或 blocked（紅色）。封鎖也會顯示在總覽分頁的最近封鎖中。

時間軸會保留事件 90 天，重新啟動後依然存在。它的列只帶有被標記內容的簡短預覽——完整文字只會出現在詢問對話框中（在受控安裝上，也會出現在雲端事件中）。

偵測器本身的日誌行——分數、附嚴重性的規則檔訊號、模型下載進度——會寫入應用程式日誌 ~/Library/Logs/BromureAC/bromure-ac.log。它們看起來像這樣：

[prompt-injection] source FLAG score=0.973 toolUse=… preview="…"
[prompt-injection] rules FLAG source=/path/CLAUDE.md signals=[zero_width(high)]
[prompt-injection] blocked: rogue instructions in /path/CLAUDE.md → api.anthropic.com

第一種形式是原始碼偵測器（含模型的分數與一段簡短預覽）；第二種是規則檔偵測器（含檔案路徑與觸發的啟發式訊號，各自標註其嚴重性）；第三種記錄的是強制執行結果。

代理程式之間透過委派互傳的訊息同樣會被掃描，在原始碼偵測器的模型已安裝時由它負責。每一則這樣的訊息都是時間軸中的一列代理程式委派——藍色「relayed」，或在掃描將其攔下時為紅色「withheld — prompt injection」。

防護欄

提示注入偵測試圖捕捉挾持行為；防護欄則限制被挾持（或只是過度熱衷）的代理程式能做什麼。防護欄有兩層。本節所述的寫入政策構成一個各工作區、由主機強制執行的政策引擎，它會把代理程式對受保護通訊協定發出的每一次 API 呼叫分類為讀取、寫入或破壞性操作，並套用該工作區針對該資源的模式。在其之下的是機器的沙盒原則——要嘛是 Bromure 防火牆，一份針對 VM 所開啟每一條連線的有序 pf 風格規則集（主機、IP/CIDR、通訊協定、連接埠，以及針對 web 流量的個別 HTTP 動詞），要嘛是一份還會在 VM 內部限制代理程式的 NVIDIA OpenShell 政策。兩者都在虛擬交換器與代理伺服器上強制執行；VM 的連接埠 80/443 流量會被透明導入代理伺服器，因此客體內部沒有任何東西能夠退出。請參閱沙盒原則、客體沙盒與核心哨兵與沙盒原則設定。每一項防火牆判定都是安全性時間軸中的一列防火牆。正如此窗格所述：防護欄會從此代理程式所使用的通訊協定中剝除破壞性操作；它在主機端——於代理伺服器內部——強制執行，因此 VM 中行為不當或遭入侵的代理程式無法繞過它，被封鎖的呼叫會回傳一個代理程式看得到的硬性錯誤。

四種模式

此窗格會列出機器已設定的憑證。每一項都有一個使用前詢問切換開關，若其服務有寫入政策，還會有一個寫入政策選擇器；政策以服務為單位，因此同一服務的兩個憑證（例如兩個 GitHub 權杖）會共用它。若沒有設定任何憑證，窗格會顯示沒有需要保護的憑證。選擇器提供四種模式：

新工作區在每個資源上都預設為寫入前提示。在防護欄存在之前建立的工作區——或其 JSON 省略了相關欄位的設定檔——會解碼為關閉。

受防護的資源

防護欄涵蓋編碼代理程式最常使用的基礎設施協定。簡要說明如下（完整的各協定分類規則——HTTP 動詞、AWS 動作名稱前綴、SQL 關鍵字剖析——已列表於防護欄設定）：

• Kubernetes — 來自工作區 kubeconfig 的 API 伺服器。DELETE 屬破壞性；GET/HEAD/OPTIONS 屬讀取；其他動詞屬寫入。被封鎖的呼叫會回傳一個 kubectl 能俐落呈現的 Kubernetes Status 403 JSON。
• AWS — 所有 *.amazonaws.com 主機。動作名稱（來自 X-Amz-Target 標頭或 Action= 表單參數）依前綴分類——Delete*、Terminate*、Remove*、Purge*、Destroy*、Deregister*、Revoke* 屬破壞性；Get*、List*、Describe* 及類似者屬讀取——並對 S3 與 REST 風格請求提供 HTTP 方法後備判斷。被封鎖的呼叫會回傳一個 AccessDeniedException 本文。
• DigitalOcean — api.digitalocean.com 與 *.digitalocean.com，依 HTTP 方法分類。
• Docker 登錄檔 — 在憑證下設定的登錄檔加上 Docker Hub。拉取（pull）屬讀取，推送（push）屬寫入，DELETE 屬破壞性；被封鎖的呼叫會回傳一個登錄檔風格的 DENIED 本文。
• GitHub / GitLab / Bitbucket — REST API 加上透過 HTTPS 的 git。git push（git-receive-pack）算作寫入——在唯讀中被封鎖，在寫入前提示中被提示——而 git fetch（git-upload-pack）永遠是讀取。
• HTTPS 資料庫 — 在憑證下設定的每個端點各一列：MongoDB Atlas Data API（find/aggregate 為讀取，insert/update/replace 為寫入，deleteOne/deleteMany 為破壞性）、ClickHouse（依 SQL 的開頭關鍵字分類），以及 Elasticsearch（_search 與其他查詢端點即使透過 POST 也屬讀取；DELETE 與 _delete_by_query 屬破壞性）。

Kubernetes 與 Docker 防護僅適用於從工作區 kubeconfig 與已設定登錄檔衍生出的主機，而資料庫防護需要在憑證下設定端點的主機——沒有可作用範圍的防護不會篩選任何東西，遇此情況時窗格會在畫面內就地警告你。

寫入前提示：同意仲介

在寫入前提示模式中，讀取會靜默放行，而每一次寫入都會暫停以彈出一個標題為 Allow write on "<scope>" from workspace "<name>"? 的主機對話框。本文會逐字顯示確切的操作——資料庫呼叫的字面 SQL 陳述式，或 REST 呼叫的 METHOD /path——因此你核准的是實際將執行的內容，而非改寫過的說法。有四種選擇：

授權以各工作區與各協定範圍界定：一個 Kubernetes API 主機、整個 AWS、一個 Docker 登錄檔、每個 git 託管平台整體、一個資料庫主機。在某台主機上允許 ClickHouse 寫入不會授予其他任何地方任何權限。並行的相同寫入會併入單一對話框，而非堆疊多個警示。所有決定僅存於記憶體中——工作階段範圍的授權（就像工作階段的其他一切）會在拆除時被清除。

在無介面的 SSH/CLI 驅動工作區上，同樣的四種選擇會作為 tmux 文字提示呈現；沒有回答即代表拒絕。

附註： 防護欄的寫入授權不會列在任何視窗中。憑證核准視窗（視窗 → 憑證核准…）只顯示憑證同意的決定；防護欄授權會依其自身的計時器或在工作階段拆除時過期，目前並沒有可提早撤銷它的 UI。

代理程式看到的內容

被封鎖的呼叫會回傳一個符合協定的 403 風格錯誤本文——一個 Kubernetes Status JSON、一個 AWS AccessDeniedException、一個登錄檔 DENIED 酬載——其訊息以「blocked by Bromure Guardrails」結尾。代理程式得到的是一個乾淨、平常的 API 失敗，它可以回報並常常能繞道而行，而不是一個掛住的連線。提示注入封鎖使用 HTTP 451，供應鏈封鎖使用帶有各自本文前綴的 HTTP 451，因此這三個系統在日誌與代理程式輸出中一眼即可區分。

逃生出口

防護欄窗格底部有三個以機器為單位的切換開關，可在不關閉代理伺服器的情況下，為無法承受攔截的主機與用戶端放寬攔截。全部即時生效：

• 允許逐請求的不安全略過（X-bromure-insecure）——預設開啟。若代理程式對自簽或私有憑證授權中心主機的請求驗證失敗，可以加上標頭 X-bromure-insecure: yes 重試；只有那一個請求會略過上游憑證驗證、不帶任何真實憑證，並記錄在安全性時間軸中。
• 停用透明攔截——預設關閉。停止網路層級的轉向，讓原始通訊端與固定憑證的用戶端直接連上網路。遵守代理伺服器設定的工具以及代理程式自己的 API 呼叫仍會經過代理伺服器（因此保有憑證替換、追蹤、防護欄與提示注入掃描）；無視代理伺服器設定的流量則會避開連外規則。
• 憑證外洩時不要警示——預設關閉。抑制入侵警示與 VM 暫停；外洩仍會被封鎖並記錄。

細節與取捨見憑證與傳輸邊界。

效能與資源使用

• 記錄模式是免費的。 在記錄但繼續下，掃描會在回應已經轉送給代理程式之後執行——偵測對代理程式迴圈增加零延遲。
• 詢問與封鎖模式在轉送前掃描。 分類器必須在請求被轉送之前完成，因此被標記的回合會就地付出推論成本。視窗上限（16 KB、每個區段 8 個視窗、僅最新訊息）與 512 筆的判定快取讓這一切維持在有界範圍內。
• 記憶體。 ONNX Runtime CPU 執行提供者是預設值，在兩個模型都載入的情況下約使用 2 GB 常駐記憶體。CoreML／Neural Engine 提供者可透過環境變數 BROMURE_INJECTION_COREML=1 選擇啟用——它會將常駐記憶體約增加為 5 倍（兩個模型約 9 GB），準確度相同，因此預設為關閉。BROMURE_NO_COREML 即使已設定選擇啟用也會強制停用 CoreML，而 BROMURE_INJECTION_FIXED_SHAPE=1 會將每個分類視窗填補為固定的 512-token 形狀（CoreML 選擇啟用時會自動隱含此設定，以避免每種形狀重新編譯；判定結果不變）。
• 偵錯。 BROMURE_AC_DEBUG=1 會在 stderr 上為分類器與規則掃描器輸出詳細的各區段 ok／score 行以及推論錯誤。
• 防護欄的開銷微不足道。 分類是對已經流經代理伺服器的請求做字串比對；只有同意對話框本身會引入暫停，而那個暫停正是重點所在。

偵測無法捕捉的內容

提示注入偵測是一道強力的過濾，而非保證。請了解它的邊界：

• 沒有模型就沒有偵測。 偵測器在其模型安裝之前是靜默的空操作。若切換開關開啟但下載失敗（磁碟已滿、網路中斷），機器會在無保護的狀態下執行——失敗會寫入應用程式日誌，磁碟已滿的情況會彈出強制回應警示，但在此期間沒有任何東西會封鎖代理程式。
• 分類器有門檻。 一個足夠新穎或隱晦的注入可能會低於 0.5 分而通過。反過來，與安全性相關的正當文字（例如一篇關於提示注入的 README）可能會高於門檻——這正是為何記錄但繼續是預設值，以及為何詢問存在。
• 中嚴重性啟發式從不強制執行。 規則檔中的能力關鍵字（rm -rf、憑證路徑、curl 管道接 shell）會被記錄以供審查，但不會自行暫停或封鎖——它們在正當的開發者文件中太過常見。
• 只有 AI 流量會被掃描。 偵測器監看代理程式傳送給模型的內容。模型已經內化的指令會透過一般的工具呼叫執行；那是防護欄那一層的範疇，加上憑證中所述的憑證誘餌與入侵偵測。
• 防護欄有傳輸層盲點。 git 強制推送在傳輸線上與一般推送無從區分，因此封鎖破壞性操作不會阻止它——只有唯讀與寫入前提示會對推送加以把關（透過託管平台 REST API 進行的明確刪除仍會被捕捉）。對於 ClickHouse，沒有可見 SQL 文字的請求在唯讀下會被封鎖（Bromure 無法證明它是讀取），但在封鎖破壞性操作下會通過（它以放行為預設）。

縱深防禦是預期的姿態：偵測、防護欄、誘餌憑證、供應鏈檢查與可拋棄的 VM，各自涵蓋彼此的缺口。

設定各窗格

這兩套系統都以機器為單位設定，位於機器設定中的安全性底下：

完整的逐欄位參考資料為提示注入設定、防護欄設定與沙盒原則設定。每一項偵測與強制執行結果事後皆可稽核——參閱追蹤與稽核。