Approval is only the start. The harder control is proving when one delegated authority has actually finished.
Once a month, before Terminal 3 runs payroll, a director issues its agent a credential for that cycle. The credential names the employee records the agent may use, the contribution rules that apply, the expense thresholds and caps, and a ceiling for the consolidated bank transfer. The agent can then calculate salaries and statutory contributions, validate expenses, check account details and disburse.
Terminal 3 says every action passes through a trusted execution environment, where it is checked against those declared limits before anything executes. Actions outside the credential are blocked and logged, payroll data stays inside the execution environment rather than entering the agent's context, and the trail is written to a hardware-attested ledger. When the next payroll cycle comes around, the director issues another credential.
The account appears in Singapore's Model AI Governance Framework for Agentic AI and was contributed by Terminal 3 itself. IMDA published the framework, though the document gives no indication that IMDA audited the ledger, tested enforcement or independently checked how the deployment behaves. I would treat it as a documented design and deployment claim, rather than independent proof that the controls always work.
In Approve, but not merge I looked at organisations deciding which decisions an AI system could make, and who was allowed to move that line. This is the question that comes after it. What interests me is the shape of the authority Terminal 3 issues. It does not give the agent a permanent property called payroll access. A named person issues an object for one cycle, that object carries its own limits, and the authority expires with the cycle. The permission has an end built into it.
That sounds clean until something has already been approved and the world refuses to finish cleanly. In August, Tong, Dai and Guo published AID-Guard around a problem most authorisation systems treat as somebody else's concern. Approval usually decides whether an action may begin. Provider state, delivery, retries and recovery can keep changing after that decision.
Two failure paths follow from the gap. A request can change between approval and commit, which means the effect that finally executes no longer matches what was authorised. Or the response disappears, nobody can tell whether the first payment happened, and a replacement attempt turns one approval into two effects.
AID-Guard tries to carry the authority through that uncertain interval instead of treating admission as the end of the job. It revalidates the approved request and provider state at commit. When the result is genuinely unknown, it holds one reservation open and permits release, or one successor attempt, only after a terminal result or certified evidence that the first effect did not occur. Under provider contracts that support the design, one reservation is intended to produce at most one effect across retry and recovery.
Granting authority is easy to describe because there is usually a visible approval event. Closing it is harder because the system needs evidence that the effect completed, failed or definitely never happened. Without that evidence, the authority can remain logically open even after everybody involved thinks the transaction is over.
The AID-Guard evidence is still prototype evidence. The authors implemented it in Python and SQLite, then tested provider contracts and failure schedules they defined themselves. All 210 Stripe provider-contract trials matched their predeclared outcomes, and the schedules around overlapping races and crash recovery produced no duplicate effects. Under complete compromise of the proposing component, all 44 attack proposals were blocked while all 44 matched legitimate proposals were admitted.
I like that the authors stop their claim at the paths and schedules they actually tested. The numbers show that the mechanism behaved as intended inside that evaluation. They do not tell us how it behaves across the messier provider contracts, operational shortcuts and recovery procedures of a real organisation.
The cost is unusually visible as well. Under the strict profile, where the committed request had to 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 without an unsafe effect being observed in the test set.
That is a different kind of control cost from latency. Binding one approval to one effect can stop work that would otherwise have completed, because the system refuses to improvise once the state stops matching the authorised path. I would rather see that cost measured than hidden behind a statement that the system has safeguards. An organisation that has never measured the work its control prevents does not yet know what the control costs.
Singapore's framework reaches the same issue from the governance side. It recommends deterministic system-level enforcement for higher-risk actions, sets out runtime checkpoints for high-stakes, irreversible and anomalous actions, and gives a payment above a predefined amount as an example. Its executive summary also acknowledges that continuous human oversight of every agent workflow becomes impractical at scale.
The joint guidance published in May by cybersecurity agencies from the United States, Australia, Canada, New Zealand and the United Kingdom approaches the problem through credentials and entitlements. It recommends minimum permissions for approved tasks, treats broad agent permissions as comparable to privileged-account compromise, calls for just-in-time credentials for high-impact actions and warns that checking entitlement only once can leave stale allow decisions in place.
That warning is very close to the engineering problem AID-Guard is solving. Terminal 3 limits how long an earlier decision survives by issuing new authority for each payroll cycle. AID-Guard keeps checking until the effect reaches a state that can close the reservation. One closes on the calendar. The other closes on evidence.
A control can only close authority if the state that closes it is observable. This is why review time appeared in both Singapore's framework and the Workday litigation as evidence about whether a human checkpoint was actually operating.
In Mobley v. Workday, Derek Mobley alleged that automated applicant screening rejected him on prohibited grounds. The court has made no merits finding, and Workday denies the allegations. In allowing part of the case to proceed, however, the court considered the timing of rejections, including decisions arriving outside business hours and within an hour of applying, as one fact supporting a plausible inference that screening was automated.
Singapore's framework separately tells organisations to examine measurable indicators around human oversight, including unusually short review times, low override rates and reviewers whose decisions differ materially from their peers. Neither source proves that elapsed time tells you whether a review was meaningful. Together they show why a claimed checkpoint needs an observable trace if anyone outside the workflow is expected to test whether it happened.
I think this is becoming a systems question rather than a collection of governance controls. Permission, approval, commit, effect and closure are different states. If the system treats them as one event, authority can survive past the point somebody intended it to cover, or be reused because the outcome of the first action is still uncertain.
The controls here also create a second problem that I do not think we have solved. The credential checker and the reservation layer sit above the agent and exercise real authority of their own. They decide whether the agent may continue, retry or stop. Who supervises those controls remains open.
What the evidence supports more clearly is a narrower rule. Every delegated authority needs a termination condition, and the system needs an observable way to establish that the condition has been reached. Terminal 3 closes on the cycle. AID-Guard closes on evidence about the effect.
If a system can tell me what an agent is allowed to do but cannot tell me whether that authority is still open, I do not think the authority is bounded yet.
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. The prose was drafted with AI assistance. The research, verification and editorial decisions are the author's.