端點更新的獨立發布保證
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 如何處理每一次更新。




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

| 問題 | 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、廠商合約責任稽核、核心形式化驗證與現場嵌入強化均在產品藍圖中,尚未建構。本頁面是包含影片、螢幕截圖、機制剖析與解答的說明展示,而非可從此處直接操作的應用程式。
不是。Kestrel 不是 EDR,且絕不需要核心存取權限。它位於您的 EDR、DLP、加密及修補代理程式之上的一層,負責治理這些廠商被允許向您的生產機群交付什麼內容。它不會掃描端點、修補漏洞或清除惡意軟體。它讀取廠商提議的更新,證明其是否能安全發布,並透過政策對推出進行閘門管控——這是您所有的核心代理程式都無法為其上層廠商所做的工作。
在 2024 年 7 月 19 日陷入癱瘓的企業並未擁有廠商的流水線,但卻承擔了後果。結構性缺口在於廠商的更新流水線與您的生產端點之間缺乏獨立層級:廠商的驗證器屬於自我審查,SBOM 與 SCA 工具涵蓋的是開源相依性而非專有頻道檔案,而變更諮詢委員會往往直接放行廠商更新。Kestrel 正是這層缺失的防護。它讀取廠商即將推送的實際負載,並在您掌控的程式碼中決定它是否能抵達生產環境。
諮詢團隊僅對更新進行推理。判定是由以純 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,且該記錄旨在契合這些申報需求,而非作為一項正式認證。
不會。諮詢團隊建構於 Pydantic AI 之上且具備供應商中立性,可透過環境變數選擇 Anthropic、OpenAI 或 Gemini,並可透過本機橋接或 Anthropic API 使用預設的 claude-opus-4-8 模型。它亦可透過確定性諮詢備援在無 API 金鑰的情況下完全離線運作。在每種模式下,確定性驗證器與政策閘門皆保持不變,仍會產生完整的判定與證據記錄,因為保證從來都不是模型的屬性。
本示範背後的研究——架構、驗證設計與企業藍圖。
我們是 AI 工程團隊,而非中介軟體廠商。我們打造獨立層級,以程式碼決定允許廠商向您的生產機群交付什麼,並將收據存根交到您手中。
一個有價值的初步對話是具體的:您的機群所運行的核心特權代理程式、在無獨立檢查下抵達生產環境的廠商更新路徑,以及您希望強制執行的推出與金絲雀政策。我們可以與您的端點及合規團隊並肩梳理確定性檢查、政策閘門與證據記錄格式。