跳至主要内容
產品

在 AI 代理動手之前,決定它可以做什麼。

Agent Assembly 會針對你導流經過它的動作,依你的政策加以評估、拒絕,或在決策做出前先行阻擋,並記錄它所做的決定。未經你導流的動作不會被檢查 — 而記錄會如實說明這一點。

一句話說明:Agent Assembly 是你放在 AI 代理動作前面的一個決策點,外加一份顯示它做了什麼決定的證據軌跡。

落差

為什麼代理框架還不夠

一個握有 shell 工具與資料庫憑證的代理,可以刪掉正式環境的資料表。一個握有模型供應商金鑰的代理,可以把金鑰貼進請求裡。一個陷在重試迴圈裡的代理,可以一直花錢花到有人注意到帳單。這些都不是故障 — 每一個都是代理照著被交辦的事、用它被賦予的權限在做事。

框架讓代理具備能力 — 它們能規劃、呼叫工具並採取行動。但它們不會賦予代理身分、約束其權限,也不會讓憑證遠離模型的可及範圍。Agent Assembly 補上這道邊界,而你無需重寫代理的邏輯 — 不過代理仍必須透過受治理的路徑啟動,這道邊界才會生效。

結果是:團隊講得出代理「應該」做什麼,卻拿不出它「被允許」做什麼。日誌與追蹤是在事後回答這個問題,而那個時間點已經太晚:等到請求出現在追蹤裡,請求早就送出去了。

它決定什麼

政策回答的六個問題 — 以及每個答案能走多遠

政策是版本化的 YAML 或 JSON,你用原本就在用的 Git 流程審閱它。下面每張卡片都標示了產品實際對這個動作做了什麼,以及隨之而來的界線。它們能走的距離並不相同,而走得最短的那幾張會直說,不會借用其他卡片的自信。

執行前拒絕

它可以連到哪些網路目的地

在你導流經過 Agent Assembly 的路徑上建立的連線,會先對照你設定的目的地清單檢查,並在代理伺服器撥號之前被拒絕。其中一條目的地規則預設開啟且沒有任何組態能放寬它:連往 loopback、私有、link-local 及相關位址空間的請求一律拒絕,包含公開主機名稱解析到這些位址的情況。

它到哪裡為止。 你自己的清單在你寫進去之前是空的,而這個拒絕來自代理伺服器自己的本機組態,不是控制平面的決策。代理伺服器在 Linux 上是已發行的執行檔,在 macOS 上要用 cargo 安裝;在 Windows 上沒有本機中介,也就沒有任何東西站在連線前面可以拒絕它。

執行前拒絕

哪些工具呼叫可以離開這台機器

MCP 工具呼叫可以由控制平面依你的政策檢查,並在代理伺服器轉送之前被拒絕。

它到哪裡為止。 這是產品裡唯一一個由控制平面自己在網路之前做出的拒絕,而且在維運者開啟之前它是關閉的。它涵蓋的是以一般 HTTP POST 傳送、且已設定 gateway 端點的被攔截主機上的 MCP。你以標準輸入輸出執行的工具伺服器(最常見的做法)、以 server-sent events 執行的,或以 WebSocket 執行的,都沒有對應的攔截機制。

已評估

你自己的代理程式碼可以呼叫哪些工具

透過被包裝的框架接縫發出的工具呼叫,會在工具主體執行之前先被檢查。

它到哪裡為止。 SDK 在設計上就是建議性的 — 它是縱深防禦的一層姿態,不是權威的把關點,而不去呼叫它的代理根本沒在問。Python 會在主體之前拋出例外並失效關閉;Go 也失效關閉,但需要明確要求包裝;Node SDK 的預設模式會把檢查導向一個一律放行的用戶端,因此在那裡根本不會產生任何拒絕。在未啟用具檢查能力的模式時要求強制執行,會在啟動時明確報錯,而不是無聲地放行。

已遮蔽

被辨識出的憑證會不會跟著請求一起送出去

在 Agent Assembly 會檢查的模型供應商主機上,被辨識出的憑證會在請求轉送出去之前被移除。

它到哪裡為止。 只有三個內建主機,因為預設只對模型供應商主機檢查承載內容。預設動作是遮蔽後轉發,不是拒絕 — 偵測到憑證即行阻擋是你要主動選擇啟用的。偵出率受限於既有的樣式集合,而這條路徑上的模型回應並不會被掃描。

未量測

它可以花多少錢

政策可以宣告花費上限,針對單一代理或跨整個團隊。

它到哪裡為止。 已宣告的上限是否真的在決策路徑中被檢查,並沒有任何證據列可以佐證,因此對「強制執行」誠實的用詞是未量測 — 上面那句講的是政策可以宣告什麼,不是什麼東西擋下了呼叫。上限只存在於政策有宣告的地方,未宣告的預算等於沒有上限,而讀不到的預算儲存區會無聲地把上限重設。

需要核准

哪些動作是被擱置而不是被回答

政策規則可以擱置一個動作,而不是直接回答它。這個擱置是真的,而且失效關閉:檢查會被阻擋住,逾時則收斂成拒絕。

它到哪裡為止。 這裡把它列為尚未完成的能力,因為它就是。沒有任何已出貨的維運者介面能回應這個擱置所等待的佇列,所以實際上它會先擋住,然後在逾時時拒絕,全程沒有任何人參與。現在還不要把人工審查算進計畫裡 — 追蹤於 AAASM-5657。

開箱狀態

你動手設定之前的三個預設

一項存在但預設關閉的能力,跟一項預設開啟的能力,是兩種不同的產品。其中兩項比評估者通常預期的還要強,第三項則是最常被比較表漏掉的那一項,因為它的方向相反。

在沒有政策的情況下啟動工作階段 — 拒絕

當無法解析出有效政策時,aasm run 不會啟動工具;政策可以解析但未宣告任何規則時,它同樣不會啟動。沒有政策不等於獲得許可,空的政策代表尚未設定,而不是全部放行。兩者都在任何東西啟動之前就拒絕。

送往私有位址的對外流量 — 一律拒絕

一個被交給雲端 metadata 位址、或被交給會解析進你自己網路的內部主機名稱的代理,會在代理伺服器撥號之前被拒絕。這道防護重新檢查的是每一個解析出來的位址而不是名稱,所以解析到私有位址空間的公開主機名稱同樣會被拒絕。沒有任何組態或環境變數可以放寬它。

未命中任何規則的動作 — 允許

一旦政策生效,未命中任何網路、工具、能力或核准規則的動作會被允許。政策之內預設放行,但「是否具備政策」這件事預設拒絕 — 兩半都要講,否則這組說法會誤導人。

完整的預設狀態,逐列列出 →

決策套用在哪裡

三個地方,權限本質上並不相同

它們不是一條有先後順序的鏈。其中一個不會替另一個補位,而你沒有部署的元件會被回報為缺席,不會被下一個悄悄接手。「檢查點沒看到,所以底下一定有東西看到了」這種推論,正是這個產品的架構存在要阻止的錯誤。

旁掛式代理伺服器

三者中最強的一個。它在連線階段拒絕、在通道內重新檢查主機、阻擋或移除被辨識出的憑證,並裁決 MCP 工具呼叫 — 這些都在它向上游撥號之前就返回。這是發生在動作之前、且位於代理自身行程之外的拒絕。

在 Linux 上是已發行的執行檔;在 macOS 上要用 cargo 安裝。在 Windows 上沒有任何形式的本機中介。

SDK 檢查點

它包裝你的框架的工具接縫,在被包裝的工具主體執行之前拋出 — 那是在你自己的程式碼內部,決策所能套用的最早時點。

刻意設計成建議性的:是縱深防禦的姿態,而不是權威的把關點。不去呼叫它的代理並沒有在問,而沒有人接過的框架則落在包裝之外。

作業系統層級的控制

因平台而異,而且就今天存在的部分而言,它們多半只是觀測。在 Linux 上,核心探針會回報 TLS 明文、行程執行與檔案活動,而這類訊號都不參與任何允許或拒絕的決策。

macOS 沒有對應的轉接器 — 但它同時也是唯一一個真的能觸及主機層強制執行等級的平台,途徑是一次選擇性啟用、經授權的設定寫入。兩半都成立,而且兩半都必須講。這個等級在已發布的 v0.0.1-rc.6 標籤上被記為尚未達成,因為它所依據的證據晚於該標籤。Windows 兩者皆無。

那控制平面呢? 它保存你的政策、預算、核准與稽核 — 而它不持有任何流量。只有在上面三者之一正等在該動作前面時,它的答案才會真的擋下這個動作。這就是為什麼導流是第一步:前面沒有東西等著的決策,是一筆記錄,不是一次拒絕。

六個角色,以及其中哪些真的能擋下什麼 →

各路徑涵蓋與未涵蓋的範圍 →

改變了什麼

你得知的時間點提前了

代理的第一個錯誤,通常是在帳單、日誌或事故檢討裡才浮現 — 那時呼叫早就送出去了,剩下能決定的只有怎麼收拾。這裡改變的是時間點。在你導流經過 Agent Assembly 的路徑上,只要有東西等在該動作前面,被你的政策拒絕的呼叫就不會送出去,而記錄寫的就是那次拒絕。在那條路徑之外,不會有任何宣稱:記錄會寫成該動作未經檢查,那是一個你可以去補上的缺口,而不是一個你必須事後發現的缺口。

界線

它不做什麼

這些會列在頁面上,理由我們寧可直說也不要讓你自己撞到:評估者在建置之後才發現一句被誇大的說法,比一開始就讀到一條準確的限制更糟。

  • 它不會治理你沒有導流的代理。導流是你要親自去做的事,每個代理、每次啟動都要做一次,而在受管啟動之外開始的工作階段就是完全在這一切之外 — 而且從內部偵測不到。
  • 它不會檢查送往它沒有攔截的主機的承載內容。預設檢查三個內建的模型供應商主機;其他主機都會被建立通道,也就是連線已被觀測,承載內容則沒有。
  • 它不會讓憑證離開代理自己的行程。它做的是在被檢查的主機上掃描對外請求,並在轉送之前移除被辨識出的憑證。
  • 它的稽核鏈可偵測竄改,但沒有簽章。它是對日誌檔做的無金鑰摘要,所以任何能改寫該檔案的人都能重新算出它 — 而驗證檢查的是現存項目之間的鏈結,因此一份被刪除後重建的日誌會驗證通過。
  • 它在 Windows 上沒有任何東西可以提供,那裡完全沒有本機中介。在它確實支援的平台上,UDP、QUIC 與 HTTP/3 也不在傳輸協定範圍內。

成熟度。 開放原始碼的執行環境尚未達到 1.0,是以預先發行系列的形式釋出。託管服務屬於已規劃 — 已決定,但尚未建置 — 所以本頁沒有任何內容構成對推出日期、地區、服務等級協議或法規遵循狀態的承諾。

佐證

四件你不必信我們就能自己查的事

自己驗證稽核鏈

aasm audit verify-chain 隨開放原始碼版本一起出貨。它證明的是現存項目的完整性,不是這份日誌是否完整 — 而且寫出是盡力而為的,所以決策可以做成,記錄卻遺失。

驗證能證明什麼、不能證明什麼 →

讀出產生這個決策的那條規則

政策是版本化的 YAML 或 JSON,你用原本就在用的 Git 流程審閱它。欄位參考文件是公開的,所以本站描述的規則就是你可以自己查到的規則。

政策欄位參考 →

把上面任何一句話追回它的界線

本頁每一句能力陳述都是共用宣稱登錄表十六筆條目之一,是引用而非改寫。每一筆都帶著它所達到的用詞、隨之而來的界線,以及背後的證據列 — 包含帶有「未量測」用詞的那四筆,其中三筆整筆皆是。

宣稱登錄表 →

讀做出決策的那份執行環境原始碼

gateway、代理伺服器、CLI 與 SDK 都以 Apache-2.0 授權放在 GitHub 上,連同釘住本頁所述各項行為的測試。什麼是開放原始碼、什麼不是,是明講出來的,不是靠暗示。

開放核心的界線 →
你怎麼跑它

開放原始碼核心 vs 託管 Cloud Console

開放原始碼核心

以 Apache-2.0 crate 自行架設一套受限功能的堆疊,用於本機評估與開發 — gateway、CLI 與 SDK 適用所有平台;代理伺服器適用 macOS 與 Linux;eBPF 探針僅適用 Linux。免費。

託管 Cloud Console

為組織、團隊、政策版本控管、核准與稽核而設的託管控制平面 — 無需你自行執行後端。

開放原始碼核心自行架設一套用於評估與開發的受限功能堆疊;託管主控台則以受管服務提供完整功能。

開始使用 →它如何運作GitHubCloud Console👷 即將推出