The conversation at the approval meeting has a standard shape. The engineering team demonstrates the agent completing the task — using the production corpus, handling the expected variation in inputs, navigating the edge cases the team identified in testing. Domain experts confirm the outputs are good, often better than the baseline the system is replacing. Someone asks about error handling; the team shows the fallback behaviour. The conversation moves to deployment timeline. The approval is given.
What does not happen in that meeting, in almost every enterprise AI organisation we work with, is a question about the conditions under which the agent is authorised to act. Not whether it can act — the demonstration answers that — but whether the organisation has agreed on what the agent is permitted to do when it encounters a situation the task specification did not address, what it does when it partially fails, and who is responsible for the state it leaves behind. The capability question and the authorisation question sound like the same question. They produce entirely different systems.
We have been directly involved in or asked to review fourteen agentic deployment decisions since the start of 2025. In four of those fourteen, both questions were asked before go-live. In the remaining ten, the approval rested on capability alone. Of those ten, six produced incidents within six months of deployment that were directly traceable to the absence of authorisation constraints. In three cases, the incidents required engineering work to reverse or contain the agent's actions. In one, the agent had overwritten a production record set with no clean rollback state.
#02The capability/authorisation confusion
The two questions look alike because both concern what the agent does. They differ in who is being asked. Capability is a question about the system: can the agent identify, decide, and execute? Authorisation is a question about the organisation: what is this agent permitted to do, in whose name, within what scope, and under what conditions may it act without human review?
In software systems with human users, authorisation is treated as an architecture concern entirely separate from capability. The question of whether a session can invoke a write endpoint is answered by an authorisation policy, not by the existence of the technical capability to call it. No engineering team confuses those two questions when building access controls for a human user. For AI agents operating in the same systems and performing comparable actions, the confusion is close to universal in the deployment conversations we participate in.
The reason is that capability is visible in ways that authorisation is not. You can demonstrate an agent completing a task. You cannot demonstrate an authorisation policy — you can only document one, and documentation requires a meeting at which stakeholders absent from capability demonstrations need to be present: the legal function, the compliance team, the operational owner who understands the downstream consequences of specific action types. In the timeline pressure of most deployments, that meeting tends not to happen, and the approval is granted on the basis of what can be shown rather than what the organisation has agreed.
#03What the failure mode looks like in practice
Two incidents from this year make the shape of the problem concrete. Both involved systems we were brought in to investigate after the fact.
The first was a supplier correspondence agent deployed by a mid-market procurement operation. The agent's scope was to communicate with suppliers about outstanding invoices — standard language, receipt confirmation, requests to correct specific fields. The capability had been correctly demonstrated: the agent handled the expected variation in invoice formats and supplier response styles without issue. What was not defined was the agent's authority when a supplier proposed revised payment terms in its reply. Over fourteen weeks, the agent received 27 such proposals and, interpreting 'confirm agreement where the invoice amount is not disputed' broadly enough to cover them, indicated acceptance in each case. The procurement team's interpretation was that it did not cover them. The result was a correspondence record containing implied agreements to terms the organisation had never formally approved — a twelve-week remediation project, with three supplier relationships requiring direct re-engagement to clarify the position.
The second was a data enrichment agent running inside a CRM. Its task was to augment contact records with information retrieved from company websites, filings databases, and industry directories. The task specification was bounded: update specific fields, confidence-weight uncertain values, flag unknowns rather than populate from unreliable sources. This the agent did correctly. What was not bounded was its behaviour in cases where the retrieved value contradicted an existing record. In those cases — approximately 11 per cent of records processed — the agent replaced the existing value with the retrieved one, treating the external source as more reliable than the incumbent entry. In 18 per cent of those overwrites, the original value was correct, having been entered by a relationship manager from a private source the agent had no access to. The agent processed 14,000 records before the first systematic review of its outputs.
In both cases, the capability question had been answered correctly. Both agents were completing the tasks they had been given. The authorisation question — what they were permitted to do in edge cases not covered by the original scope specification — had not been asked.
#04The five criteria we now require
We now treat every agentic deployment as requiring a formal authorisation framework before the system enters production. The framework is not technical in the engineering sense — it lives in a document that a non-engineer can read and audit — but its requirements must be satisfied by architecture rather than by procedure. A procedure that requires a human to remember to do something is not authorisation. An architecture that makes certain actions impossible outside defined conditions is.
The first criterion is scope enumeration. Before deployment, the set of actions the agent is permitted to take must be explicitly listed — not described at a general level, but listed. An agent that 'manages supplier communications' has not had its scope defined. An agent that 'sends and receives emails from the supplier list in the CRM supplier contact table, creates response threads in the ERP correspondence module, and reads but does not modify invoice payment schedules' has. The distinction matters because scope violation is only detectable against an explicit scope. The supplier correspondence incident was traceable, in part, to a scope description that named the task class rather than the action set.
The second criterion is reversibility classification. Every action type in the enumerated scope must be classified by reversibility. Reads are trivially reversible; most writes are partially reversible within a time window; some actions — external communications, record deletions, supplier confirmations that may constitute implied acceptance — are not practically reversible at all. For irreversible actions, the framework must specify an elevated mechanism: either the agent does not take those actions autonomously, or the action is gated on a prior human checkpoint, or the agent is constrained from proceeding when its confidence does not meet a defined threshold. The reversibility map is the most useful output of the authorisation exercise, because it immediately identifies the action types carrying the highest consequence and forces a decision about whether they belong in the agent's scope at all.
The third criterion is boundary behaviour. The authorisation framework must define, precisely, what the agent does when it encounters a situation outside its enumerated scope. The boundary cannot be specified as 'escalate to a human when uncertain' — uncertain is not a state the model reliably identifies in the way that threshold conditions are. It must be expressed as concrete trigger conditions: 'if a supplier communication contains proposed terms not present in the invoice under discussion, close the thread without response and raise a task for the supplier relationship owner.' Explicit and inspectable. A boundary behaviour that depends on the agent's own judgement of when it is out of its depth is not a boundary — it is a description of what you hope will happen.
The fourth criterion is checkpoint intervals. For agents operating over extended periods or across large record sets, the framework must specify at what interval a human reviewer examines the agent's outputs before they are committed at full scale. In the CRM enrichment case, no interval was specified. The agent processed 14,000 records before anyone reviewed its output systematically. A checkpoint after the first 200 records — with a domain expert examining a sample across the full action type distribution — would have surfaced the overwrite pattern before it applied at scale.
The fifth criterion is attribution architecture. Every action the agent commits must be attributable, at audit time, to the agent session, the task context, and the triggering instruction or schedule. It is not sufficient for an audit log to record that 'agent-enrichment-prod updated contact record 44821 at 09:14.' The record must link to the session that initiated the update, the retrieved source that justified it, the confidence weight assigned, and the prior value overwritten. That level of attribution is what makes a post-incident investigation tractable. Without it, the damage is visible and the cause is a reconstruction exercise.
“Capability is a question about the system. Authorisation is a question about the organisation. In most agentic deployments we review, only one of those questions has been answered before the system goes live.”
#05Why reversibility is the load-bearing criterion
The five criteria are not equally important in architectural terms. Reversibility is the one that determines what an agent can and cannot be permitted to do, regardless of how well the others are satisfied.
An agent whose entire action set is reversible can be deployed with a relaxed checkpoint interval, because failures are correctable before they propagate. An agent whose scope includes irreversible actions — external communications, record deletions, financial commitments, data overwrites without backup — must be held to a higher standard of certainty before it acts. The mechanism for achieving that standard must be architectural: a checkpoint before irreversible actions, a hard constraint preventing the agent from taking them autonomously, or a restricted scope that excludes them. The mechanism cannot be procedural, because a procedure that depends on the agent's own assessment of its certainty inherits the reliability of that assessment.
The instinct in most deployment conversations is to treat irreversible actions as edge cases — not the common path, not worth constraining the primary design around. In both incidents described above, the damage came from exactly those edge cases. An agent processing 1,000 records per day with a 2 per cent out-of-scope rate encounters 20 edge cases daily. Over six weeks, it has handled 840 of them. By that point, the question is not whether something has gone wrong but how much of the edge-case distribution has been managed in ways the organisation would not have approved if it had been asked.
Organisations that get this right before an incident treat reversibility as a design property, not an operational concern. Read-only agents deploy with minimal oversight. Write agents require action classification before approval. Agents that send external communications — to suppliers, customers, regulators, counterparties — require the most rigorous framework, because their actions are simultaneously irreversible and externally visible in ways that create obligations the organisation has not reviewed.
#06What the approval gate actually produces
An organisation that has worked through the authorisation framework before deployment understands what it has deployed in a way that one which approved on capability alone does not. It knows the action set, the reversibility profile, the boundary behaviours, the checkpoint schedule, and the attribution architecture. It has a document that a non-engineer can read and that a regulator can examine.
It has something more useful still: a conversation that happened before the agent went live, in which the business stakeholders, the legal and compliance functions, and the engineering team agreed in writing on what the agent is permitted to do. That conversation surfaces misalignments that would otherwise appear as incidents. The procurement director who did not understand that the supplier correspondence agent might handle revised-terms proposals in a way that implied acceptance did not attend the capability demonstration. She would have attended the authorisation review, and the misalignment would have been identified in a meeting room rather than in a dispute with a supplier over payment terms.
We have run this review as a standard requirement in seven deployments since establishing it. In four of the seven, the exercise produced changes to the agent's scope before launch — not because the capability design was wrong, but because a stakeholder who understood the downstream consequences of specific action types had not been present when the capability was designed. In two of the four, those changes delayed the launch by approximately one sprint. In both cases, the delay was shorter than the incident remediation that followed in comparable deployments where the review had not been run.
The case for the approval gate is not that it prevents every failure — agents in production will encounter situations their designers did not anticipate, and some of those encounters will produce errors. The case is that it separates failures attributable to the genuinely unexpected from failures attributable to the simply unexamined. The first class is normal and manageable. The second is what produced the incidents described here: not systems behaving unexpectedly, but systems behaving exactly as designed, in ways nobody had formally decided whether to authorise.