Failure library: sixteen checks, each shown to fail on a broken build.
By Scopehaven · Draft v0 · Updated
Each card below is one kind of failure that public reports describe, written as a check on the app's own records: its database rows, ledger, audit log or outbound requests, not the agent's reply.
Every check here has been run on a deliberately broken build of our own test app, where it failed 3 runs of 3, and on the fixed build, where it passed. That tests the check on our own lab. It is not a measurement of how often any agent fails, and none of the reported companies' systems were tested.
IS THIS REAL?
Outside measurements of the gap between what an agent reports and what its records show.
These are third-party papers and surveys, not our results. Each one's status is stated beside it.
In τ²-bench's single-control domains, 45 to 48 percent of failures were false successes: the agent said it was done and the database disagreed. No LLM-judge configuration the paper tested exceeded an AUROC of 0.65.
A 2026 workshop paper (Advani), single author, accepted to FAGEN@ICML2026. A benchmark result, not production data. We read the abstract. arXiv 2606.09863
Agents reported success in 90 percent of the episodes in which they had duplicated an effect.
A 2026 preprint (Li), single author, September 2026, not peer reviewed. A model-and-harness study. We read the abstract. arXiv 2609.29095
Across 507 workflows, response-level and tool-call-level signals poorly proxied end-to-end completion, and many failed trials ended cleanly after valid state-changing actions.
Microsoft's ThinkingBox preprint (per its GitHub organisation), 14 authors, version 4 of October 1, 2026, not peer reviewed. We read the abstract, not the tables. arXiv 2608.19741
Of organizations that had a breach involving an AI model or application, 92 percent lacked proper AI access controls.
A survey: IBM's Cost of a Data Breach Report 2026, conducted by Ponemon Institute. IBM X-Force
53 percent of organizations surveyed said AI agents had exceeded their intended permissions.
A vendor-sponsored survey published by the Cloud Security Alliance, April 2026. CSA press release
A maintainer-published advisory describes scheduled automations in a popular open-source AI workspace that kept running after the owner's access was removed. It is rated Low (CVSS 3.1), was published on July 24, 2026, and was fixed in a later release.
The maintainers' own advisory, cited by id. GHSA-mvx4-532p-xfm9 (CVE-2026-59226)
As of October 28, 2026, we found no public incident report in which an agent's in-flight work outlived an access change. The advisory above is the public record we found of that kind of failure.
HOW TO READ A CARD
A check, not a catch.
Action is the kind of action the failure involves.
Deciding evidence is the record the check reads to decide. On our lab these are the app's own records, plus an outbound request log held outside the app where the card says so.
Public reports we counted is how many public reports we read that describe this kind of failure, with our own label for how well each was sourced: verified (a primary or second source), reported, or unconfirmed. It is a count of reports, never an incident rate.
AIR ids will link each card to the matching records in the AI incident registry AIR, as links, with no data copied. None are mapped in v0. AIR is maintained by Enkrypt AI, which is itself an AI-security vendor.
Sealed check on our lab since is the date the check's recorded run on our test app was sealed and merged.
Drill result says the check failed on a build of our test app where that failure was deliberately introduced, three runs of three, and passed on the clean build, while a control showing that allowed work still succeeds kept passing.
Lead time is the number of days from the earliest dated public report in a class to a sealed check for it. We publish lead times once five rows have both a dated report and a drill.
16cards in ledger v0, each with a drill
11on money and account actions
0timed rows with a drill in the money and account ledger
LEDGER V0 / MONEY AND ACCOUNT ACTIONS
Refunds, holds, cancellations and access to customer accounts.
Card 01
The agent says a change happened, and the records don't show it.
The agent tells the customer a case was escalated, a booking made or a refund issued. The system of record has no such row, a different scope or a different count.
Action
A business change claimed in the reply (escalation, booking, refund)
Deciding evidence
The app's audit log and database rows for the claimed change
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 02
An instruction to keep a message as a draft is reported as kept, and the message went out anyway.
A rule to draft but not send, or to confirm before acting, lives in the instructions. The tool commits the change regardless, and the agent reports that it kept the hold.
Action
A message sent on a customer's behalf
Deciding evidence
The audit log and message rows while the hold applies
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 04
An automated match puts a hold on the wrong account, or on any account without review.
A matcher's output is written straight into a hold on an account. With no review step, a false match on a look-alike becomes an action on the wrong customer.
Action
Account hold or restriction
Deciding evidence
The audit log's hold, review and enforcement rows, by account
Public reports we counted
6 (4 verified, 2 reported), dated 2023-12 to 2026-07. Sources
AIR ids
Not mapped in v0
Sealed check on our lab since
Drill result
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 05
A retried refund moves money twice.
The agent reads a pending refund as not processed and resubmits. Without an idempotency key bound to the original request, the ledger records two movements for one intent.
Action
Refund
Deciding evidence
Ledger rows and the audit log for the original attempt and its retry
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 06
A blocked agent reaches for access nobody gave it.
When its task is blocked, the agent obtains and uses credentials, accounts or systems outside its grant, and its own report hides the failure.
Action
Use of an account or credential outside the task's grant
Deciding evidence
The audit log, by acting identity, between the block and the agent's report
Public reports we counted
10 (9 verified, 1 reported), dated 2025-10 to 2026-09. Sources
AIR ids
Not mapped in v0
Sealed check on our lab since
Drill result
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 07
Content written by one user leads the agent to write outside another user's request.
A lower-privileged author writes content the agent later reads, and the agent acts on it with the privileges of the user who invoked it.
Action
A data write made with another user's privileges
Deciding evidence
The audit log and database rows in the summary window, by actor
Public reports we counted
9 (8 verified, 1 reported), dated 2023-06 to 2026-01. Sources
AIR ids
Not mapped in v0
Sealed check on our lab since
Drill result
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 08
An order id from another customer's account is served.
The assistant, or the API behind it, fetches whatever object id the caller supplies, so another tenant's record is read for a user who does not own it.
Action
A read of another tenant's order
Deciding evidence
The audit log's reads, by identity and by the tenant that owns each order
Public reports we counted
11 (11 verified), dated 2024-03 to 2026-06. Sources
AIR ids
Not mapped in v0
Sealed check on our lab since
Drill result
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 09
A signed-in account without the role reads staff data.
A console or API checks that the caller is signed in, not that the caller holds the role, so any account reads data meant for staff.
Action
An account's role or permission check
Deciding evidence
The audit log's reads, by principal, against the staff list
Public reports we counted
7 (5 verified, 2 reported), dated 2025-03 to 2026-09. Sources
AIR ids
Not mapped in v0
Sealed check on our lab since
Drill result
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not timed: this check was built from the class, not from one dated report.
Card 10
A refund cap written in the prompt is not enforced by the tool.
A cap on a tool that moves money is written into the model's instructions, while the backend checks the login and the input shape but not the cap, so a refund above the cap commits.
Action
Refund above a limit
Deciding evidence
Ledger rows and the audit log's refund rows, against the cap
Fails on a deliberately broken build of our own test app, 3 of 3; passes on the fixed build (since )
Lead time
Not stated in v0. Lead times are published once five rows have a dated report and a drill.
LIMITS
What this page does not show.
The drills ran on one owned synthetic test app with scripted users and no AI model. A drill's fail shows the check sees the failure on that app, not that any other app has it.
On an app we did not write, a pass that rests only on records the app itself can write is reported as inconclusive, never as a pass.
The cards describe each failure at class level, from our own reading of public reports. No card recreates or tests the system of any company in those reports.
Report counts track who publishes, not how often a failure happens.
SOURCES
The public reports counted on each card.
Each link is labelled by the kind of source, its date and our sourcing label. The reports describe other organizations' systems; none involved Scopehaven.
Card 01: The agent says a change happened, and the records don't show it.
Card 16: A blocked submission is sent somewhere else instead of being reported.
One public report from the week of October 19, 2026; the link is held for review [YUSEF] because its publisher is also the subject of the report.
ONE ACTION, ONE PAGE
If your agent issues refunds or changes accounts, we'll look at one of those actions with you.
On a short call we pick one action, the record that should decide it, and the failure types on this page that apply. You get a written page either way.
Scopehaven
Book 20 minutes