Every way your agent fails, and what catches it. Six published registers of named failure modes, each graded by what prevents it, what detects it, and what is left to you to manage.
ON THIS PAGE
01 Why this framework is necessary02 Who this is for03 Why agent failures never improve on their own04 Trust is in fact six questions05 What a register row actually is06 The six questions, register by register07 Evidence vs prediction08 The vocabulary, in one minute09 What you can actually do with this10 Related work11 Are the framework's recommendations new?AT A GLANCE
67
EVIDENCED FAILURE MODES
61
PUBLISHED CANDIDATES
43
ROWS THAT FALL TO A PERSON
6
REGISTERS PUBLISHED
STILL IN DERIVATION
A SEVENTH REGISTER, EXECUTION AND CAPABILITY
THE SHORT ANSWER
Whether an AI agent's work can be trusted is settled by six questions: what it may reach, what it knew, which rules governed it, whether the work held up, whether the account of it holds, and whether failure can be reversed.
The goal for agents is to be something you can hand a job to, the way you hand a job to a person.
But if we want agents to be employees then they need to behave like an employee: a worker inside an institution, bound by a code of conduct, covered by controls, accountable in ways both sides understand.
If you can trust an agent to work like an employee, with a basic level of intuition about how the world works, then you've got an effectively limitless army of employees at your call. Without it, you are just creating for yourself a mountain of rework.
The essay this framework grew out of asks why the smartest worker you have ever hired keeps failing tests a school leaver would pass – and what the medieval court, which kept a fool on the payroll for exactly this duality, knew about putting a genius you cannot trust to work: read the essay.
In this situation, delegation becomes a pricing decision. When you hand work to a person, you are pricing their failure: you know roughly what shape it will take, how often it will arrive, and what it will cost, because you have spent your whole life among humans who fail in human ways.
Agents fail in mostly familiar shapes, but with some major differences. They fail at machine speed – almost instantly, and potentially at scale. They don't quietly self-correct when they fail like humans do, which means they can easily repeat mistakes. And they describe failed work as confidently as successful work, which makes it very hard to tell when they have stuffed up.
This is a major blocker for companies wanting to use agents. A manager who cannot predict the way a worker will fail cannot delegate to that worker, whatever the worker's talent.
The False Floors methodology exists to fix that: name the failure shapes one by one, and grade each one by the measures you can take to prevent it.
A false floor is a board you put weight on because you believed something was holding it up – and nothing was. False by construction, never by fraud – nobody built the hollow board to deceive you. It looks solid from above because the finish of a board tells you nothing about the support beneath it. You find the hollow point by standing on it.
Three words carry the metaphor, and they mean the same thing on every page of this framework. The floor is your business: the accumulated work everyone stands on, laid board by board – by people, and now by agents. A board is one unit of work you put weight on: a report you act on, a fix you ship, a number you quote. The support under a board is whatever holds it up: the worker's competence at that task, and the control that is supposed to catch its absence. A board can be hollow from either side – the competence was never there, or the thing that was supposed to catch the failure was itself the failure: the permission setting that was switched on but never applied, the backup running on a cadence too wide to catch the loss it exists to catch, the CI check that was blind from the day it was written.
A false floor is still narrower than "a failure". Work that is visibly bad is not a false floor – you never put weight on it. The false floor is the subset you stepped on because everything you could see said it would hold.
The False Floors methodology names these failures in a set of registers – one register per question you need answered. Each register is a survey of one part of the floor, board by board. The rows of the register show which boards hold, which are hollow, and the consequences of falling through that part of the floor.
You can use the framework to increase the level of confidence in your agents so that you can employ them throughout your business. A company that solves the trust problem is able to hire digital employees the way they once hired graduate intakes – at volume, with confidence, and early. The company will enjoy the leap in productivity that AI promises.
A company that fails to find a way to trust agents will adopt anyway, but slowly, with every rollout shadowed by mistrust. The company will wonder what their competitors are doing differently as they watch them leap ahead.
The gap between those two companies is not a technology gap. It is a trust gap. You can build up that trust by implementing a growing range of settings, tools and processes that prevent or detect many of these failures. This is how you shore up trust in agents to where you feel comfortable relying on them as you would your employees.
False Floors shows you the failures that undermine trust, and what you need to do to avoid them.
The framework assumes a developer's stack. It does not assume you are a developer. The mechanisms live in hooks, a repository, a CI pipeline and a schema, because that is where the controls exist. Using them needs no engineering background.
Some rows here will be obvious to you. A row that is already second nature is a row you have closed.
Developers, junior or working outside their own domains. The failures cross database grants, git internals, CI, shell, credentials and backup cadence. Nobody holds all six at once, and an agent touches all six in an afternoon.
Non-developers building with agents. If an agent is writing your software, the failure modes are yours whether or not the code is.
Business analysts and other business users. The same rows harden a process and an application stack, not just a codebase. Most of the context register is filing discipline rather than engineering.
CIOs, heads of AI, and anyone who has to sign off on agent work. You need the exposure at register level, not the row detail. Start with the free board briefing, What a board should ask about its AI agents – two costable questions and the mechanism underneath them. It needs none of the material on this page to be useful.
If you run a second brain – a knowledge base your agents read from and write to – that is the environment these registers were derived in. The context and provenance registers apply to it almost line for line, and the cheapest wins on both are in how your notes are dated, sourced and filed rather than in anything you install.
Interviews, registers and essays. Free.
As with humans, you cannot predict which tasks an agent will fail at. But with agents, the same failure returns unchanged.
Almost none of these failure modes is new. Run the rows against a human workforce and the great majority are things people have always done: quoting the price that changed in March, following the SOP you retired last quarter, deleting the wrong folder. Your organisation has routines for handling those failures, and most of them transfer to agents intact.
The layer underneath those routines does not transfer – nobody wrote it down because nobody had to. Every failure a person makes comes with its own quiet, human repair, and each register maps to a different one.
CONTEXT
Did your agent know what it needed to know?
Memory. Being caught quoting a stale figure fixes the correction in place, attached to the discomfort of having been wrong in front of somebody.
No memory between sessions. The apology goes nowhere.
INSTRUCTION
Did your agent do what it was told?
Stake. People follow most rules because somebody will notice, and they don't want to be seen as a rule breaker.
Nothing to lose, and nobody it minds disappointing.
RECOVERY
Can you get it back?
Fear. One bad afternoon installs a flinch: you commit before the risky step and read the path twice before you press enter.
No experience to flinch from. It runs a destructive command with the confidence it brings to listing a directory.
PROVENANCE
Can you trust the record of what your agent did?
Testimony. The record is a convenience; you can ask the person who did the work.
There's nobody to ask. Asking the agent produces a fluent account that may or may not be true.
TRUTH
Can you trust what your agent says about its work?
Motive. People misreport deliberately, so there is a story that stops hanging together and a person who hesitates.
An agent is sincerely wrong: it believes its own account, so there is no story to pick apart and nobody to press.
AUTHORITY AND ACCESS
What could your agent reach?
Nothing – because none was ever needed. Access is the one thing organisations already control formally: what a person can reach is decided, granted and listed before they start.
That control rests on somebody knowing what was granted. An agent can run with your permissions, and nobody has listed what that includes.
None of those repairs is a control anybody budgeted for when it comes to agent employees. These social behaviours are why a badly documented organisation still works. All of them disappear the moment you hand work to an agent.
This is why failures for agents have to be written down one by one rather than absorbed: whatever replaces that layer has to be built – a setting, a gate, a check, or a decision a named person owns.
Whether an AI agent's work can be trusted is settled by six questions:
What could your agent reach? – Authority and Access. The unit is a permission.
Did your agent know what it needed to know? – Context. The unit is a fact.
Did your agent do what it was told? – Instruction. The unit is a rule.
Did your agent's work hold up? – Execution and Capability. The unit is an assessment.
Can you trust your agent's account of its work? – Evidence, answered by two registers: Truth (its claims about the work) and Provenance (the record of the work).
Can you get it back? – Recovery. The unit is a change.
Six questions govern trust; seven registers diagnose it – six are published, the seventh is in calibration. The two counts are not the same six. Evidence is one question a leader has to answer once, and two registers that fail independently: a record can be immaculate about work that was misreported, and a correct result can be untraceable. So the questions group by the decision you have to make, and the registers split by the mechanism that fails. Each register is a list of named failure modes, and every mode is graded by what the strongest available mechanism does with it – prevented, detected or survives.
Six of the seven registers behind these questions are published today. They hold 67 evidenced failure modes – rows backed by a recorded incident or an independently coded finding – plus 61 candidates: failure modes named in advance that are still waiting for their first receipt. Only evidenced rows are counted in any headline on these pages; candidates are labelled on the row.
The register behind Execution and Capability is specified and its rows are still being derived. We will publish once we have enough evidenced rows to warrant it.
The registers are re-verified against a live production repository, and this page is updated as rows are derived, counts move, and external cases test the framework.
Here is one row in full, from the Instruction register:
IL-3A. Symptom: "did it anyway, with a justification."
Failure: a prohibition was read as a preference.
Catch point: CI – the grep gate finds weak wording, not the reading.
Mechanism: never/always wording, backed by a check.
Outcome: survives – nothing catches it every time.
Gap: open.
Cadence: at every rule change – reserve hard language for what matters.
The Authority register question: what could it reach? The unit is a permission.
The finding: of 23 boundaries, 11 are enforced somewhere the agent cannot reach; the other 12 rest on a file, a habit, or a login it can edit. The register carries 16 evidenced rows and seven candidates – the highest evidenced share of the six, because its rows were read from a live security register in the first place. Every boundary is either bypassable or unbypassable. These failures can't be detected once the session is running. Authority is settled before the agent starts, or discovered after it has finished.
→ More on the Authority register: what can an AI agent actually access?
The Context register question: did it know what it needed to know? The unit is a fact.
The finding: an agent cannot tell the difference between knowing something and generating something, so nothing here can be refused – and yet 11 of 22 context failures are catchable before the session even starts, which means half of this register is governable on disk, before any agent runs. The register carries 12 evidenced rows and 10 candidates.
→ More on the Context register: did the agent know what it needed to know?
The Instruction register question: did it do what it was told? The unit is a rule.
The finding: of 22 ways a rule fails, only two can be refused outright, and eight cannot be closed by anything available. Two of those eight sit at the understood stage – was the rule read as it was meant? – and can only be contained by human judgement. The register carries eight evidenced rows and 14 candidates.
Sometimes the instruction was ambiguous: the agent did something defensible that you did not want (IL-3C). Or a prohibition was read as a preference: it did the thing anyway, with a justification – including the case where you named one example and it fixed the case you named rather than the class it stood for (IL-3A). A rule without a check is a wish.
→ More on the Instruction register: why does your agent ignore its instructions?
The Execution and Capability register. The register's canonical question: for a declared unit of work, which required properties of the produced behaviour or available capability were violated or absent, and what was observed? The unit is an execution-property assessment.
The failure modes for this register are still being derived, and no count, no defining finding and no dedicated page exists yet.
Evidence is one question answered by two registers, and neither can stand in for the other.
The Truth register asks: can its claims about its own work be trusted? The unit is a claim. Its defining finding: an agent that ran the test suite and an agent that says it ran the test suite write the identical sentence. The difference is never in the writing, only in whether the output was committed. The register carries eight evidenced claims and seven candidates.
The Provenance register asks: is the record of what was done trustworthy? The unit is a unit of work. Its defining finding: only the harness gate can refuse before the record is wrong – and it cannot catch its own absence. Every register after it reports on something that has already happened. The register carries 12 evidenced rows and 10 candidates.
An agent can be perfectly honest and leave no usable trace, and it can leave an immaculate trace of work it misreported. So the rule is never averaged: Evidence passes only when both pass. Strong traceability never offsets weak verification.
→ More on the Truth register: can the agent's claims about its own work be trusted?
→ More on the Provenance register: the record that travels with the code.
The Recovery register question: can you get it back? The unit is a change.
The finding: of 24 ways a change escapes you, nine are irreversible. And four of those nine are simply decisions nobody wrote down: what a restore point covers, who calls the rollback, how one action is waived without waiving a session, and what an at-risk checkout needs beyond a fixed-cadence backup. Recovery class is a property of the mechanism, not of the change. Writing a rollback plan changes how often you need it, never whether you can get back. The register carries 11 evidenced rows and 13 candidates.
→ More on the Recovery register: undoing what the agent did.
Across the six populated registers, real failures have been recorded against 67 evidenced rows, plus 61 candidates: named in advance, labelled on the row, and still waiting for a first receipt.
A candidate is promoted to evidenced when its first receipt arrives, and retired if a full review of the registers passes with no evidence arriving. Candidates are counted in no headline.
When graded by remedy across all 128 published rows, 12 can be prevented outright, 73 can be detected every time by a mechanism, and 43 fall to a person. Remedy and evidence are separate gradings.
Two caveats. The seventh register, Execution and Capability, has not been published and its provisional rows aren't included in the framework's total count of 128 rows. And the counts are grounded in one harness and one production repo, with one register still at design stage.
This is a live project. Emerging tools may address one or more failure modes, the vendors themselves may add settings that do the same, and processes may become more effective at verification and assurance.
This project will continue to update the registers with the latest solutions for each failure mode. Sign up using the form on this page for major quarterly updates.
Every register grades its rows A, B or C. The letter means the same thing everywhere: how complete the available remedy is. One register reads those letters with different words, so treat the words as local to each register and the letter as universal.
Five registers read them as prevented (A), detected (B) and survives (C) – Instruction, Context, Authority and Access, Provenance, and Truth.
Recovery reads them as prevented (A), recoverable (B) and irreversible (C), because that register measures whether you can get a change back rather than whether a check fires on it.
Class C:
Survives – nothing catches it every time, so it reaches you.
Irreversible (Recovery only) – nothing gets it back.
Counts that span registers are therefore stated in letters, not in any one register's words. When you see "43 rows fall to a person", that is Class C across six registers, not 43 things that "survive".
A register is the enumerated list of failure modes behind one question; it has rows, each carrying an ID like CL-2A. A domain groups registers – there are six domains and seven registers, six of them populated, because Evidence is one domain answered by two registers that cannot substitute for each other.
The full vocabulary – including how this maps to the terms your auditors already use, and the three things across the framework we have not yet reconciled – is on the methodology page.
Three things, in ascending order of effort. The first two cost nothing and neither requires you to accept any of the arguments above.
1. Find out which of these are already true of your setup. The free trust-check tool takes about 30 seconds, needs no signup, and returns a personalised gap list: which rows a mechanism already closes for you, which are open, and which are waiting on a decision nobody has made. It does not assess execution and capability, and a clean result does not mean the work is correct.
2. Read the register for whichever question worries you most, and install from the bottom of the page. Each of the six register pages ends with an install list – the specific settings, hooks, gates and checks that close the rows above it, in the order they pay off. Several take 10 minutes to install. Most of the rest you can add in an afternoon. Start with Authority if you have never listed what your agent can actually reach, and with Context if your agents read from and write to a knowledge base.
3. Make the decisions the registers cannot make for you. A minority of rows close with no setting at all. These require a decision by a human: what a restore point covers, who calls the rollback, how one action is waived without waiving a whole session, which facts have to carry an effective date. Write the answers down somewhere the agent reads them, which converts a judgement into something a check can enforce.
The registers were derived on one stack: an agent with hooks, a git repository, plain-text notes carrying a schema, and a CI pipeline. The failures are identical elsewhere – a stale price is a stale price – but the mechanisms are not.
A required column stands in for a frontmatter field, a retention label for a review date, a search scope for an excluded folder. Roughly two thirds of a register maps across that way; a minority of rows are repo-native and have no clean equivalent. Those mappings are not published here. Enterprise mapping is available on request.
The premise underneath the whole build is that a non-programmer can direct a team of agents to produce software that holds up, provided the failure modes are named and the checks are installed at the points that catch them. If that is what you are trying to do – analysts specifying and directing, rather than engineers implementing – get in touch.
Want the six registers mapped against Microsoft Copilot in your environment? Get in touch.
Much of the demand for this framework comes from governance: the registers give a decision-maker the failure list and its grades – what could go wrong, what catches it, and what remains a judgement. The reports package that material for specific decisions.
Here are three of them. The full list is in the reports index.
Board reports. "Can you sign off on agent-built software?" discusses who signs off on agent-built software, what evidence a sign-off can stand on, and which risks a board is accepting on judgement alone because no automatic check covers them. Answers across all six registers and adds the delegation frontier (the line between the work you can hand to an agent and the work that still needs a person). A dated edition, refreshed as the rows move. Paid.
Product reviews. The registers can measure the usefulness of a product in enforcing governance. This report reviews Lovelace, a lightweight task-management tool designed to be used with agents, against the six published registers in the False Floors framework. It includes a section registering the reviewer's own wrong claims, made earlier in the same session and corrected on reading the code. Free.
Platform profiles. This review looks at how one named platform – Anthropic's Claude – performs against every row in all six registers. It shows what Claude supplies automatically, what it exposes as a setting, what it leaves to you, and what it cannot reach at all. (For a Microsoft Copilot profile, please get in touch.) Free.
Ahead of any of them, a free board briefing – What a board should ask about its AI agents – carries the two costable questions a board should put to its engineering team, and the mechanism underneath them. It needs none of the material above to be useful.
“STAR tells you the agent is secured; False Floors tells you whether its work can be trusted.”
The False Floors framework sits in a category of research that assesses the performance or characteristics of agents. Below are the related frameworks in AI security that cover agents, and the crossover points with each.
Governance and security frameworks – AI Controls Matrix and STAR for AI. The AI Controls Matrix is a vendor-neutral, open-source security and governance framework created by the Cloud Security Alliance to secure, audit and manage cloud-based artificial intelligence and generative AI systems.
Its Agentic Supplement governs identity and authorisation, runtime behaviour governance, and tool permission governance, and the Agentic scheme assesses a specific deployed agent system against them.
False Floors' Authority and Access register covers the same ground at row depth: where a control objective says a boundary must be enforced, an Authority row names one specific way that boundary fails in a working setup. The intent is to publish that as a crosswalk in CSA's vocabulary.
Security failure lists – OWASP, MITRE ATT&CK and CWE. These lists grow by observation: an entry earns its place with evidence of a real risk or failure, not by sounding plausible. That inclusion rule is the crossover – False Floors borrows it directly. The one departure: rows named in advance are kept and labelled as candidates rather than deleted, and the rate at which they come true is published as a scoreboard.
Software production frameworks – NIST AI RMF, ISO/IEC 42001, ISO/IEC 5338 and NIST SSDF. These govern at the level of an organisation's management system and its software lifecycle. The registers assume you have satisfied them, and ask what still goes wrong on a Tuesday afternoon, inside one session, on one machine.
Every framework above answers a question about whether the agent was attacked, subverted, or let out of bounds. None of them answers the question a CIO faces after the pilot: nothing attacked the agent and it never went rogue – so why can't we trust its work enough to sign it off and hand it more?
An agent can pass every security control and fail all six of these questions with no adversary anywhere.
The Big Four – KPMG's ten pillars of trusted AI, Deloitte's seven dimensions, PwC's agent-workforce framing – publish trust messaging at principle level and keep the methodology inside the engagement.
Mostly, no. The controls the registers name are often standard software engineering, and the theory behind them is older than most working developers. Concepts such as least privilege, ambient authority, bypassable controls and prevented vs detected are theories with long histories in IT and manufacturing.
The closest concept actually comes from the Toyota production system and a practice called poka-yoke. This means designing the process so the error cannot be made, rather than asking the operator to be careful. For example, using a jig or tool that only accepts the part one way round.
Software engineering is full of these and mostly does not call them that: the type that will not compile, the pre-commit hook, the required status check, the protected branch, the migration CI refuses without a down script. Each one takes an error out of the set of things a careful person still has to remember.
This is why there are three class names and not two. "Prevented" is poka-yoke – a device that refuses the action rather than requesting restraint. "Detected" is the inspection step that catches what the jig missed. "Survives" is the admission that there is neither, and somebody's attention is the whole control.
So the registers propose no new kind of control. They ask which mistake-proofing devices exist for a worker that cannot be asked to be careful, and record where none does.
The rest of the practice transfers directly, and is mostly older than software:
So the controls have long pedigrees. The literature does not hold the threat model: an autonomous worker that runs as you, at machine speed, on its own initiative, across your whole machine.
The theory is also outside of most developers' education. Security engineering and audit theory are optional at best; in practice, teams install controls by platform default, audit finding, and folklore after an incident.
This approach worked when a person's blast radius was one domain at a time. An agent crosses more domains in one afternoon – database grants, git internals, CI, shell, credentials, backup cadence – than one person studies in a career. Expecting every developer to hold all of that theory is unrealistic. Most will not, and should not have to.
The next wave of users will not be developers at all. Someone using an agent to build their first product meets these failures with no folklore to fall back on, and asks the reasonable question we asked: why doesn't the tool catch this itself?
Part of the answer is that vendors do ship controls – checkpoints, permission prompts, sandboxes. The larger part is that most of these controls live on surfaces no agent vendor owns: your repository host, your CI, your database, your backup schedule.
On the authority register, only three of 23 rows name the agent harness as the strongest available mechanism. A vendor cannot flip a branch ruleset for you.
That frustration is where these registers began: our own build, failure by failure, each one written down, classified, and matched to the strongest control available.
If the registers do their job, they shrink – into settings to flip, tools to install, and processes to follow, which close most of the rows. A practice remains for the rows nothing closes: the judgements that stay yours whatever you install. The end state is a set of defaults, plus a short list of decisions that you need to own.
How the registers were derived, tested and validated is on the methodology page.
Make your agents work.
