同一家供应商，两次更新，记录在案的两种不同决策。
本演示治理一个合成终端集群 Acme Financial: Global Endpoint Fleet，涵盖 6 种操作系统配置集和 8 个特权代理（其中 5 个处于 ring-0 级别）下的 8,500 台终端。供应商 SentinelEdge 推送两次 Rapid Response Content 更新。观察 Kestrel 如何分别处理它们。
面向终端更新的独立发布保障
Kestrel 是一个位于软件供应商与您的生产终端集群之间的独立控制平面。它在供应商更新到达任何终端之前将其拦截，以确定性方式证实 CrowdStrike 级别的故障特征，通过顾问模型无法推翻的策略对发布进行把关，并导出董事会和监管机构可重新运行的经签名证据记录。您在此处观看的是基于合成的 8,500 台终端集群的演示，而非已实际部署的生产流水线。
20 → 21
导致终端集群崩溃的字段数量不匹配
CrowdStrike 根因分析，2024年8月 RCA
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 根因分析，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，默认模型为通过本地桥接或 Anthropic API 访问的 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 先例的框架，便于融入合规申报沟通。此签名是用于保障完整性的本地 SHA-256，而非企业级 PKI，该记录旨在满足这些合规申报需求，本身并非一项法定认证。
不会。顾问团队基于 Pydantic AI 构建，且不绑定特定模型供应商，可通过环境变量自由选用 Anthropic、OpenAI 或 Gemini，默认模型为通过本地桥接或 Anthropic API 访问的 claude-opus-4-8。它还支持通过确定性顾问后备方案在无需 API 密钥的情况下完全离线运行。在所有模式下，确定性核验器与策略闸门均保持不变，且依然生成完整的裁决与证据记录，因为安全保证从来就不是大模型本身的属性。
我们是一支 AI 工程团队，而非中间件供应商。我们构建在代码层面裁决供应商获准向您的生产终端集群推送何种内容的独立隔离层，并为您提供审计凭证。
首次有成效的沟通是具体的：您的终端集群运行的内核特权代理、未经独立审查便直达生产环境的供应商更新路径，以及您希望执行的发布与金丝雀策略。我们可以与您的终端和合规团队并肩协作，梳理确定性检查、策略闸门以及证据记录格式。
