供應鏈防護

自主編碼代理程式會不斷安裝套件——搭建一個專案就會拉進數百個相依套件，過程中沒有任何人讀過套件名稱，更別說變更紀錄了。這使得套件登錄表成為敵意程式碼進入沙盒的最寬廣單一通道：一個仿冒拼寫的名稱、一個剛被劫持的發行版本，或一段惡意的 postinstall 指令碼，都會在 npm install 完成的那一刻，以代理程式的完整權限執行。Bromure Agentic Coding 將每一次套件抓取都視為不受信任的輸入，並在主機端對其套用各工作區專屬的政策，讓任何一個位元組都無法進入 VM 之前先攔下。

本章說明哪些內容會被攔截、管線中的每一項檢查、當某項檢查觸發時會發生什麼事，以及如何在安全記錄中判讀結果。此窗格逐欄的設定參考位於供應鏈設定。

為什麼套件安裝是攻擊面

沙盒本身已經把代理程式關住了：它無法碰觸你的 Mac，而且它的憑證都是誘餌（見憑證）。沙盒本身無法做到的，是判斷代理程式拉進來的程式碼的來源出處。供應鏈攻擊正是利用這個缺口：

• 新發行版本劫持。 維護者的帳號被入侵，並發布了一個惡意版本。這類版本通常會在數小時到數天內被偵測並撤下——這正是為什麼時效閘門會拒絕比某個截止時間更年輕的版本。
• 已知有漏洞的版本。 代理程式將某個相依套件解析到一個有已發布公告的版本。OSV 檢查會攔下這些。
• 惡意程式、仿冒拼寫與流氓安裝指令碼。 一開始就被構建成惡意的套件。socket.dev 與 Delpi 供應商會標記或過濾這些，而安裝指令碼剝除則直接移除了最常見的執行途徑。

強制執行的設計就是在主機端進行。代理伺服器會在代理程式看到回應之前先對其套用政策，因此在 VM 內執行的任何東西——包括一個完全被入侵的代理程式——都無法放寬規則。VM 內的 .npmrc 與 pip.conf 只能進一步限縮代理伺服器已經提供的內容，永遠無法放寬。信譽服務的 API 金鑰（socket.dev、Delpi）僅保存在主機端，永遠不會匯出到 VM 中。

攔截如何運作

VM 發出的每一個網路請求都會經過主機端的 MITM 代理伺服器（見概念）。代理伺服器會辨識送往主要套件登錄表的請求，並將每一個請求分類：

• 中繼資料——一個套件的版本清單（npm packument、PyPI 的 JSON API 或 /simple/ 索引、Cargo 稀疏索引項目等等）。時效閘門在此運作，透過改寫清單來實現。
• 成品——某個特定版本的可下載檔案：npm 的 .tgz、Python 的 wheel 或 sdist、.crate、.gem、.nupkg，或 Go 模組的 .zip。OSV 查詢、socket.dev 檢查、指令碼剝除與硬性阻擋，全都在抓取成品時發生。
• 直接放行——這些主機上的其他一切（搜尋、驗證）。原封不動。

只要工作區至少啟用了一個供應鏈層（或該工作區已向 bromure.io 註冊，在這種情況下即使關閉所有強制執行層，抓取仍會被觀察以供遙測），攔截就會自動生效。在 VM 內沒有任何需要安裝或設定的東西。

附註： 已存在於 npm 或 pip 本機快取中的套件永遠不會觸及網路，因此不會對它們進行任何檢查——也不會記錄。安裝過程中安全記錄一片安靜，可能只是表示一切都來自快取。

判決結果：允許、改寫、阻擋、保留

供應鏈各層是個別的開關切換，每一個都有固定的動作——此窗格沒有全域的阻擋／警告／允許模式。（你可能在提示注入中認識的三向記錄／詢問／阻擋單選鈕，以及防護欄中的強制執行模式，都是各自獨立的系統。）每一次抓取最終都會落入以下四種結果之一：

451 阻擋會攜帶一個純文字內文，開頭為 Bromure Supply-Chain Security blocked this request:，後接確切原因，例如：

Bromure Supply-Chain Security blocked this request: npm package [email protected]
published 4 hours ago — policy requires 2 days minimum

npm、pip、cargo 與其他套件管理員會在其錯誤輸出中一字不差地印出該內文，因此代理程式與你都能精確看到安裝失敗的原因——而且代理程式通常可以自行繞過它（例如，釘選一個較舊的版本）。之所以刻意選用 451 狀態，是為了讓供應鏈阻擋能一眼與防護欄使用的 403 區分開來。

各生態系的涵蓋範圍

代理伺服器攔截八個套件生態系。並非每一項檢查都支援每一個生態系：

有兩個值得知道的缺口：

• 時效閘門——Maven、NuGet、Go。 這三個生態系在其標準中繼資料回應中不攜帶各版本的發布時間戳記，因此其中繼資料會不經過濾地通過，而成品後援也沒有資料可依據來動作。時效閘門今天實際上不會阻擋它們；npm、PyPI、Cargo、RubyGems 與 Packagist 則完全涵蓋。
• socket.dev——Cargo。 socket.dev 不支援 Cargo。啟用 socket.dev 過濾後，每一個 crates.io 成品都得不到判決，因此會觸發未經驗證套件的同意提示（見離線與降級行為）。如果你的工作區有大量 Rust 工作，可以選擇回應這些提示，或改用其他供應商。

時效閘門

時效閘門會拒絕比可設定天數更年輕的套件版本，其理論基礎是：一個剛發布的發行版本最有可能是剛被劫持的套件——惡意版本通常會被快速回報並撤下，而等過那段時間對一般開發而言幾乎不花成本。它是唯一預設啟用的層，最小時效為 2 天。

它透過兩個相互配合的機制運作：

• 中繼資料改寫。 代理伺服器會從登錄表的版本清單中剝除過於新鮮的版本，並將 latest 與其他 dist-tag 重新指向最新的存活版本。浮動參照——pkg@latest、semver 範圍——因此永遠不會被硬性阻擋：套件管理員會靜默地解析到足夠老、足以通過的最新版本。從代理程式的角度來看，比截止時間更年輕的版本根本尚不存在。
• 抓取成品的後援。 代理伺服器在中繼資料中看到的每一個各版本發布時間都會被快取在記憶體中（最多 50,000 個項目）。如果代理程式接著直接請求一個釘選的、過於新鮮的版本，該抓取會被 451 阻擋，並說明套件的實際時效與所需的最小值。對於 pip——其預設的 PEP 503 HTML 索引不攜帶時間戳記——Bromure 會即時查詢 https://pypi.org/pypi/<pkg>/<version>/json 以取得發布時間。

若要設定它，開啟工作區的供應鏈窗格並使用時效閘門群組：

1. 切換拒絕比截止時間更年輕的套件。
2. 以步進器設定最小時效：（0–90 天）。
3. 如果某個特定套件必須能立即安裝——例如，是你自己的團隊發布的——用新增項目按鈕將它加入豁免套件之下。項目使用允許清單格式：npm:axios 將豁免範圍限定於一個生態系，而裸的 axios 會在每個生態系中比對該套件名稱。比對不分大小寫。

提示： npm 的中繼資料請求會被靜默升級為完整的 packument，好讓閘門能看到發布時間——對於 npm 的縮寫中繼資料格式，你不需要做任何事。

OSV 漏洞檢查

OSV 檢查會在 api.osv.dev——免費的開源漏洞資料庫，它匯總了 GitHub Advisory Database、PyPI 公告、Go 的漏洞資料庫、RubySec 等——上查詢每一個下載成品的生態系、套件與版本。如果該確切版本有任何公告達到或超過你所選的嚴重度，該下載就會被 451 阻擋。它涵蓋全部八個生態系，且不需要 API 金鑰。

當公告帶有 GHSA 標籤時，嚴重度取自該標籤；否則 Bromure 會從公告的向量字串計算 CVSS v3 基本分數。

在 OSV 漏洞檢查群組中：

1. 切換在 api.osv.dev 上查詢套件（免費、不需金鑰）。
2. 選擇在此嚴重度阻擋：——低度以上、中度以上、高度以上，或僅限重大。

此檢查預設關閉，而嚴重度門檻預設為高度以上——正如窗格本身所指出的，一個遞移子套件中的低度嚴重性 CVE 不應中斷工作流程。查詢僅在成品下載時執行（而非中繼資料抓取），結果會在應用程式執行期間快取在記憶體中，最多同時執行 16 次查詢，而暫時性的網路錯誤最多會以退避方式重試 5 次。如果完全無法連上 OSV，該套件會被保留以待你的同意，而非被靜默允許——見離線與降級行為。

套件過濾：socket.dev 與 Delpi

套件過濾群組透過一個互斥的單選鈕選擇信譽供應商：無、socket.dev 或 Delpi。這兩個供應商的運作方式截然不同——socket.dev 是代理伺服器在放行抓取前先諮詢的預先查詢；Delpi 則直接取代 npm 登錄表。設計上一次只能有一個作用（同時執行兩者會對每次安裝雙重過濾），而選擇無會停用兩者，同時保留任何已儲存的金鑰。無論你選擇哪個供應商，本章中的其他各層——時效閘門、OSV、指令碼剝除——仍會在其之上套用。

預設是無。在單選鈕存在之前建立、且已有 socket.dev 金鑰的工作區，會自動被推斷為 socket.dev。

socket.dev

socket.dev 是一項商業套件信譽服務。選擇 socket.dev 並輸入 API 金鑰後，代理伺服器會在提供每一個成品下載之前，先對照 socket.dev 的問題 API 進行檢查。它支援 npm、PyPI、Go、Maven、RubyGems、NuGet 與 Packagist——但不支援 Cargo（見各生態系的涵蓋範圍）。

你需自備金鑰：點擊 API 金鑰：欄位旁的取得 API 金鑰（它會開啟 socket.dev/dashboard/settings/api-tokens），建立一個權杖，然後將它貼入安全欄位。在輸入金鑰之前，兩個阻擋切換都會保持停用，而空白金鑰會使 socket.dev 完全停用，無論切換為何。金鑰儲存在主機端工作區的 profile.json 中，永遠不會進入 VM；所有查詢都源自你的 Mac。

有兩個獨立的阻擋可用：

• 阻擋已遭入侵的套件（流氓安裝指令碼、被標記為惡意程式、仿冒拼寫、可疑遙測）——針對 socket.dev 攻擊形態的供應鏈風險問題觸發。確定性的惡意程式訊號（惡意程式、已知惡意程式、GPT 偵測到的惡意程式、惡搞套件、遭入侵的 SSH 金鑰）會在任何嚴重度都阻擋。較嘈雜的攻擊形態訊號——混淆的程式碼、可疑字串、安裝指令碼、仿冒拼寫、shell 存取、異常的 HTTPS 使用——只在 socket.dev 將其評為高度或重大時才阻擋，因此帶有無害 postinstall 的套件不會被誤抓。純品質與屬性訊號（新作者、環境變數讀取、網路存取、遙測）刻意永遠不阻擋。
• 阻擋帶有已知 CVE 的套件——針對 socket.dev 的漏洞分類，在達到或超過 CVE 阻擋門檻：選擇器（與 OSV 相同的四個層級；預設高度以上）時觸發。

兩個阻擋都預設關閉。結果會在應用程式執行期間快取，最多同時執行 16 次呼叫，而暫時性失敗最多會以退避方式重試 5 次。驗證錯誤會連同 HTTP 狀態與回應內文的預覽一起顯示在安全記錄中。

附註： 如果你同時啟用 OSV 與 socket.dev 的 CVE 阻擋，兩者都會檢查每一個成品——這是允許的（它們是不同的層），只是在 CVE 涵蓋上有所重複。許多使用者會改為將 socket.dev 的已入侵套件阻擋與免費的 OSV 檢查搭配使用。

Delpi

Delpi 是由 Lupin & Holmes（landh.tech）提供的一個直接替換式安全 npm 登錄表，它提供預先審查過的套件。Bromure 不是去查詢套件，而是將每一個 npm 登錄表請求——中繼資料、tar 封存檔、稽核，任何送往 registry.npmjs.org 或 *.npmjs.org 的請求——重新路由到 Delpi 位於 depi-npm-proxy.landh.tech:443 的 npm 相容過濾登錄表，將你的金鑰附加為 Authorization: Bearer 標頭，並剝除客體送出的任何 Authorization 標頭。Delpi 會在其 packument 中改寫 tar 封存檔的 URL 以指向自身，因此那些後續抓取也會在主機端被注入金鑰。

若要啟用它，在單選鈕中選擇 Delpi，並將你的金鑰貼入 **API 金鑰：**安全欄位（取得 API 金鑰會開啟 landh.tech）。當該欄位為空時，會顯示橘色警告：輸入 API 金鑰——沒有金鑰 Delpi 會保持關閉。 每一個被重新路由的請求都會記錄在安全記錄中：

[delpi] GET registry.npmjs.org/… → https://depi-npm-proxy.landh.tech

錯誤處理是明確的，而非靜默的：

• 401（金鑰被拒絕）。 Bromure 會替換為一個 npm 會印出的清晰純文字錯誤（「Bromure: the Delpi registry rejected the configured API key…」，帶有標頭 X-Bromure-Block: delpi-auth），將其記錄下來，並針對每一個工作區與金鑰的組合觸發一次性的 GUI 警示：「Delpi 拒絕了你的 API 金鑰」。無介面的 SSH／TUI 工作階段不會收到 GUI 警示；它們依靠記錄行與改寫過的 npm 錯誤。
• 403（套件被 Delpi 阻擋，或金鑰未獲授權存取它）。 記錄並原封不動地放行，因此 npm 會回報 Delpi 自身的拒絕文字。

Delpi 僅影響 npm——其他七個生態系不受它影響。Delpi 在單選鈕中取代的是 socket.dev，而非你的本機政策：時效閘門、OSV 檢查與指令碼剝除仍會對 Delpi 所提供的內容執行。

安裝指令碼剝除

npm 的 preinstall、install、postinstall 與 prepare 掛鉤會在安裝時執行任意程式碼，是現實世界 npm 惡意程式的主力。啟用即時從 npm tar 封存檔剝除 preinstall／install／postinstall／prepare（在安裝指令碼群組中）後，代理伺服器會即時改寫每一個 npm tar 封存檔：它會解壓縮 .tgz、定位頂層的 package/package.json、移除那四個指令碼鍵、重新計算 tar 標頭的檢查碼，然後重新以 gzip 壓縮。

由於 tar 封存檔的位元組改變了，代理伺服器也會從套件的登錄表中繼資料中清除 dist.integrity 與 dist.shasum，因此 npm 會自行從剝除後的 tar 封存檔計算雜湊，其驗證在未釘選的安裝中仍然通過。每一次剝除都會被記錄（「stripped install scripts from」該套件與版本，以橘色顯示）；經檢查後判定乾淨的 tar 封存檔僅會被標上 X-Bromure-Rewritten: supply-chain 標頭。在任何剖析失敗時，原始的 tar 封存檔會原封不動地放行——此層採故障開放，因為它絕不能弄壞一個格式正確的安裝。

有些套件確實需要安裝指令碼——原生繫結編譯器，例如 better-sqlite3 或 node-canvas。將這些加入允許安裝指令碼的對象（格式為 npm:better-sqlite3），它們就會保留其掛鉤。

此切換預設關閉，且有兩個限制適用：

• 僅限 npm。 PyPI 的 sdist 不會被改寫——setup.py 就是任意程式碼，因此在那裡進行剝除不可行。
• 僅限未釘選的安裝。 一個完整性雜湊已在 package-lock.json 中釘選的 tar 封存檔，無法在不使驗證失敗的情況下被改寫。那種情況由下一層來管理。

鎖定檔釘選的安裝

一次鎖定檔釘選的安裝——npm ci——會在鎖定檔中釘選每一個 tar 封存檔的完整性雜湊。Bromure 無法在不破壞雜湊驗證的情況下改寫那些 tar 封存檔，因此它唯一的選項是原封不動地放行它們，或阻擋它們。預設情況下它們會靜默放行。

如果你想有所置喙，在鎖定檔釘選的安裝群組中啟用在原封不動放行鎖定檔釘選的 tar 封存檔前提示（npm ci、pip --require-hashes）。一批當中第一個鎖定檔釘選的抓取（對 npm 而言，透過 npm-command: ci 請求標頭偵測）接著會彈出一個主機同意對話框，標題為放行來自工作區「…」的 npm ci（鎖定檔釘選的安裝）？，帶有按鈕允許 15 分鐘、允許一次、在本工作階段其餘時間允許與不允許。整批同時進行的抓取會合併到那一個提示上並遵循你的決定；拒絕會以 451 阻擋該抓取，而該拒絕會被記住 60 秒，好讓重試不會重新提示。

附註： 儘管 UI 標籤提到了 pip --require-hashes，目前偵測僅針對 npm 的 npm-command: ci 標頭實作——pip 的雜湊釘選安裝不會觸發此提示。（它們也永遠不會被改寫，因為 PyPI 成品永遠不會被修改。）

同意提示與授予

所有供應鏈詢問使用者的路徑——鎖定檔直接放行，以及下文所述的未經驗證套件保留——都會經過一個共用的同意仲介，並具備突發合併：對同一範圍的並行請求會等待在單一對話框上，而非堆疊警示。每一個提示都提供相同的四個決定：

作用中的授予與拒絕會在核准 UI（視窗 → 憑證核准…區域）中列為供應鏈決定——與防護欄決定分開——你可以在其中提早撤銷一項授予。授予僅存在於記憶體中，不會在應用程式重新啟動後留存。

在遠端 SSH／CLI 工作階段中沒有 GUI 對話框：同樣的問題會在工作區的 tmux 內以選擇器呈現。不作答即表示拒絕。見遠端存取。

設定政策

供應鏈政策是各工作區分別設定的，位於編輯工作區視窗的供應鏈窗格中（側邊欄中的黃色出貨箱圖示）。完整的逐欄參考位於供應鏈設定；預設值一覽如下：

三個操作細節：

• 編輯即時生效。 儲存工作區會立即將新政策推送到執行中的工作階段——代理伺服器會針對每個請求讀取它，因此永遠不需要重新啟動 VM。每一個新的或變更過的政策都會在安全記錄中以一行摘要確認，例如：

  [supply-chain] policy engaged for 1a2b3c4d: age-gate=2d osv=high socket.dev=compromised+cve=high strip-scripts
  

  設定錯誤會就在那行摘要中被點名：socket.dev=key-set-but-no-toggle 表示已輸入金鑰但沒有啟用任一阻擋，而 delpi=selected-but-no-key 表示已選擇 Delpi 但因缺少金鑰而關閉。

• 儲存位置。 政策存放在工作區位於 ~/Library/Application Support/BromureAC/profiles/<id>/ 下的 profile.json 中（僅寫入非預設欄位）。socket.dev 與 Delpi 的 API 金鑰也存放於此——僅在主機端，在 UI 中顯示為安全欄位，且永遠不會複製到 VM 中。沒有供應鏈專屬的環境變數或啟動引數。

• 遠端設定。 SSH／TUI 遠端選單提供相同的供應鏈窗格與相同的欄位，因此無介面的執行個體可以在沒有 GUI 的情況下設定。見遠端存取。

安全記錄視窗

供應鏈管線所做的一切都能在安全記錄中看到——開啟視窗 → 安全記錄…。它是代理伺服器發出的每一個安全事件的即時尾隨：供應鏈查詢與判決、451 阻擋、指令碼剝除、政策生效確認與 Delpi 重新路由，以及提示注入偵測、Fusion 啟用／停用、LLM 路由變更、遠端存取事件與工作樹行。一個視窗服務整個應用程式；再次選擇該選單項目會將它帶到前面。

各行以顏色編碼，好讓你一眼判讀一次安裝：

此視窗有一個篩選…欄位以縮小檢視範圍（輸入套件名稱、生態系，或你在意的那些行中的任何文字）、一個自動捲動核取方塊（預設開啟；取消勾選以在你閱讀時停止跟隨尾隨）、一個會清空緩衝區的清除按鈕，以及一個顯示項目計數的頁尾（「42 entries」，或在篩選作用中時「7 of 42 entries」）。一則空狀態訊息會說明何時會出現項目。

若要看它實際運作：開啟該視窗、在工作階段內執行任何安裝（npm install、pip install、cargo add、gem install……），並觀看項目串流進入。一次完全乾淨的安裝仍會為每個成品產生「inspecting」行——這是刻意的，好讓一個安靜的管線能與一個被繞過的管線區分開來。

附註： 緩衝區是一個上限約為 5,000 行的記憶體環形緩衝區，不會在應用程式重新啟動間留存。每一行也會被鏡像到應用程式的 stderr，因此從終端機啟動 bromure-cli（或擷取其記錄輸出）能給你一份持久的副本。該視窗以 820×460 開啟，可縮小調整至 720×360。

離線與降級行為

管線的信譽檢查依賴於你的 Mac 發出的外送呼叫（絕不會從 VM 發出）：OSV 用的 api.osv.dev、socket.dev 用的 api.socket.dev、PyPI 發布時間後援用的 pypi.org，以及 Delpi 用的 depi-npm-proxy.landh.tech。當一個啟用的來源無法產生判決時——重試後網路仍中斷、HTTP 錯誤、速率限制、驗證失敗，或不支援的生態系——Bromure 會故障關閉，而非靜默允許。

下載會暫停，而一個未經驗證套件的保留會針對每個套件與版本詢問你，帶有一個標題為**放行來自工作區「…」的未經驗證套件？**的系統警示：Bromure 無法連上來源以審查該套件，而安裝它意味著接受一個未對照你所設定的信譽來源檢查過的套件。四個標準同意決定適用；拒絕（包括在沒有可用 GUI 且遠端提示逾時的情況下）會以 451 阻擋。保留是以每個 package@version 為鍵，因此一次核准永遠無法涵蓋整個相依圖。

這是刻意的防護：沒有它，一個能對信譽服務誘發速率限制的攻擊者就能讓套件未經檢查地偷渡過去。實際的後果：

• 在完全離線的情況下工作且啟用 OSV 或 socket.dev，意味著每一個未快取的套件都會提示。在離線期間停用那些層——時效閘門能在沒有連線的情況下，從已快取的中繼資料持續運作。
• socket.dev 加上 Cargo意味著每一個 crate 都會提示，因為 socket.dev 完全無法審查 Cargo（授予是以每個 package@version 為單位，因此一次工作階段授予只涵蓋那一個 crate 版本）。
• **PyPI 發布時間後援是唯一的例外：**在純粹的網路錯誤時，它會對該次抓取故障開放（該失敗不會被快取，因此下次會重試該查詢）。時效閘門的中繼資料改寫不受影響。

入侵偵測

供應鏈檢查降低了敵意程式碼進入沙盒的機率；入侵偵測則捕捉那些確實進入的敵意程式碼試圖動作的那一刻。它是憑證系統的一部分，而非套件管線——誘餌憑證與權杖交換的完整全貌在憑證中——但它的警報記載於此，因為一個被下毒的套件是它最可能的觸發因素。

VM 發出的每一個外送請求都會在單一次通行中被掃描，以尋找憑證交換層所鑄造的誘餌（「假」）權杖。一個範圍限定於某個主機（比如 github.com）的假權杖，出現在一個送往任何其他主機的請求中，就是憑證外洩的特徵。當這種情況發生時：

1. 代理伺服器以 451 阻擋該請求——目的地永遠收不到一個位元組。
2. VM 會立即暫停。如果該工作階段已分離，它會被強制重新附加並顯示出來。凍結的工作階段框會染成紅色。
3. 一則重大警示出現，標題為此環境可能已遭入侵，說明 Bromure 偵測到一次外送嘗試，欲將所指名工作區的一個工作階段憑證洩漏到一個並非為它鑄造的主機，且該 VM 已被暫停——並針對每次洩漏附一行細節：一段權杖預覽（如 sk-a…f9q3）、該憑證的名稱、它為之鑄造的主機，以及觀察到它前往的主機。

該警示提供三個回應：

• 關機（預設）——停止 VM 並將該工作區標記為已入侵。
• 儲存以供調查——你選擇一個資料夾；Bromure 會匯出 disk.img（VM 系統磁碟的副本）、home.tar.gz（工作區的家目錄），以及每個共用資料夾的 shares/<name>.tar.gz，然後關機並將該工作區標記為已入侵。RAM 狀態會被捨棄。
• 繼續——接受風險並恢復；如果再次發生，偵測器會重新觸發。Esc 與 Cmd-. 刻意不對應到繼續——恢復一個可能有敵意的 VM 必須是一次明確的點擊。

一個被標記為已入侵的工作區在你明確清除它之前會拒絕再次開機，而清除流程會警告共用資料夾不會被清除——它們可能仍持有受汙染的檔案，因此請手動審查它們。

沒有任何需要設定的東西：對於宣告了主機範圍的憑證，偵測永遠開啟。沒有釘選主機（「任何主機」）的手動憑證永遠無法觸發它，而 Claude／Codex 權杖使用一種寬鬆的相同註冊網域比對（一個為 api.anthropic.com 鑄造的權杖，在另一個 anthropic.com 主機上被看到並不會發出警報）。一次只顯示一則警示；在它開啟時發生的重複事件會被捨棄。

企業可見性

對於向 bromure.io 註冊的工作區，每一次中繼資料與成品抓取也會向企業事件串流發出一個 supply_chain.fetch 事件，攜帶生態系、套件、版本、請求種類、結果（allowed、rewritten、blocked 或 stripped），以及原因種類（age_gate、osv、socket_compromised、socket_cve、verify_unavailable、lockfile_denied、scripts_stripped）。光是註冊就能讓管理員擁有全組織的套件下載可見性——一份每個代理程式所安裝的一切的清單——即使在關閉了每一個強制執行層的工作區上也是如此。

註冊如何運作，以及管理員在另一端看到什麼，涵蓋於企業中。