ApexClaw
HomeResources › Incident patterns
RESOURCES

What AI agent incidents keep teaching

Public agent incidents differ in detail and rhyme in structure. Five patterns account for most of them — and every one maps to a control that existed before the incident did.

Get an Agent Trust Gap Brief

The five recurring patterns

1. Excessive agency

The agent could do far more than its task required, and eventually did. Maps to ASI03; answered by least privilege and autonomy budgets.

2. Injection-to-action

Content the agent read became instructions it followed — the classic entry point, dangerous in proportion to permissions held. Maps to ASI01.

3. Cascade amplification

Agent chains trusting each other's output, so one corrupted step propagated. Maps to ASI08; answered by verification at each consequential boundary.

4. Memory poisoning

Injected context that misbehaved long after the injection, defeating point-in-time review. Maps to ASI06.

5. Missing evidence

The incident review that could not establish what the agent actually did — the pattern that turns hours into weeks. Answered by signed, hash-chained execution receipts.

The uncomfortable summary

No public post-mortem describes a failure that required novel controls. They describe absent ones: a gate that was never placed, a permission that was never narrowed, evidence that was never designed. The lesson of the incident record is not that agents are ungovernable — it is that governance arrived after the agent did.

Last verified 2026-08-11. Pattern analysis draws on publicly reported incidents and the OWASP Agentic Top 10 taxonomy; individual organisations are deliberately not named.

No post-mortem describes a failure that required novel controls. They describe absent ones.
Julian Joseph, founder of ApexClaw

By Julian Joseph, Founder, ApexClaw. Written from direct work operating autonomous systems under governance. Reviewed against the claims policy: sourced, first-party, or labelled.