端點更新的獨立發布保證

同一廠商推送兩次更新。一次在數秒內發布至 1.2% 金絲雀環;另一次在任何端點重新開機前即被阻擋。

Kestrel 是一個獨立控制平面,介於您的軟體廠商與生產機群之間。它在廠商更新抵達任何端點之前進行攔截,以確定性方式證明 CrowdStrike 級別的失效特徵,透過諮詢模型無法推翻的政策對推出進行閘門管控,並匯出董事會與監管機構皆可重新執行的已簽署證據記錄。您在此觀看的是基於合成的 8,500 個端點機群之示範,而非已部署的正式流水線。

20 → 21

導致機群當機的欄位數量不相符

CrowdStrike 根本原因,RCA 2024 年 8 月

12/12

正確的發布決策

在 12 項具標籤的測試夾具集上,確定性

0/6

良性更新上的錯誤阻擋

同一測試集中的 6 個良性測試夾具

該機群、廠商 SentinelEdge 及其 Falcon 級代理程式皆為合成。C-00000291 場景重現了已記錄的 CrowdStrike 7 月 19 日失效特徵,而非任何真實客戶的系統。

架構不相符導致數百萬台機器癱瘓,且沒有任何層級為其把關。

2024 年 7 月 19 日,單一 CrowdStrike Rapid Response Content 頻道檔案在不到 90 分鐘內導致數百萬台 Windows 機器當機。公開的根本原因不是駭客攻擊,也不是不良模型。這是一個架構不相符:雲端驗證器核准了 21 個欄位的更新,而核心直譯器仍預期 20 個欄位,導致越界讀取並引發瞬間 BSOD。由於當機發生在開機極早階段,發生當機的代理程式永遠無法重新初始化以接收復原命令,因此復原意味著必須在 Safe Mode 下逐一手動修復機器。(CrowdStrike Root Cause Analysis,2024 年 8 月。)

廠商自我審查

核准更新的驗證器屬於交付該更新的同一個廠商。自我審查的流水線沒有任何獨立第三方在負載進入您的生產機群途中對其進行檢視。

現有工具著眼於別處

SBOM 與 SCA 工具涵蓋開源相依性,而非廠商的專有頻道檔案。內容安全把關提示詞,身分安全把關存取。沒有人在廠商自身的更新進入途中對其進行讀取審查。

變更諮詢委員會直接放行

一家擁有 5,000 個端點的企業運行著來自其無法控制之廠商的 8 到 12 個核心特權代理程式,每個代理程式都能直接將頻道檔案推送到 ring 0。變更諮詢委員會基於信任核准廠商更新,因為在該流水線與生產環境之間空無一物。

判定是由監管機構可重新執行的程式碼所決定,而非由提出建議的模型所決定。

諮詢團隊會對每個更新進行推理,但無法做出決定。Kestrel 將每個套件引導通過一個流水線:將其正規化、依機群狀態落實關聯、讓團隊進行辯論,隨後將決策移交給以純 Python 編寫的確定性驗證器與政策閘門。偏向發布的諮詢代理永遠無法消除關鍵的確定性發現,因為對治理產品的信任絕不能依賴被治理對象自我擔保。

01 / SCHEMA-COMPATIBILITY DIFF

讀取直譯器預期的欄位數量

該檢查會將更新宣告的欄位數量與已部署核心直譯器的預期進行比對。21 欄位的更新遇到 20 欄位的直譯器,正是 7 月 19 日事件的文字根本原因,在任何端點重新開機之前即由算術運算捕捉。

02 / SANDBOX REBOOT-CYCLE MODEL

跨重新開機週期的個別設定檔結果

模擬沙盒跨重新開機週期為每個作業系統設定檔模擬 BSOD 與開機循環行為,此信號來自獨立於架構檢查的驅動程式相容性信號。當它回報 6 個設定檔中有 5 個失敗時,這印證了架構檢查的發現,而非單純附和。

03 / BLAST-RADIUS AND CANARY MATH

對照政策衡量的第一波部署

該檢查會對照您的最大金絲雀政策計算第一波規模。一次向全機群 100% 推出,或未宣告任何金絲雀計劃的推出,皆違反政策並會被拒絕,而分階段的 1.2% 第一波則符合政策。

04 / DEAD-AGENT AND CONFLICT DETECTOR

無法自行復原的代理程式

該檢查會標記開機前代理程式本身即為復原接收器的情況,因此一旦當機將使端點孤立並迫使逐台機器進入 Safe Mode;同時標記兩家廠商在同一時窗內修改同一個核心回呼的衝突。這正是導致 7 月 19 日演變成手動復原的失效關鍵。

諮詢團隊建構於 Pydantic AI 之上:包含一個正規化器、一個沙盒直譯器以及兩個立場對立的評論代理,一位主張更新可安全交付,另一位則主張它將導致當機。這組對抗性配對在程式碼裁決之前從雙向進行紅隊驗證。判定本身為四種處置之一:ALLOW 代表發布至金絲雀、HOLD 代表轉交審查、BLOCK 代表拒絕推出,以及 ABSTAIN 代表將無法剖析的負載轉交由人工處理,因為閘門絕不放行其無法證明的內容。

該團隊具備供應商中立性,可透過環境變數選擇 Anthropic、OpenAI 或 Gemini,預設模型為 claude-opus-4-8,並可透過確定性諮詢備援在無 API 金鑰的情況下完全離線運作。在每種模式下,驗證器與閘門均保持不變,仍會產生完整的判定與證據記錄。驗證器與閘門特意設置於代理框架之外。

同一個廠商,兩次更新,兩項記錄在案的決策。

示範治理一個合成機群 Acme Financial: Global Endpoint Fleet,涵蓋 6 個作業系統設定檔與 8 個特權代理程式(其中 5 個位於 ring-0)共 8,500 個端點。廠商 SentinelEdge 推送了兩次 Rapid Response Content 更新。請觀看 Kestrel 如何處理每一次更新。

Kestrel 針對來自 SentinelEdge 的良性 RRC-7741 更新所顯示的 Approve Rollout 畫面。綠色決策面板顯示 released to canary ring at a 1.2% first wave, schema matches deployed interpreter, 5 of 6 profiles passed 5 reboot cycles。其下方顯示受影響第一波為 102 endpoints、dead-agent loop 為 false、包含雜湊值 sha256:798431b4c96612a9 的證據記錄,以及顯示 7 of 7 events complete 的評估追蹤。
ALLOW。 良性的 RRC-7741 更新宣告了相符的 20 欄位架構與分階段金絲雀計劃。架構相符,排除舊版設定檔後 6 個設定檔中有 5 個通過 5 次重新開機週期,死代理循環為 false,且 1.2% 的第一波符合政策。Kestrel 核准推出並將其發布至由 102 個端點組成的金絲雀環。綠燈、快速且平淡無奇——這正是良好更新應有的樣子。
Kestrel 針對來自 SentinelEdge 的 C-00000291 更新所顯示的 Block Rollout 畫面,旁邊是顯示 8,500 個端點、6 個作業系統設定檔以及 8 個特權代理程式(其中 5 個位於 ring 0)的合成機群總覽。紅色阻擋面板顯示 blocked before any production endpoint rebooted,伴隨架構欄位數量不相符(預期 20 欄位,提供 21 欄位)、死代理復原循環、爆炸半徑 100% 超過 5% 金絲雀政策、受影響第一波為 8,500 個端點,以及估計避免的停機損失達 $5,000,000。
BLOCK。 C-00000291 更新重現了 7 月 19 日的特徵:20 到 21 個欄位數量不相符、6 個設定檔中有 5 個發生模擬 BSOD、死代理復原循環為 true,以及沒有金絲雀計劃、一次推送到全機群的 100% 爆炸半徑。所有四項檢查全部觸發,在任何端點重新開機前即拒絕推出。估計避免的停機損失 $5,000,000 是示範本身的計算模型,在畫面上依受影響比例乘以每小時 $5M 再乘以一小時 MTTR 下限計算得出,而非真實客戶的損失。
Kestrel 中完整的 C-00000291 阻擋決策,其證據記錄已展開。在紅色阻擋判定下方,證據記錄面板顯示包含 Open HTML Record 與 Signed JSON 按鈕的 SHA-256 內容雜湊,上方為顯示 7 of 7 events complete 的評估追蹤。
決策的收據存根。 按一下即可將已簽署的證據記錄匯出為 HTML 檢視與 JSON 檔案,載有 SHA-256 內容雜湊、判定、確定性證明、個別設定檔沙盒結果、附帶模型 ID 的諮詢判定、觸發的政策規則以及逐步評估追蹤。簽章是確保完整性的本機 SHA-256,而非企業 PKI。
Kestrel 中標題為 Normalize signed vendor manifest 的單一步驟評估追蹤彈跳視窗,標記為 184 milliseconds 內完成,說明其驗證了套件封套、廠商身分、宣告的推出方案及目標代理程式,將其轉換為具型別的發布請求,並附帶註記說明該事件與決策輸出保留在一起供稽核審查。
每一步驟皆可受檢驗。 七個追蹤事件中的每一個都會展開顯示其自身的延遲以及所執行操作的明確說明。第一步在 184 milliseconds 內將已簽署的廠商宣示說明正規化並保留於決策輸出中,使稽核人員能夠一步步逐步審查決策,而非盲目信任。

計分板所主張的,以及它並未主張的。

View Benchmark 分頁會執行完整的具標籤測試夾具集並計算計分板。閱讀每個數字時,請注意示範為其附加的適用範圍。這些是固定集合上的治理涵蓋結果,而非開放世界的絕對保證;且它們是確定性的,因此相同的輸入每次執行都會產生相同的決策。

Kestrel 的 Benchmark Results 面板,標記為跨具標籤發布測試夾具集的確定性評估。三個大型圖塊顯示 12 of 12 verified decisions、0 of 6 false blocks 以及 $13.3M exposure avoided,狀態列上方顯示 benchmark complete, 12 of 12 verified。
三個數字,並附帶其適用範圍。 12 of 12 是在包含每項基準真實決策的 12 項具標籤測試夾具集上的閘門準確度。0 of 6 是跨 6 個良性測試夾具的錯誤阻擋數,若此項出錯將瓦解信任。$13.3M 是示範在所有被阻擋與暫緩項目上所模擬的估計避免停機損失,其中 $5,000,000 來自單一 CrowdStrike 級別的阻擋,由螢幕上顯示的公式計算得出。
問題Kestrel 在此示範中所做的事示範範圍之外的事項
閘門準確度在 12 項具標籤測試夾具集上的 12 of 12 項正確決策,包括 6 個良性、數個阻擋與暫緩,以及 1 個誠實棄權。捕捉所有不良更新的通用保證。該結果基於固定集合,而非開放世界。
避免的停機損失全集合估計 $13.3M,其中 $5M 來自被阻擋的 CrowdStrike 級更新,源自螢幕上受影響份額乘以每小時費率再乘以一小時下限的模型。真實客戶節省的資金或保證的回報。這是基於合成測試夾具的合成估算。
沙盒涵蓋範圍跨機群 6 個設定檔中 5 個的確定性個別設定檔結果模型,舊版 Server 2012 主機被標記並排除,而非預設為安全。真實的 Windows 虛擬機器沙盒農場。此處的矩陣是模擬模型,而非運行中的虛擬機器,沙盒農場目前處於產品藍圖中。
整合機制讀取廠商更新頻道饋送並作為測試夾具存根路由至 ITSM 佇列,並以本機 SHA-256 簽署記錄。即時雙向 ITSM、真實廠商饋送與企業 PKI 簽章。這些在示範中皆為模擬整合。

本示範未涵蓋之事項

Kestrel 不是 EDR,亦不與 Falcon、Defender 或 Cortex XDR 競爭。它不會掃描端點、修補漏洞或清除惡意軟體,且絕不需要核心存取權限。沙盒矩陣是確定性的個別設定檔結果模型,而非真實的 Windows 虛擬機器;證據簽章是本機 SHA-256,而非企業 PKI;廠商更新頻道饋送與 ITSM 佇列為測試夾具存根,而非上線連接器。Acme Financial、SentinelEdge 與 Falcon 級代理程式均為虛構,且無任何真實廠商為 Veriprajna 客戶、合作夥伴或背書人。12 of 12 與 0 of 6 是在固定 12 項具標籤測試夾具集上的結果,金額數字為示範本身的估計避免停機模型,而非認證、法律意見或保證回報。真實虛擬機器沙盒農場、即時雙向 ITSM、廠商合約責任稽核、核心形式化驗證與現場嵌入強化均在產品藍圖中,尚未建構。本頁面是包含影片、螢幕截圖、機制剖析與解答的說明展示,而非可從此處直接操作的應用程式。

CISO 在廠商與生產環境之間部署防護層之前所提出的問題。

這難道不是另一套 EDR 嗎?我們已經運行了 CrowdStrike 和 Defender。

不是。Kestrel 不是 EDR,且絕不需要核心存取權限。它位於您的 EDR、DLP、加密及修補代理程式之上的一層,負責治理這些廠商被允許向您的生產機群交付什麼內容。它不會掃描端點、修補漏洞或清除惡意軟體。它讀取廠商提議的更新,證明其是否能安全發布,並透過政策對推出進行閘門管控——這是您所有的核心代理程式都無法為其上層廠商所做的工作。

CrowdStrike 服務中斷是廠商該修復的錯誤。我們在自己這一端究竟能做些什麼?

在 2024 年 7 月 19 日陷入癱瘓的企業並未擁有廠商的流水線,但卻承擔了後果。結構性缺口在於廠商的更新流水線與您的生產端點之間缺乏獨立層級:廠商的驗證器屬於自我審查,SBOM 與 SCA 工具涵蓋的是開源相依性而非專有頻道檔案,而變更諮詢委員會往往直接放行廠商更新。Kestrel 正是這層缺失的防護。它讀取廠商即將推送的實際負載,並在您掌控的程式碼中決定它是否能抵達生產環境。

如果大型語言模型(LLM)參與其中,我該如何信任該判定以用於合規申報?

諮詢團隊僅對更新進行推理。判定是由以純 Python 編寫的確定性驗證器與政策閘門所設定,這是一套監管機構可重新執行的可重複推導算術,因此傾向發布的諮詢代理永遠無法消除關鍵的確定性發現。由於決策是程式碼而非模型的自我報告,相同的輸入每次執行都會產生相同的決策,不具任何模型變異性。該示範亦可透過確定性諮詢備援在無 API 金鑰下完全離線運作,且在該模式下閘門及其判定完全不變。

這樣的閘門難道不會阻擋我們的良好更新並拖慢一切進度嗎?

這是一個閘門,而不是事事阻擋的管家。在示範中,來自同一廠商的良性 Rapid Response Content 更新通過了檢查,並在數秒內發布至 1.2% 的金絲雀環,而危險的更新則被阻擋。在標籤集中的 6 個良性測試夾具上,錯誤阻擋數為 0。Kestrel 僅在危險轉折處果斷出擊,而其無法建模的舊版主機會被標記並排除,而非預設為安全。

在發布決策之後,我實際上要向稽核人員交付什麼?

按一下即可將已簽署的證據記錄匯出為 HTML 檢視與 JSON 檔案,載有 SHA-256 內容雜湊、判定、確定性證明、個別設定檔沙盒結果、附帶模型 ID 的諮詢代理判定、觸發的政策規則,以及附帶每步延遲的逐步評估追蹤。該記錄亦承載歐盟網路韌性法案(EU Cyber Resilience Act)、SEC 揭露以及達美航空先例(Delta-precedent)框架,使其符合申報對話需求。簽章是確保完整性的本機 SHA-256,而非企業 PKI,且該記錄旨在契合這些申報需求,而非作為一項正式認證。

這會將我們鎖定在單一 AI 供應商嗎?它會向外回傳數據(phone home)嗎?

不會。諮詢團隊建構於 Pydantic AI 之上且具備供應商中立性,可透過環境變數選擇 Anthropic、OpenAI 或 Gemini,並可透過本機橋接或 Anthropic API 使用預設的 claude-opus-4-8 模型。它亦可透過確定性諮詢備援在無 API 金鑰的情況下完全離線運作。在每種模式下,確定性驗證器與政策閘門皆保持不變,仍會產生完整的判定與證據記錄,因為保證從來都不是模型的屬性。

技術研究

本示範背後的研究——架構、驗證設計與企業藍圖。

社群媒體

同步發佈於

從您承受不起在未經檢查下進入生產環境的那個廠商更新開始。

我們是 AI 工程團隊,而非中介軟體廠商。我們打造獨立層級,以程式碼決定允許廠商向您的生產機群交付什麼,並將收據存根交到您手中。

一個有價值的初步對話是具體的:您的機群所運行的核心特權代理程式、在無獨立檢查下抵達生產環境的廠商更新路徑,以及您希望強制執行的推出與金絲雀政策。我們可以與您的端點及合規團隊並肩梳理確定性檢查、政策閘門與證據記錄格式。

發布治理評估

  • ✓ 核心特權代理程式清冊
  • ✓ 進入生產環境的廠商更新路徑
  • ✓ 缺乏獨立檢查的環節
  • ✓ 推出與金絲雀政策定義

建構控制平面

  • ✓ 確定性驗證器與政策閘門
  • ✓ 機群落實關聯與沙盒模型
  • ✓ 已簽署證據記錄格式
  • ✓ 適用於您的 ITSM 與饋送的整合接縫