Authority is not something an agent has. It is issued, bounded, and has to be closed out. The closing is the hard part.
Once a month, before the payroll run, a director at Terminal 3 issues the agent a credential.
The credential names the employee records the agent may see for this cycle, the contribution rules that apply, the thresholds and categories and caps on expenses, and a ceiling for the consolidated bank transfer, declared before the run begins. The agent then calculates salaries and statutory contributions, validates expenses, checks account details, and disburses. Every action it takes is routed through a trusted execution environment and checked against the parameters of that credential before it executes. Anything outside them is blocked and logged. The payroll data stays inside the execution environment rather than entering the agent's context, so the agent acts on records it never reads, and the execution trail is written to a hardware-attested ledger.
Next month the director issues another one.
This account comes from a case study in Singapore's Model AI Governance Framework for Agentic AI, contributed by Terminal 3. IMDA published it; there is no indication IMDA audited the ledger, tested the credential enforcement, or otherwise checked the description against the system. It is a deployment described by the organisation that built it, in a document published by a government body.
Inherited. From Approve, but not merge. Organisations grant specific decisions on stated terms rather than publishing an autonomy level. Applied to. What happens to that grant after it is made. The question. When does an issued authority stop existing, and how would anyone know?
Authority with an end on it
Approve, but not merge looked at four organisations deciding which decisions an AI system could make, and who was allowed to move that line. This is the next question. Once you have decided, how do you hand over the authority so that it exists for this run, this amount, this month, and then stops existing?
Terminal 3's answer is that the authority is an object. It is issued by a named person, it carries its own limits, and it expires. It is not a property the agent possesses between runs.
That is a clean proposition and it is not the hard part.
The gap after yes
In August, three researchers published a paper that starts from an observation most authorisation systems have not caught up with. Authorisation usually ends at admission. The approval is granted, the action is admitted, and the system considers the matter settled. But the world does not settle at the same moment. Provider state, delivery, retry and recovery all keep moving after admission.
Two things go wrong in that interval. A request can change between approval and commit, so what executes is no longer what was authorised. Or a response goes missing, the system cannot tell whether the payment went through, and a replacement attempt turns one approval into two effects.
AID-Guard is an attempt to close that gap. It revalidates the approved request and the provider's state at the moment of commit rather than trusting the earlier decision. Under ambiguity, when the outcome genuinely is not known, it holds a single reservation open. It permits release, or exactly one successor attempt, only after a terminal result or certified evidence that the first effect did not occur. For provider contracts that support it, one reservation yields at most one effect across retry and recovery.
Stated plainly: the hard part is not granting authority. It is knowing when that authority is finished.
The evaluation is a Python and SQLite prototype, and the testing is small but deliberately adversarial. All 210 Stripe provider-contract trials matched their predeclared outcomes, and schedules built around overlapping races and crash recovery ran without producing duplicate effects. Under complete compromise of the proposing component, 44 attacks out of 44 were blocked while 44 matched legitimate proposals were still admitted. The authors bound their own claim to the effect paths, provider contracts and failure schedules they evaluated, which is more restraint than most published controls show.
What it costs to close the loop
Approve, but not merge found only two organisations in four that had measured what their control cost to run. This paper measured its own, and the number is a different order of magnitude.
Under the strictest profile, where the committed request must match the approved manifest exactly, benign task completion fell by 35.4 to 43.8 percentage points. A more permissive typed profile recovered nine to ten completions with no unsafe effects observed in the tests.
Uber's per-call authorisation cost forty milliseconds. This one is not measured in latency at all. It is measured in tasks that no longer complete.
Both numbers are honest and neither generalises. What generalises is the shape: binding authority to a single effect, all the way through commit and retry and recovery, has a price, and the price is paid in throughput rather than in latency. An organisation that has not measured it does not yet know what its control decision costs.
Show me the loop
Every organisation that deploys one of these systems says a human reviews the consequential decisions. The claim is cheap to make and, until recently, almost impossible to test from outside.
Derek Mobley filed suit against Workday in the Northern District of California in February 2023, alleging that algorithmic applicant screening rejected him on the basis of race, age and disability. The procedural history matters more than the allegations. In July 2024 the court dismissed the theory that Workday was an employment agency, without leave to amend, along with the intentional discrimination claims. What survived was disparate impact on an agent theory.
Timing helped it survive. The court noted that the plaintiff had been rejected at the screening stage from more than a hundred positions, that rejection emails arrived outside business hours and within an hour of applying, and held that these facts, alongside allegations about training data, supported a plausible inference that the screening algorithms were rejecting applications automatically on a basis other than qualifications. Workday denied the allegations in August 2024. The collective certified in May 2025 is preliminary, and when applicants screened by HiredScore features were included that July, Workday's objections were parked for the decertification stage rather than resolved. The EEOC filed an amicus brief, which the court accepted on the grounds that the questions were of first impression.
Nothing here has been decided. That is not the point. The point is that whether a human checkpoint was operating has become a contested factual question, and the evidence being argued over includes how quickly the decision appeared after the application.
The observable both sides reached for
Here is the part worth sitting with. Singapore's framework, published before any of this reached a notice stage, tells organisations to audit their human oversight using measurable indicators. It names three. A low override rate, which can indicate rubber-stamping. An unusually short review time, which can indicate automation bias or review fatigue. And analysis of outlier reviewers whose decision patterns differ materially from their peers.
A governance body and a federal judge, working from opposite directions, reached for the same observable. If you want to ask whether a checkpoint is real, one place to look is how long it takes.
That is a more useful finding than either source alone. Review time cannot establish on its own that oversight was meaningful. But it is evidence about it, available from the outside to a regulator, an auditor or a plaintiff, drawn from data the organisation is already generating.
This is becoming architecture
Two governance documents published this year converge on the same design.
Singapore's framework distinguishes structural and rule-based controls from model-based or prompt-layer ones, and recommends deterministic system-level enforcement for higher-risk actions: restrict a tool technically rather than instructing the model not to use it. Where the rule lives was about what happens when that advice is ignored. The framework also introduces runtime controls on the reasoning that design-time safeguards may not be sufficient, sets out checkpoints before high-stakes, irreversible and anomalous actions, and gives payment above a predefined amount as its example. And it concedes, in its own executive summary, that continuous human oversight of all agent workflows becomes impractical at scale.
The joint guidance issued in May by the cybersecurity agencies of the United States, Australia, Canada, New Zealand and the United Kingdom says permissions should be restricted to the minimum needed for approved tasks, treats broad agent permissions as equivalent to a privileged-account compromise, requires just-in-time credentials for high-impact actions, and insists that the people who design and operate the system, not the agent, decide where approval is required. It also warns that checking entitlements only once produces stale allow decisions.
Stale allow decisions. That is the same failure AID-Guard is describing from the engineering side, and the same one Terminal 3's monthly reissue limits, by capping how long any earlier allow decision persists. Three sources, three vocabularies, one problem.
What is still missing
Every control in this article sits above the agent and below nobody. The credential check, the reservation, the classifier that decides which actions need approval: each holds real authority and acts without being asked. Who supervises them is a live question, and not one this article answers.
What this material does answer is narrower and more immediately useful. An authority handed over without a termination condition is not bounded, however carefully its scope was drawn. It can drift past the moment it was meant to cover, be reused when a response goes missing, or persist because nobody specified what finishing looks like. Terminal 3's ceiling expires with the cycle. AID-Guard's reservation closes on evidence. Both are answers to the same question, which is not what the agent may do but when it stops being allowed to.
The important distinction is not between restrictive and permissive authority. It is whether, for every authority issued, the system can say whether it is still open.
An authority that never closes is an authority nobody is counting.
Sources
- IMDA, Model AI Governance Framework for Agentic AI, version 1.5, published 20 May 2026, updated 5 June 2026; Terminal 3 case study at section 2.3
- Tong, Dai and Guo, AID-Guard: Stateful Authorization for Delegated Agent Effects, arXiv preprint, 21 August 2026
- Mobley v. Workday, Inc., No. 3:23-cv-00770 (N.D. Cal.); order on motion to dismiss, 12 July 2024, 740 F. Supp. 3d 796; preliminary collective certification, 16 May 2025; HiredScore inclusion, 7 July 2025; notice plan approved, 2 December 2025. Case ongoing
- CISA and partner agencies of Australia, Canada, New Zealand and the United Kingdom, Careful Adoption of Agentic AI Services, 1 May 2026
The Terminal 3 account is described by Terminal 3 in a framework published by IMDA; no independent verification of the implementation is claimed. The AID-Guard results are from a prototype evaluation by its authors and have not been peer reviewed. The Mobley findings described are procedural; no merits determination has been made and the allegations are denied.