資安與風險
- 撰寫對象
security-engineer- 它導向的那個決定
- 決定這東西是否改變了那些已經在跑的代理的風險狀況，以及它不涵蓋什麼。
這一切從哪裡開始
你所管轄範圍內的 AI 代理，早就能觸及網路、檔案系統與 shell。而你手上的那些控制措施是為人、為服務打造的：身分、審查、變更管理，以及你事後才會去讀的日誌。它們沒有任何一個站在代理的決策與代理的動作之間。
你的偵測能力完全是回顧性的，而你的補償性控制措施，其實是「還沒有人給過這些代理任何重要的東西」 — 而在某個團隊出貨一個帶著正式環境憑證的代理的那一週，這件事就不再成立了。
為什麼它成了這一季的問題
有個團隊要求對一個裡面放著部署金鑰的儲存庫執行一個編碼代理。你被要求簽核，而誠實的答案是：你沒有任何機制能說出它可以觸及什麼 — 只有一個能讓你事後查出來的機制。
Agent Assembly 對此做了什麼 — 以及每個答案能走多遠
Agent Assembly 是一個放在代理動作前面的決策點 — 範圍限於你導流經過它的路徑 — 再加上一份它做了什麼決定的記錄。就一次資安審查而言，有六筆項目承擔了主要的分量。
底下每一張卡片，都是這四個頁面共用的十六筆主張登錄表中的一筆項目，皆為原句引用而非改寫。用語是登錄表自己的用語，是從證據抄下來的，而不是為了配合句子挑選的；旁邊的界限是這項主張的一部分，不是它的背景說明。每一筆項目 — 包含這一頁沒有引用的那些 — 都會連同背後的能力清單列一起公開：共用主張登錄表。
在你導流經過 Agent Assembly 的路徑上所建立的連線，會依你所設定的目的地清單進行檢查，並在代理伺服器撥號之前遭到拒絕。
它到哪裡為止。 這次拒絕出自代理伺服器自身的本機對外流量組態，而非控制平面的決策。目的地清單預設為空 — 這次拒絕之所以存在，是因為有維運者設定了它。在 Linux 上是發行產物；在 macOS 上，cargo install aa-proxy 是唯一的途徑；在 Windows 上沒有任何本機中介。如果代理伺服器不在這條連線前面，這條連線就只是單純地被建立起來。
送往回送位址、私有位址、鏈路本機位址及相關位址空間的請求一律被拒絕，包含公開主機名稱解析到這些位址的情況。
它到哪裡為止。 預設開啟、失效關閉，而且沒有任何組態可以放寬它。它涵蓋的範圍是位址空間，而不是任意的公開目的地 — 它並不提供 RC1 所講的那件事，也不得被當成有做到那件事。
MCP 工具呼叫可以由控制平面依你的政策進行檢查，並在代理伺服器轉發之前遭到拒絕。
它到哪裡為止。 這是本產品中唯一一個由閘道決定、且發生在撥號之前的拒絕，而它預設關閉。它涵蓋的是在已設定閘道端點的被攔截非 LLM 主機上，以一般 HTTP/1.1 POST 送出的 MCP。以 stdio 執行的工具伺服器 — 最常見的設定方式 — 以及 SSE 與 WebSocket 都沒有攔截機制；Streamable HTTP 則被記錄為在功能上就是壞的，而不只是未被涵蓋。
在 Agent Assembly 會檢查的模型供應商主機上，被辨識出來的憑證會在請求被轉發之前從中移除。
它到哪裡為止。 共三個內建主機，因為 llm_only 預設開啟。預設行為是遮蔽後轉發，而非拒絕。偵出率受限於樣式集合 — 並沒有 Stripe 的偵測器。該路徑上的模型回應不會被掃描。
在控制平面已設定、卻變成連不上的情況下，決策路徑會拒絕，而不是允許。
它到哪裡為止。 在有閘道的那些路徑上是失效關閉：執行環境在閘道連不上時會拒絕，代理伺服器會拒絕啟動，而閘道在政策載入失敗時會中止。反過來則不對稱 — 完全沒有設定閘道的執行環境，會落到一次本機評估，其最終預設是允許。已設定然後壞掉是失效關閉；從未設定則是失效放行。
某一項決策的記錄是否持久地抵達稽核鏈，並未被確立。驗證工具是真實存在的 — aasm audit verify-chain 隨開放原始碼版本一併提供 — 但它所證明的是現存項目的完整性，而不是任何一項特定的決策確實產生了一筆記錄。
它到哪裡為止。 能力清單中關於這個主題的唯一一列，是寫出失敗時會發生什麼的那一列，而該列帶著 coverage: unmeasured、failure_posture: fail_open 與 evidence: gap。所以誠實的用語就是該列自己的用語。關於這條鏈的其他一切都是界限，不是能力：它可察覺竄改，但既非不可變更，也未經簽章 — 它是一個無金鑰摘要，所以任何能改寫輸出目的地的人都能重新算出它。鏈首會在送出之前就先推進，而通道滿載時會丟掉該筆項目、該次呼叫卻仍然返回，這使得被丟棄的項目與被刪除的項目無從分辨。一份被清空的日誌驗證起來也會是乾淨的。除非代理伺服器的稽核路徑已設定，否則它根本不會寫出任何本機記錄。請見那兩個缺口。
之後有什麼不一樣
對於一個你已導流的代理，送往你所設定的清單之外的目的地的請求，會在連線被開啟之前遭到拒絕。
真正改變的那個安全面向是順序 — 決策發生在效果之前 — 而不是涵蓋率，也不是記錄的完整性：某一次拒絕的項目是否持久地抵達稽核鏈，是 RC6，而它是未量測。你買到的是這個順序；不要以為你買到了一本帳本。
你可以查證什麼，以及在哪裡查
各種繞道方式是被逐一列舉並公開出來的，而不是被辯解掉的 — 既以一個限制頁面的形式呈現，也以能力清單中每一列的「已知繞道方式」欄位呈現。
已列舉的繞道方式 →本頁每一句話都要回溯到的那份 80 列證據基礎，其中每一列都帶著它的涵蓋用語、決策時點、預設狀態、失效姿態與證據。
能力清單 →威脅模型、信任邊界與稽核性質 — 鏈驗證能確立什麼、又不能確立什麼。
安全模型 →逐一情境的決策、決策者與界線，每一個都附上它所依據的能力清單列。
風險情境 →預設開啟的有哪些，逐列列出 — 產品承諾頁上的第 3 級表格。一項存在但預設關閉的能力，跟一項預設開啟的能力，是兩種不同的產品。
預設開啟的有哪些 →主張紀律本身，包含這個產品拒絕發布的那些措辭，以及為什麼再多的核可也不會讓一句沒有佐證的絕對說法變成真的。
主張用語 →
那些你原本會比較晚才發現的事
- 抗繞道能力只有一個階級，也只有一列。其他每一種狀態 — 包含 GatewayProtected — 都應視為對抗繞道能力隻字未提。—（ADR 0030 的保護狀態）RC9
在 macOS 上，針對 Claude Code 的受管啟動，是唯一一條觸及 ADR 0030 的 HostEnforced 這一階級的路徑。
它到哪裡為止。 ADR 0030 §4.1 讓 HostEnforced 成為唯一一個主張抗繞道能力的狀態，而能力清單中恰好只有一列帶著它。有兩件事把它限制得很緊。這一階級所依據的，是回讀一份由 root 擁有的受管設定檔，而該工具在執行期間是否真的遵守那些設定鍵，屬於未量測。而能力清單把這一階級記為在已發布的 v0.0.1-rc.6 標籤上尚未達成 — 它所依據的證據晚於該標籤。macOS 的主機層攔截本身處於 Integrated，僅限於工具治理的範圍：可以主張那份檔案，絕不要主張強制執行。
- 目的地清單預設為空。在開箱狀態下，RC1 什麼都不會拒絕。一律開啟的是 RC2，而它涵蓋的範圍是位址空間，而不是你指名的那些目的地。
- 導流是逐一代理、逐次啟動的。在受管啟動之外啟動的代理就在這道界線之外，而且那件事從內部偵測不到（RC15）。
- 最大的缺口是主機層動作。由原生代理行程所產生的 shell 指令或子行程，在已發行的版本裡根本沒有任何攔截機制；瀏覽器自動化與資料庫查詢也是一樣。政策語言能夠表達這些規則；但已發行的東西裡沒有任何一個能據以行動。
- 未經檢查不等於乾淨。未量測RC7
在沒有任何東西檢查過某個動作的情況下，記錄會寫成未經檢查 — 而不是寫成它被允許。
它到哪裡為止。 範圍是動作或承載內容，絕不是連線：代理伺服器沒有攔截的主機，在 CONNECT 時仍然會被裁決，所以它的連線是已觀測，而它的承載內容是未量測。今天有一個未修復的缺陷與這條規則相牴觸 — 對於即將以隧道方式、未經檢查轉送出去的流量，CONNECT 層級的事件仍然會記下一筆允許（AAASM-5637） — 所以請把這條規則與這個未修復的缺陷一起講，不要當成已完成的行為。
- 這份證據可察覺竄改，但並非不可變更，而且它可能遺失。被丟棄的項目與被刪除的項目無從分辨，而且沒有任何能力清單列能確立某項決策的記錄真的會持久抵達 — 這裡的用語是未量測（RC6）。不要把稽核鏈當成足以滿足留存或不可否認性要求的那項控制措施來呈現。
- 代理平面接受未經驗證的呼叫者。一條刻意設計、暴露面有界的啟動引導路徑，但它終究不是一個經過驗證的平面。已評估RC16
代理會以一組 Ed25519 did:key 身分與一份持有證明進行註冊，而委派血緣是在伺服器端推導出來的。
它到哪裡為止。 代理平面依設計即可在未經驗證的情況下被觸及，作為啟動引導路徑：任何觸得到它的未經驗證呼叫者都可以註冊，也可以送出政策查詢。那些查詢是在租戶識別被中性化、而不是以呼叫者自身租戶的情況下被評估的，所以暴露面在於這個平面會接受這次呼叫。組織範圍的限縮是逐一呼叫點套用的，而不是在儲存層套用。不要把代理平面描述成經過驗證的。
- 「需要核准」不是你今天買得到的能力。需要核准RC12
不作任何主張。
它到哪裡為止。 能力清單裡沒有任何一列達到這個用語。這個擱置在閘道這條路徑上確實存在，且逾時會失效關閉，但沒有任何已出貨的維運者介面能夠回應它；而在 MCP 通道之內，待決的決策會直接被降級成一次拒絕，所以在那裡也同樣找不到人來處理。AAASM-5657。
- Windows 上沒有任何本機中介。不支援RC14
被指名的那些傳輸協定與平台並不可用，而對照表說明了是哪些。
它到哪裡為止。 Windows 上沒有任何形式的本機中介。UDP、QUIC 與 HTTP/3 不在傳輸協定範圍內；在被攔截的主機上，HTTP/2、gRPC 與 WebSocket 也不在，以 WebSocket 承載的 MCP 同樣不在。某一個元素為不支援，並不等於整個產品為不支援。