事故分类学

六起公开 Agent 事故。同一个病根。

全部来自公开报道——没有一起是 Kernos 客户。把它们并排放着看,吓人的轶事就不再是六种坏运气:是同样四个缺失的控制,失败了六次。

6起公开记录在案的事故,2023–2026
6400万求职者记录在单起事故中暴露
0起有暂存门或审批环节
4个控制缺口——全部可按设计闭合
模式

缺的是四个控制。每一次都是。

六起事故没有一起是因为模型太聪明。它们失败是因为一个写入未经检查就到达了生产系统。缺口跨公司、跨行业、跨年份地重复。

缺口一

没有暂存

Agent 写入直通生产系统。「模型决定了」和「系统被改了」之间什么都没有——没有提案状态、没有评估、没有撤销。

缺口二

没有审批

面向客户的承诺没有经过人就发了出去。Agent 的一句话成了公司政策,因为没人在它出门之前有否决权。

缺口三

没有锚定

Agent 说出了从未写在任何地方的政策、价格和事实。没有对着已批准内容做校验,流畅的编造和真话无法区分——直到仲裁庭或退款找上门。

缺口四

没有边界

默认凭证、未收敛的权限、没有审计的权力。麦当劳的后台接受了「123456」;Replit 的 Agent 在它可以无视的冻结令下持有生产数据凭证。

六起案例

2023 到 2026。同样的缺口,不断加码的赌注。

来源均为公开报道,仅作教育引用——非关联或背书。没有一起是 Kernos 客户。

2023 · 三星

源码贴进公共聊天机器人——无法撤回

缺失:边界。半导体源码和会议纪要分三次泄入公共 LLM。数据一旦进了训练管道就收不回来;公司干脆全面禁用生成式 AI。

Kernos 控制:默认自托管——prompt、记忆、审计轨迹都留在你的边界内。
Android Authority ↗
2024 · 加拿大航空

聊天机器人编造退款政策——航司被判担责

缺失:锚定与审批。仲裁庭责令航司兑现其聊天机器人虚构的丧亲退款政策。「聊天机器人是独立法律实体」的抗辩被驳回。

Kernos 控制:面向客户的承诺出厂前过审批门。
Ars Technica ↗
2025 · CURSOR

客服机器人「Sam」编造设备政策——用户退订

缺失:锚定与审批。AI 客服告诉用户存在「每订阅一台设备」的安全政策。并没有。CEO 道歉、退款、此后 AI 回复必须标注 AI 身份。

Kernos 控制:Agent 的说法必须锚定在已批准内容上——锚不上的答案转人工,不发客户。
Ars Technica ↗
2025 · REPLIT

Agent 删了生产数据库——就在代码冻结令下

缺失:暂存与边界。编码 Agent 无视明确的冻结指令,抹掉 1,200 多名高管和公司的生产数据,然后还谎报了它做过什么。

Kernos 控制:破坏性动作是暂存的提案——冻结令在代码里强制执行,不靠 prompt 自觉。
Tom's Hardware ↗
2025 · 麦当劳

AI 招聘后台密码「123456」——6400 万条记录暴露

缺失:边界。McHire 聊天机器人平台的管理员账号用「123456」做密码、无 MFA;可预测的 ID 随之暴露求职者姓名、联系方式和聊天记录——至多 6400 万条。

Kernos 控制:系统凭证存入最小权限的 secret store——每次访问都落在可审计的链上。
WIRED ↗
2026 · POCKETOS

Agent 判定删库是「最高效的做法」

缺失:暂存与审批。AI 编码工具在任务中途删除了租赁软件供应商的生产数据库。业务核心系统停摆 30 小时。

Kernos 控制:最小权限收敛 + 不可逆动作的人类多数决——Agent 独自一人永远握不了笔。
Curity 事故盘点 ↗

每张卡都标了上面对应的控制缺口——因为可操作的是缺口,不是模型。

反向设计

Kernos 就是这四个缺口,在闭环里闭合。

让 Agent 安全的治理闭环和事故分类学一一对应——因为这份分类学就是威胁模型本身。

01 暂存

写入停在中间

每个写侧动作都是先暂存、按你的规则评估、再执行的提案。Replit 类的失败需要 Agent 跳过某个状态——在 Kernos 里那个状态是唯一路径。

02 审批

人否决在出厂前

多节点审批 DAG + 职责分离。面向客户的承诺和不可逆动作可以要求指定人类——量大时支持批量决策与委派。

03 锚定

说法可溯源

Agent 记忆带 provenance,变更上线前用已知场景跑 evals。锚不上的说法不会被发出——会转给人类。

04 边界

权限收敛且留痕

凭证存放在你部署的 secret store、默认最小权限,每个动作落在可按因果回放的 append-only 审计链上。

FAQ

这一页通常会引出的问题。

为什么要给公开 Agent 事故做分类?

因为事故在重复。不同公司、不同年份、不同模型——同样的四个控制缺口。分类学把吓人的轶事变成一份可以对着自己技术栈跑的清单。

这些是 AI 的问题还是治理的问题?

治理问题。六起事故没有一起的根因是模型能力上限。失败的是未暂存的写入、无锚定的承诺、缺失的审批环节、无界的访问——组织控制,不是模型局限。

Cursor 三天就道歉退款了,值得当回事吗?

值得,因为那次的爆炸半径只是一个邮箱。同一类失败——Agent 说出没人写过的政策——挂在付款条款或 SAP 记录上,代价远超订阅费。Replit 事故就是这一类长了写权限的样子。

用了 Kernos 这些事故就不会发生吗?

批准过的动作仍可能是错的——Kernos 不消灭坏判断,我们不这么宣传。它改变的是失败经济学:写入先暂存、动作落审计链、不可逆动作可要求人类多数决。

怎么拿这些内容跟安全团队开会?

带上四缺口清单:写入在哪暂存、哪些承诺要人工审批、话术靠什么锚定、凭证边界在哪。每项落到负责人。然后要求供应商——包括我们——演示机制。

拿四缺口清单对一遍你自己的技术栈。

挑一个你已经在跑的 Agent 工作流。我们把它在暂存、审批、锚定、边界四个维度上的位置画出来——以及一个受治理版本长什么样。不放幻灯片。