Four organisations gave an AI system real authority over a business decision. None published a level. They named the decision instead.
On 13 March 2026, an AI agent at the software company Ona approved a pull request without a human reading it. A human still had to merge it. That separation is the whole design.
Ona's engineering team published the criteria. A change qualifies for automated approval if it touches fewer than a thousand lines, contains no protobuf changes, no database migrations, no infrastructure or CI configuration, no authentication or authorisation logic, and no changes to audit logging or monitoring. Fail any one and a human reviews it. The classification is performed by an automation rather than by the engineer who wrote the change, which means nobody can move their own work across the line.
The merge stays human. Ona is explicit about why: the merge is the auditable approval event its SOC 2 process depends on, and moving it would cost them the record. So the agent holds the authority to say a change is acceptable and holds none of the authority to put it into production.
The policy was not designed in the abstract. The team spent two weeks watching which pull requests a human reviewer approved without adding anything, and drew the boundary around what they observed. Their own summary of the method is to start by observing rather than by deciding.
Inherited. From A quantity, not a switch. Autonomy is a quantity rather than a state you flip. Applied to. Organisations granting AI systems real authority over business decisions. The question. A quantity of what, granted over what, and on whose signature?
Four organisations, four sectors, one move
Nobody in this article published an autonomy level. There is no scale, no tier, no rating from one to five. Each of these organisations took a process apart, found the decisions inside it, and granted or withheld authority at each one separately, on stated terms.
A quantity, not a switch argued that autonomy is a quantity rather than a state you flip. Nothing here displaces that. It locates it. The quantity is set per decision rather than per system, which is why no single number describes any of these four.
The terms are the engineering. What follows looks at four of them, and at what it cost each organisation to express a boundary that no standard yet knows how to carry.
Authority as a lease
In May 2025, NICE recommended that DERM, an AI system for assessing skin lesions, could be used in NHS teledermatology for patients referred on the urgent suspected skin cancer pathway. The system can identify lesions that need no dermatologist review, removing those patients from the pathway without a specialist seeing them.
The recommendation is not a permission. It is a licence with an expiry and a condition attached. DERM may be used during a three-year evidence generation period, provided the evidence set out in NICE's plan is actually being generated and the system holds the necessary regulatory approvals. The company must confirm its evidence agreements are in place and contact NICE annually. NICE may revise or withdraw the guidance if those conditions are not met. At the end of the period, the evidence returns to NICE, which decides whether routine adoption follows.
Inside that licence, the authority is not uniform. For people with black or brown skin, a healthcare professional review remains mandatory, because the evidence on accuracy in darker skin is weaker. The same system, the same task, different authority by population, keyed to where the evidence supports the delegation. The committee also recorded advice that studies should measure skin tone by spectrophotometry rather than the Fitzpatrick scale, so even the instrument used to locate the boundary is disputed.
The evidence base underneath is contested in a way that matters. In studies the committee considered, at two NHS trusts, a second-read reviewer overturned between 40% and 50% of the cases DERM had marked as eligible for discharge. That figure sits inside the recommendation rather than outside it. The authority was granted with the disagreement on the record.
Setting the amount from the work, not from a policy
Brex rebuilt its customer onboarding, the know-your-customer and underwriting checks a business passes before it gets a card, as a system of specialised agents. It moved from approving none of its card applications automatically to approving roughly 40% of them, and it did so in weeks.
The interesting part is the bar it set before it moved. Brex studied how its analysts worked, wrote down the judgements that had never been written down, and rebuilt its historical cases into a labelled benchmark. Against that benchmark it set three conditions: the system must catch every bad actor a human caught and some the humans had missed, it must never reject a customer a human would have approved, and it must always explain the decision. Agents were built to be able to say they were unsure, and uncertain cases route to an analyst whose decision feeds back as a labelled signal.
Brex attributes the speed of the expansion to its risk specialists and its engineers working as one team rather than to a better model, which is a claim about organisational design rather than technology.
What Brex publishes is the bar. What it does not publish is the evidence that the bar was cleared. The results appear as a chart described as moving up and to the right, with no accuracy figures, no false-negative rate and no independent audit. The confidence threshold that triggers escalation is referred to and never given.
What it takes to enforce any of this
A boundary that exists only in a policy document is a boundary that the system does not know about. Uber's engineering team published, in May 2026, an account of what it took to make one enforceable at the point of action.
Every agent at Uber runs as a workload with a cryptographically signed identity, and only a central token service can mint tokens on an agent's behalf. Each token is issued for a single hop, carries a specific audience claim, and lives for a time measured in minutes. A token minted for one agent to call another cannot be replayed against a database. Each token also carries the full chain of everyone involved, so a request arriving at a tool shows the originating engineer, the agent they invoked, and the agent that one delegated to. Uber's stated reason is a failure they kept seeing: an agent opened a pull request, and the record showed only that an agent had done it.
Authorisation happens at a gateway, per tool call, evaluated against both the human's identity and the agent's. The policies are drawn from an internal risk classification and are mandatory for the systems Uber considers high risk.
Agents built before this architecture existed were brought into it not by mandate but by a standard client that performs the exchange automatically, making the compliant path the easy one.
Three of these four accounts are written by the organisations that built the systems. They are good evidence of what was decided and why the people involved say so. They are not evidence that the boundaries hold in production. NICE is the exception, and it is a public body publishing its reasoning against an evidence base its own committee describes as limited.
Who is allowed to move the line
Granting authority is the easy half. The harder question is who may widen it later, and two of these four answer it.
At Ona, the platform team owns the classification tooling, and any change to the evaluation logic, the criteria, or the agent's review prompt requires explicit approval from the Head of Product Design and Engineering. Swapping the underlying model counts as a material change to the policy. That last clause is the one worth sitting with. Changing the model is a governance event at Ona, not an engineering one.
NICE names its diagnostics advisory committee, and then something more revealing happened. Requests were made to a resolution panel on the grounds that NICE's published process had been breached. The panel found the decision-making framework had not been followed, and that had it been followed, DERM would have been recommended for use while evidence was generated. The recommendations were amended accordingly. The committee reached one position, a panel found the process had not been followed, and the authority granted to the system changed. Who decided has a second layer, and it is on the public record.
Brex names a partnership between its risk specialists and its engineers, and no individual or committee that authorised 40%. Uber names the teams that built the architecture, and nothing about who assigns the risk classification that determines which systems get mandatory policies. In both cases the boundary is real and the person accountable for its position is not identified.
Two out of four. That ratio is the finding.
What the control costs to run
Uber publishes the price of its own control. The 99th percentile latency on the token exchange sits consistently below 40 milliseconds, and they show the graph, because the obvious objection to authorising every hop is that a single task might involve dozens of them.
NICE prices its second read directly. The DERM assessment is £30 per referral. An NHS teledermatology review of the case adds £8.20, and a second read by the company's own dermatologist adds £17. Against that, the assessment group estimated that a healthcare professional review could raise sensitivity from around 95% to about 98%, while the committee noted specificity would be lower than the automated system alone. More cancers caught, fewer patients discharged, at a stated cost per case.
Ona and Brex publish neither. Ona reports that lead time fell from 4.1 hours to 1.1 and deployments rose from 329 a week to 1,037, and reports no defect rate, no escaped-bug count and no incident data for automatically approved changes. Nor does it say why a thousand lines is the right threshold rather than five hundred. Two of these four organisations measured what their control cost. Two published the benefit and stayed quiet about the price.
Why each of them built it themselves
Uber did not start from nothing. Workload identity came from SPIFFE and SPIRE, and the token exchange is built on RFC 8693, a published standard. They customised it, because carrying provenance across hops in a way their auditing and performance requirements could live with was not something the standard did. They had considered handling this with an external proxy and concluded that carrying execution context end to end needed support inside the application layer.
That is not an idiosyncratic choice. It is the state of the field.
The IETF's WIMSE working group has six adopted documents in progress and a seventh already with the IESG, covering workload credentials, identifiers, authentication and practices. Every one of them answers a version of the same question: which workload holds this credential.
Alongside them sit ten further drafts that no working group has adopted, and those are the ones about carrying a person's delegated authority through a chain of agents. Attenuated delegation for agent chains. Signed authorisation-evidence records. Cross-organisational delegation. The cross-organisational draft was revised on 31 August, the attenuated delegation draft on 3 September, and one on delegation-chain integrity was filed on 8 September. They are not stalling. They are arriving faster than anyone is adopting them.
The working group has said as much itself. Its June interim recorded that no current organising framework embodies all of this, and that the question is which pieces are missing. The cross-organisational delegation draft states that existing mechanisms were designed for a single trust domain and a small number of hops, and do not adequately express, constrain or verify authority delegated recursively among agents. It enumerates requirements and declines to specify a solution. The individual draft Uber names as the one it is tracking is not a working group document.
The gap that is left
Everything in this article has an equivalent in older engineering. A permission that expires. An approval separated from execution. A record of who authorised what. A named person who may move the line. Where the rule lives looked at what happens when that machinery sits in the wrong place. For now, putting it in the right place still requires organisations to assemble much of the machinery themselves.
There is a boundary on how much of this a standard could ever carry. A protocol could express that authority was delegated, that it was scoped, that it narrowed at each hop, and that the chain is verifiable. No protocol will tell you that a thousand lines is the right threshold, or that patients with darker skin need a second reader, or that 40% is the right share of applications to approve automatically. The mechanism is standardisable. The judgement is not.
Which leaves a strange position. We have adopted standards for proving which piece of software is calling. We have no adopted standard for expressing what a person allowed it to do on their behalf. Four organisations in four sectors each assembled that machinery themselves, in order to express a judgement only they could make.
And in each of them, something now enforces the boundary automatically: a classifier, a gateway, a routing rule. Those controls hold real authority, and they act without asking. Which raises the question of what sits above them.
Sources
Ona, How auto-approving low-risk PRs with AI cut our lead time by 74%, Benjamin Stark, 9 April 2026
NICE, Artificial intelligence technologies for assessing and triaging skin lesions referred to the urgent suspected skin cancer pathway: early value assessment (HTG746), 1 May 2025; migrated from HTE24 in December 2025 with recommendations unchanged
Thomas and others (2023), second-read overturn rates at two NHS trusts, as recorded in the NICE committee discussion
Brex, The end of the trade-off: How AI agents broke the onboarding trilemma, undated
Uber, Solving the Identity Crisis for AI Agents, 21 May 2026
IETF, Workload Identity in Multi System Environments working group document list, retrieved 9 September 2026
IETF, Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements, draft-reece-wimse-cross-org-delegation, revised 31 August 2026
IETF, WIMSE working group interim meeting minutes, 3 June 2026
The Ona, Brex and Uber accounts are written by the organisations that built the systems described.