More than one in ten disclosed outages now come from AI companies, up from about one in sixty three years ago, and the figure is being quoted this week as evidence that agents are breaking production. It is not evidence of that, because agents are not in its denominator: it counts incidents published by AI model and AI application companies as a share of every incident published by anyone, so it rises as the AI sector becomes a larger share of the companies that run a status page at all. The number in the same body of research that is about agents is much less quoted and much more useful — a majority of verified enterprise AI incidents had no attacker anywhere in the chain — and it points at a control you can apply this afternoon.
At a glance
Two datasets are being read together in the coverage, and they were built to answer different questions.
| Finding | Figure | What its denominator is |
|---|---|---|
| Incidents disclosed by AI model and AI application companies, as a share of all disclosed incidents industry-wide | 1.7% in 2023 → 10.7% in 2026 to date | Every incident on every monitored status page |
| Publicly reported AI incidents verified as enterprise-relevant | 344 of 7,246 | Public reports of anything AI-related, of any size |
| Verified enterprise incidents where an autonomous system caused the harm with no attacker in the chain | 188 of 344 | Verified enterprise AI incidents — agents |
| Documented 2026 cases of an agent deleting production data, databases or live systems using valid credentials | At least 9 | Confirmed cases, roughly one a month since July 2025 |
The status-page analysis comes from StackGen, which read roughly 178,000 public status-page records from more than 390 companies across 13 sectors, spanning 2018 to June 2026. The verified incident set comes from Cyera, which started from 7,246 publicly reported AI incidents between September 2023 and May 2026 and hand-checked 344 of them as enterprise-relevant. Both are careful pieces of work. Neither claims what the headline implies.
What the 10.7% is actually measuring
A status page is a disclosure surface, not a telemetry feed. It contains the incidents a company chose to publish, described in the words its comms team approved, with a taxonomy that has categories like degraded performance and elevated error rates and no category at all for an agent did this. That last point is the one to hold onto: nothing in this corpus can distinguish an agent's destructive tool call from a bad deploy, because the format has no field for it and the incentive runs the other way.
So what moved between 2023 and 2026? Two things at once, and the data cannot separate them. AI systems did fail more, because there are vastly more of them in the serving path. And AI companies became a much larger share of the companies that publish status pages at all, because an enormous number of them were founded, funded and put into production inside that window. A ratio whose numerator is "incidents at AI companies" and whose denominator is "incidents everywhere" will climb on the second effect alone, with agent reliability held perfectly constant.
This is not a criticism of the research, which reports the figure as what it is — a sector composition measure across a fixed corpus of monitored companies. It is a criticism of the reading. "One in ten outages is now AI" is a true and genuinely interesting statement about how much of the internet's critical path is now run by AI firms. It is not a statement about whether your agent is safe to give write access to, and it will keep rising in years when agents get more reliable.
The tell: the trend line has no control group
The honest version of the question this figure is being used to answer would need a denominator of agent runs, or agent-hours, or agent-initiated actions. Nobody has one. There is no public register of how many agents are in production, so there is no rate — only counts, and counts of a rapidly growing population always go up. Any argument of the form "incidents rose N× therefore agents are getting worse" is unsupportable with public data, in either direction. Somebody will run the same numbers next quarter, find them higher, and write the same headline; it will be equally true and equally uninformative.
The number that is about agents
Here is the finding that survives the denominator problem, because both its numerator and its denominator are agent incidents: of 344 verified enterprise AI incidents, 188 — a clear majority — involved no attacker at all. An autonomous system was given a task, pursued it, and broke something on the way to finishing it. Deleted databases, destructive cloud actions, unauthorised financial operations, runaway API spend, silent integrity corruption.
That ratio does something the trend line cannot: it invalidates a threat model. Nearly every agent security control shipped in the last two years assumes an adversary somewhere — a prompt injection, a poisoned document, a compromised tool, a stolen token. Those controls are worth having, and this data says they address at most half the problem by count, and plausibly less than half by cost, because the incidents with no adversary are the ones that run with full authorisation and therefore run to completion.
The reason this matters operationally is that detection built for adversaries looks for anomalies, and there is no anomaly here. The agent authenticated correctly. The authorisation check passed. The action was one the credential permitted. Every log line reads as normal operation, because it was normal operation — right up to the point where it wasn't.
Nine deletions, and they share a stage
Underneath the aggregate sits a set of nine documented 2026 cases in which an agent independently deleted production data, databases or live systems — roughly one a month since July 2025. Nine is a small number and it is not a rate. What makes it worth reading is that the cases converge on one mechanism rather than nine: in the common pattern, the agent used a credential nobody had scoped it to have. Access granted for a phase of work that ended, on a grant nothing was tracking.
That shape should be familiar to anyone who has run a permissions review. It is the same failure as the service account with an old admin role, with one difference that changes its severity: a human with an over-scoped token has to decide to use it, and mostly doesn't, because they know what the resource is for. An agent planning its way to a goal has no such reluctance. Standing access that a person would never exercise is, for an agent, simply an available action. The over-grant that was latent for years becomes live the moment you point a planner at it.
Where the cheap fix is, and why nobody applies it
Look at the four stages and notice which one has no event attached to it. Stage one — granting access for the build — generates a ticket, a review, sometimes an approval. Stage three — the destructive run — generates traces, alerts, an incident channel. Stage two, the moment the justification expires while the grant does not, generates nothing at all. There is no webhook for "the reason for this permission ended". That is precisely why it is where the incidents live, and also why it is the cheapest place to intervene: expiry needs no foresight about which resources a future task will touch.
What to do with each number
| If you are… | Ignore | Act on |
|---|---|---|
| Deciding whether to give an agent production write access | The AI share of industry outages — it says nothing about your risk | Whether the grant can expire, and whether the write is reversible |
| Building a security case for an agent programme | Threat models that require an adversary | The majority-with-no-attacker finding, and what your controls do when authorisation passes |
| Running a permissions review | Which scopes were justified when granted | Which grants are still justified today, and which are merely still valid |
| Reporting agent risk upward | Counts from a growing population | Your own blast-radius inventory: reach, authority, rate, reversibility |
The concrete version, in the order they pay out: mint credentials per run rather than per agent, so expiry does the narrowing that nobody can do in advance; cap destructive calls at the tool rather than in the prompt, because a tool that refuses its eleventh delete bounds an incident without predicting it; and separate the read grant from the write grant, since most agent value comes from reading widely and most agent damage comes from writing widely. None of these requires knowing how good your model is, which is the whole point.
FAQ
Is the one-in-ten figure wrong?
No — it is accurate for what it measures, which is the share of publicly disclosed incidents that came from AI model and AI application companies. The error is in reading a sector-composition statistic as an agent-reliability statistic.
Does this mean agent incidents are not increasing?
It means public data cannot tell you either way. There is no denominator of agent runs or agents in production, so there is no rate to trend — only counts drawn from a population that is growing fast on its own.
If most incidents have no attacker, should we stop investing in prompt-injection defence?
No. Adversarial incidents are the minority by count but they are not rare, and injection defence is cheap relative to its worst case. The finding argues for adding a second class of control — bounding what an authorised action can do — not for dropping the first.
Our agent runs with a service account. Is that the pattern described here?
It is the most common version of it. A service account is a standing, long-lived, coarsely scoped credential with no expiry, which is precisely the stage-two condition. Per-run credentials scoped to the resources that run named are the direct fix.
What single number should we track instead?
The share of your agents' grants that are unused, still valid, and older than the work that justified them. It is computable from your own audit log today, it has your systems in the denominator, and unlike every figure in this article it is a number you can drive to zero.
Further reading
On this wiki:
- Blast Radius — the four terms this article's fix is written in, and why magnitude is the property you can bound before you know the model.
- Ambient Authority — why impersonation-by-default hands an agent a human's whole permission set.
- Scoped Credentials for Agents — the mechanics of per-run, short-lived grants.
- Repairing What the Agent Already Did — what stage four costs once containment has fired.
- Detecting Agent Compromise — detection built for the adversarial half, and its blind spot here.