Approval and execution happen at two different moments
An employee approves a purchase order. While that order waits for processing, another workflow consumes the same budget. The AI agent then executes the previously approved order. Every individual step appears correct: the employee gave permission and the agent acted on it. Yet the organization exceeds its limit.
This is not a language-model error. It is a failure in the control layer around the action. The approval was valid when it was given, but no longer valid when the action was actually committed.
New independent research into concurrent agent systems calls this stale authorization: a system executes an allowed action after the state that justified the permission has changed. The paper uses shared budgets and inventory, among other examples, to show why controls applied only when a request is made are insufficient.
Human review does not automatically solve the timing problem
Human-in-the-loop is often treated as the safe end state: let a person review a risky action and allow the agent to continue afterwards. That is sensible, but only when it is clear what the approval reserves, how long it remains valid and which conditions invalidate it.
For a simple text review, an approval may remain useful for a long time. An action against a changing system is different. Consider an order within a daily budget, a reservation of scarce inventory, a refund within a customer limit, a change below a risk threshold or the provisioning of cloud capacity within a quota. Other people, agents and systems may consume the same capacity in the meantime.
Approval for request A can therefore become obsolete before A is executed. The human decision was not wrong. The system incorrectly turned it into unlimited, detached permission.
Check not only identity, but also current state
Many authorization controls answer a static question: may this user or agent call this tool? Operational agents require an additional question: may this specific action still be committed now, given the latest state of the business process?
That second question must be answered as close as possible to the actual change. Otherwise a gap opens between check and execution. In security, this is known as the time-of-check-to-time-of-use problem. The OWASP Transaction Authorization Cheat Sheet covers the same general risk: what was valid during the check may no longer be valid when it is used.
For an AI workflow, the control layer must therefore reread the relevant conditions before the target system changes. Not only who requested the action, but also remaining budget, available inventory, current approval status, quotas, risk signals and any intervening changes to the case.
An audit log proves the failure but does not prevent it
A clean audit log can later show that the employee approved at 10:02 and the agent executed at 10:08. That is useful for investigation and accountability. It does not prevent another transaction from consuming the same budget capacity at 10:05.
Monitoring has the same limitation. An alert after the second booking reports that the threshold has been exceeded. The control should instead prevent two individually valid decisions from creating an invalid combined state.
The decision, current policy state and effect must therefore be technically coupled. In some workflows, that means revalidating immediately before execution. In others, a reservation must temporarily hold budget or inventory. For critical transactions, the final check may need to be part of the same atomic operation as the change itself.
What the research does and does not establish
The researchers built a PostgreSQL-backed prototype and compared it with approaches that pass policy state as ordinary request context. In controlled experiments, the prototype prevented stale authorizations that the comparison methods missed. They also exercised a scripted procurement workflow with shared budgets and inventory.
This is useful technical evidence for the problem and a possible solution direction. It is not a production audit or a language-model performance study. The procurement workflow was deliberately scripted and did not use an LLM. The value of the research therefore does not lie in a promised performance percentage, but in the demonstrated systems failure: separate checks can all return green under concurrent operations while the combined result violates policy.
Four acceptance questions for every agent allowed to change a system
- Which mutable state determines permission? Identify whether budget, inventory, quota, status, risk or another shared value constrains the action.
- What does approval reserve? Determine whether approval only confirms intent or also temporarily holds capacity.
- When does approval expire? Define a time limit and the system changes that require reassessment.
- Where does the final check happen? Test the conditions immediately before the effect and, where needed, couple the check transactionally to the change.
Then test more than one agent in an empty environment. Let two workflows claim the same limited capacity at the same time. Delay a human approval while the underlying state changes. Finally, inspect not only the logs but also the resulting state in the ERP, CRM, TMS or other target system.
The production lesson: permission belongs with the effect
An agent that performs operational work needs more than a good prompt, a role model and an approval button. It needs a control layer that brings data, business rules, human decisions and system changes together at the right moment.
The practical rule is simple: never treat approval as permanent permission by default. Before the agent commits an action, the system must be able to demonstrate that the current state still permits it. Only then does human review become a real control rather than a snapshot.