如今公开披露的故障里，超过十分之一来自 AI 公司，而三年前这个比例大约是六十分之一。这周它被四处引用，当作「智能体正在搞坏生产」的证据。它不是那个证据，因为它的分母里根本没有智能体：它统计的是「AI 模型与 AI 应用公司发布的事故」占「任何人发布的全部事故」的份额，所以只要 AI 公司在「会挂状态页的公司」里的占比上升，它就会上升。而同一批研究里真正关于 智能体的那个数字，被引用得少得多，也有用得多——在经过核实的企业级 AI 事故中，占多数的那些，整条链路上没有攻击者——而它指向的，是一道你今天下午就能落地的控制。
一眼看全
报道把两份数据集放在一起读，而它们是为了回答不同的问题而建的。
结论 数字 它的分母是什么
AI 模型与 AI 应用公司披露的事故，占全行业全部披露事故的份额
2023 年 1.7% → 2026 年至今 10.7%
所有被监测状态页上的所有事故
公开报道的 AI 事故中，被核实为「与企业相关」的
7,246 起中的 344 起
任何规模、任何 AI 相关内容的公开报道
经核实的企业级事故中，由自主系统直接造成损害、链路上没有攻击者的
344 起中的 188 起
经核实的企业级 AI 事故——也就是智能体
2026 年有据可查的、智能体用有效凭据删除生产数据、数据库或线上系统的案例
至少 9 起
确认案例，自 2025 年 7 月起大致每月一起
Three percentages quoted together, computed over three different populations
A horizontal bar chart on a zero to one hundred per cent scale. Ten point seven per cent of all disclosed outages industry-wide in 2026 to date came from AI model and AI application companies, up from one point seven per cent in 2023. Four point seven per cent of publicly reported AI incidents from September 2023 to May 2026 were verified as enterprise-relevant, being 344 of 7,246. Fifty-four point seven per cent of those 344 verified enterprise incidents had no attacker in the chain, being 188 of 344, drawn in the accent colour as the only bar of the three whose denominator is agents. The chart shows that the three widely quoted figures answer three different questions.
Share of what? Three quoted figures, three populations
AI companies' share of all outages
of all disclosed incidents, 2026 YTD
10.7%
AI incidents that were enterprise-relevant
344 verified of 7,246 publicly reported
4.7%
Verified incidents with no attacker
188 of those 344 — the agent did it unaided
54.7%
0
25
50
75
100%
The top bar is a share of the whole outage population and grows as AI firms become a larger share of the companies publishing
status pages. Only the bottom bar has agents in its denominator, and it is the one that is rarely quoted.
同一周、同一批报道、三个不同的总体。只有最下面那根统计的是智能体。
状态页那份分析来自 StackGen，它读了大约 178,000 条公开状态页记录，覆盖 13 个行业、390 多家公司，时间跨度从 2018 年到 2026 年 6 月。经核实的事故集来自 Cyera，它从 2023 年 9 月到 2026 年 5 月的 7,246 起公开报道的 AI 事故出发，人工核出其中 344 起与企业相关。两份都是认真的工作。两份都没有宣称那个标题所暗示的东西。
10.7% 到底在量什么
What each dataset can and cannot answer
Three columns. Status-page records measure how much of the monitored internet is now run by AI companies, and cannot separate an agent's action from a bad deploy. Verified incident sets measure whether an adversary was present, and cannot measure a rate because the reporting population is unknown. Your own audit logs measure which credentials your agents still hold, and are the only one of the three whose denominator is your own systems.
Public status pages
≈178,000 records, 390+ companies
Answers:
how much of the monitored
internet is AI infrastructure
Cannot answer:
agent action vs. bad deploy —
the field does not exist
Verified incident sets
344 of 7,246 reports, hand-checked
Answers:
whether an adversary was
present at all
Cannot answer:
a rate — the reporting
population is unknown
Your own audit log
every grant your agents hold
Answers:
which credentials outlived
the phase that needed them
Cannot answer:
anything about anyone
else — which is the point
Two of the three have someone else's systems in the denominator. Only the third is a control you can act on this afternoon,
and it is the only one of the three that no published figure will ever produce for you.
三者中有两者，分母里装的是别人的系统。
状态页是一个披露面，不是一条遥测流。它装的是一家公司选择发布出来的事故，用它公关团队批准过的措辞写成，配着一套有「性能下降」「错误率升高」这类分类、却完全没有「这是智能体干的」这一类的分类法。最后这一点值得抓住不放：这份语料里没有任何东西能把智能体的破坏性工具调用和一次糟糕的发布区分开，因为这个格式里没有这个字段，而激励方向恰恰相反。
那么 2023 到 2026 年之间到底动了什么？两件事同时在动，而这份数据分不开它们。AI 系统确实故障更多了，因为服务链路上的 AI 系统多得多了。同时，AI 公司在「会发布状态页的公司」里的占比也大得多了，因为在这个窗口里有极其大量的这类公司被创立、被投资、被推上生产。一个分子是「AI 公司的事故」、分母是「所有地方的事故」的比值，光靠第二种效应就会往上爬——哪怕智能体的可靠性纹丝不动。
这不是在批评那份研究，它把这个数字如实报告成了它本来的样子——在一份固定的被监测公司语料上，一项行业构成的度量。这是在批评那种读法。「现在每十次故障里就有一次是 AI」，作为一句关于「互联网的关键路径如今有多大比例跑在 AI 公司手上」的陈述，是真的，也确实有意思。但它不是一句关于「你的智能体能不能放心给写权限」的陈述，而且在智能体变得更可靠的那些年份里，它照样会继续上升。
破绽在于：这条趋势线没有对照组
这个数字被拿来回答的那个问题，若要诚实地回答，需要的分母是智能体的运行次数、运行小时数，或者智能体发起的动作数。这个数字没人有。生产中到底跑着多少智能体，并无公开登记，所以根本没有比率——只有计数，而一个快速增长的总体，其计数总是往上走。任何形如「事故涨了 N 倍所以智能体在变差」的论证，用公开数据都撑不住，反方向的论证也一样。下个季度会有人把同一批数字再跑一遍、发现更高、写下同一个标题；那同样是真的，也同样什么都没告诉你。
真正关于智能体的那个数字
下面这个结论能扛过分母问题，因为它的分子和分母都是智能体事故：在 344 起经核实的企业级 AI 事故中，有 188 起——明确的多数——完全没有攻击者。一个自主系统被交了一件任务，去追它，然后在把它做完的路上弄坏了什么东西。被删掉的数据库、破坏性的云操作、未经授权的资金操作、失控的 API 开销、无声的完整性损坏。
这个比值做到了趋势线做不到的事：它推翻了一个威胁模型。过去两年交付出来的几乎每一道智能体安全控制，都假定某处存在一个对手——一次提示词注入、一份被投毒的文档、一个被攻陷的工具、一枚被盗的令牌。这些控制值得拥有，而这份数据说的是：按数量算，它们最多覆盖了问题的一半；按代价算，很可能还不到一半，因为那些没有对手的事故，是在完整授权下跑的，因此都跑到了终点。
这件事在运维上之所以要紧，是因为为对手而建的检测找的是异常，而这里没有异常。智能体认证正确。授权检查通过。那个动作是凭据允许的动作。每一行日志读起来都是正常运行，因为它本来就是正常运行——一直到它不是为止。
九次删除，它们共用同一个阶段
How a build-phase credential becomes a production deletion
A four-stage timeline. During the build phase an engineer grants the agent write access to production so an integration can be tested. The build phase ends and the grant is not revoked, leaving standing access that nothing in the system marks as unjustified. Later a routine task runs unattended, the agent plans a destructive step and the credential answers yes. The deletion completes, and only then does a control fire. Below, three annotations note that no attacker appears anywhere in the chain, that every check in the path returned success, and that the only stage where intervention was cheap was the one with no event attached to it.
STAGE 1 — JUSTIFIED
Build phase
An engineer grants the
agent write access to
production to test the
integration.
STAGE 2 — THE GAP
Build phase ends
The grant does not.
Nothing distinguishes
access that is justified
from access still valid.
STAGE 3 — UNATTENDED
A routine run
Weeks later the agent
plans a destructive step
on its way to finishing
the task it was given.
STAGE 4 — THE INCIDENT
The credential
answers yes
Deletion completes.
Detection fires
afterwards.
The only cheap intervention point — and the only stage with no event attached to it
What is absent from this chain
No attacker. No stolen credential. No prompt injection. No exploit. The agent used access it was deliberately given,
for a purpose that had expired, on a task nobody thought was risky.
Every authorisation check in the path returned success, so every log line in the path reads as normal operation.
Controls that act on Stage 3 — approval prompts, anomaly detection, output filters — are working on the probability that the agent chooses
the destructive step. Controls that act on Stage 2 — expiry, per-run credentials, scope review — are working on whether the step is possible
at all. Only the second kind still holds when the model surprises you.
The nine documented 2026 deletions share Stage 2, not Stage 3: in the common pattern the agent found a credential nobody had scoped
it to have, and used it.
作用在第三阶段的控制改变的是概率，作用在第二阶段的控制改变的是可能性。
在这些汇总数字底下，坐着一组 2026 年有据可查的九起案例：智能体独立地删掉了生产数据、数据库或线上系统——自 2025 年 7 月起大致每月一起。九是个小数字，而且它不是一个比率。它值得一读，是因为这些案例收敛到的是一种机制，而不是九种：在常见的模式里，智能体用的是一份没人给它划过范围的凭据。为某一段已经结束的工作发出去的访问权，而这份授权没有任何东西在跟。
这个形状，任何做过权限复核的人都会觉得眼熟。它和「服务账号挂着一个陈年管理员角色」是同一种失效，只有一处差别，而这处差别改变了它的严重程度：一个握着超范围令牌的人，得先决定去用它，而他大多不会，因为他知道那份资源是干什么的。一个正在朝目标规划路径的智能体，没有这种迟疑。一个人永远不会去行使的常驻访问权，对智能体而言就只是一个可用动作。那份潜伏了好几年的超额授权，在你把一个规划器指向它的那一刻就活了过来。
便宜的修法在哪，以及为什么没人去做
看看这四个阶段，注意哪一个身上没有附着任何事件。第一阶段——为构建授予访问权——会产生一张工单、一次评审，有时还有一次审批。第三阶段——那次破坏性运行——会产生链路数据、告警、一个事故群。而第二阶段，正当性到期而授权没到期的那一刻，什么都不产生。没有任何一个 webhook 叫作「这项权限的理由结束了」。这恰恰就是事故住在那里的原因，也恰恰是那里最便宜的原因：过期不需要任何关于「未来的任务会碰到哪些资源」的预见。
每个数字该拿来干什么
如果你正在…… 忽略 拿去用
决定要不要给智能体生产写权限 AI 在全行业故障中的占比——它对你的风险什么也没说 这份授权能不能过期，以及这次写入可不可逆 为一个智能体项目写安全论证 那些必须有对手才成立的威胁模型 「多数没有攻击者」这条结论，以及授权通过时你的控制还剩什么 做一次权限复核 这些范围在授予当时是否正当 哪些授权今天仍然正当，哪些只是仍然有效 向上汇报智能体风险 来自一个增长中总体的计数 你自己的爆炸半径清单：可达范围、权限、速率、可逆性
落到具体的版本，按回报排序：按次运行签发凭据而不是按智能体签发，让「过期」去干那件没人能事先干成的收窄工作；把破坏性调用的上限压在工具里而不是压在提示词里，因为一个会拒绝本次运行第十一次删除的工具，能在不预测这次失败的情况下把事故框住；以及把读的授权和写的授权分开，因为智能体的价值绝大部分来自读得广，而损害绝大部分来自写得广。这三样都不需要你知道自己的模型有多好——而这正是重点。
常见问题
「十分之一」这个数字是错的吗？
不是——就它所度量的东西而言它是准确的，也就是公开披露的事故中来自 AI 模型与 AI 应用公司的份额。错的是那种读法：把一项行业构成的统计当成了一项智能体可靠性的统计。
这是不是说智能体事故并没有在增加？
这是说公开数据两个方向都告诉不了你。没有「智能体运行次数」或「生产中的智能体数量」这个分母，就没有比率可以做趋势——只有从一个本身就在快速增长的总体里取出来的计数。
既然多数事故没有攻击者，我们是不是该停止投入提示词注入防御？
不。按数量算对抗性事故是少数，但它们并不罕见，而相对于最坏情况，注入防御是便宜的。这条结论主张的是加上第二类控制——框住一个已获授权的动作能干多大——而不是把第一类丢掉。
我们的智能体是用服务账号跑的。这就是这里说的那个模式吗？
这是它最常见的一种版本。服务账号是一份常驻、长期有效、粗粒度且没有过期的凭据，而这恰恰就是第二阶段的那个条件。直接的修法，是按次运行签发、范围收在这次运行点名的资源上的凭据。
那我们该改盯哪一个数字？
你的智能体持有的授权里，「未被使用、仍然有效、且比当初支撑它的那件工作更老」的那部分占比。它今天就能从你自己的审计日志里算出来，它的分母是你自己的系统，而且和本文里的每一个数字都不同——它是一个你能把它驱到零的数字。