AgentRiders. Join the Guild

The Record / Burns

Burns

When an AI agent run loses money, data or time, riders call it a burn. This registry is a curated list of named failure patterns. Each page gives the signals, the first ten minutes, the recovery, and the permissions, budgets and kill switches that prevent it, labeled logged or illustrative. Counts and rates wait for enough logged burns.

By · Published · Updated

A kill script that matched the agent’s own shell. An admin allowlist that would have locked out its own admin. A green test run with an IDOR behind it. Three burns, one flight, logged. This is where burns get names.

Which AI agent failures count as burns?

A burn is an AI agent run that lost money, data or time (glossary): a failure or incident with a cost attached. A duplicate write, a leaked credential, an hour of review on work that said it was done. The burns chapter logs the cost in three parts: direct charges, lost work, recovery time. Unknown stays unknown, never zero.

How does the registry of AI agent failure modes work?

The registry is a curated list of named failure patterns. Each gets one page: how you know, the first ten minutes, the recovery, and the reins that prevent it. Each carries one of two labels. Logged means a published flight log records the burn, quoted as the rider wrote it. Illustrative means the example is drawn from the Field Manual or Flight School, like the doubled import in When an agent fails, and the page says so. Logged examples accrue from published flight logs; the first come from Shipped AgentRiders Phase 2. No counts, rates or costs by pattern until enough burns are logged, per how we count. An illustrative page is a definition, never data.

How do you file an AI agent incident report?

An incident is filed as a burn inside a flight log. First stop the loss. The first-ten-minutes checklist carries the Burns chapter protocol on one page: contain, establish the facts, choose the smallest recovery. Then fill the burn report while the evidence is fresh. When the flight is over, log it in the composer: what happened, how you recovered, what it cost, and a pattern from this registry. The registry grows from what riders file, not from what we guess.

Questions riders ask about AI agent failure modes

All three turn on one distinction: a burn is a cost on the record, not a verdict on the flight or the mount.

Is a burn the same as an aborted run? No. Outcome and burns are logged separately. A flight can land with burns, as the first logged one did, and an aborted flight can carry none.

Why no counts or rates? A rate from one rider, one repo and one billing method is noise with a decimal point. Numbers appear when enough burns are logged by enough riders, with the method stated.

Does a burn ground the mount? Not always. Grounded means pulled from real work until the rein that let the burn through is refitted: a scope the harness enforces, a spend cap instead of an alert, a kill switch you have fired. Log a near miss too. Resuming is a separate decision from recovering.

Every pattern in the registry

  • false-negative test suite (security gap behind passing tests) Logged

    A false-negative test suite is a green test run that never checks the property that matters, so agent-written code passes every test and is still unsafe to ship. In the one logged case, 38 passing tests missed an IDOR and a stored XSS; an adversarial review before merge caught both, at a logged recovery cost of $0.

  • self-terminating stop mechanism (kill pattern too broad) Logged

    An agent’s stop mechanism can terminate the agent itself when the kill command matches by process-name pattern and the invoking shell’s own command line contains that pattern. The run stalls instead of stopping cleanly. In the logged example the kill script killed the agent’s shell with exit 144; the fix ran the kill from a file and by port.

  • wrong principal (identity misconfiguration) Logged

    A wrong-principal burn is an identity misconfiguration: an agent builds an access rule for an identity that does not match the real account, so the right person is refused. In the one logged case, an admin allowlist was hardcoded to the handle max while the owner had claimed @maxcr; corrected on the branch before merge, logged cost $0.

  • false completion report Illustrative

    A false completion report is a closing message that says the task is done when the evidence does not support it: the artifact is missing, partial, or never checked. Riders call it a confident closing message. No flight has logged this pattern yet; the example here is illustrative. The fix is a check the agent does not control.

  • false isolation boundary Illustrative

    A false isolation boundary is the burn where a git branch or worktree is treated as a sandbox for an AI agent while the process keeps its filesystem, network and credentials. Riders call it branch-is-not-a-sandbox. The branch separates diffs for review; it stops no read, request or push. No flight has logged it yet; the example is illustrative.

  • monitoring mistaken for enforcement Illustrative

    Monitoring mistaken for enforcement is the burn where a spend alert fires and nothing stops the AI agent: the threshold reports the cost; the run keeps going. Riders say an alert is not a rein; the registry files it as alert-is-not-a-cap. No flight has logged it; the example is illustrative. The fix is a cap that refuses the next request.

  • non-idempotent retry Illustrative

    A duplicate write after a timeout is an AI agent failure, a non-idempotent retry: a write times out, the agent reads the silence as a failed call and retries, and the destination, which accepted the first request, now holds every record twice. No flight has logged it yet; the example is illustrative. The fix is a destination check before retrying.

  • prompt injection via data Illustrative

    Prompt injection via data is the AI agent failure where retrieved text, a file, an email or a web page, is followed as instructions. The agent’s mandate never changed; it acted as if it had. Riders call it data-treated-as-orders. No flight has logged it yet; the examples are illustrative. The fix is a harness that limits what reading can cause.

  • incident response checklist for an AI agent Checklist

    When an AI agent fails, the first ten minutes are for regaining control, not explaining. Minutes zero to two: stop the run and remove access that can still do harm. Minutes two to five: write an incident note separating confirmed facts from unknowns. Minutes five to ten: choose the smallest recovery that restores the intended state without new damage.