AI Agent Governance Has a Transaction Problem

Giving an AI agent permission to do something feels like the important part. If an agent can issue refunds, change an account, revoke access or restart a service, someone needs to decide whether it should have that authority. So organisations build permission controls, approval rules and limits around what the agent can touch. 

That all makes sense. But there’s another problem waiting on the other side of the approval. Say an agent has legitimately been authorised to issue a £500 refund. It sends the request, but the payment provider times out before returning a response. The agent doesn’t know whether the refund failed or whether it succeeded and the confirmation simply never arrived. 

So what does it do? Trying again sounds reasonable. Except if the first request worked, a retry could turn one authorised refund into two. And if something else changed while the agent was waiting, even the original instruction might no longer be valid. This is where AI agent governance starts moving beyond the question of permission. 

Organisations also need to know whether the action they authorised is the action that actually happened. It’s becoming a real production concern. In August 2026, new AID-Guard research examined what its authors call the “authorization-to-effect gap” in delegated agent actions. 

Around the same time, AWS began explicitly treating idempotent execution and recoverable workflows as reliability requirements for agentic systems, while emerging standards work from the IETF and FIDO Alliance is looking at how authority follows agents into individual transactions. 

The common thread is pretty simple. Giving an agent the right to press a button isn’t the same as proving that pressing it produced the right result.

Permission Doesn't Guarantee A Correct Transaction

Most permission systems answer a relatively clear question: is this identity allowed to perform this action? That works well for establishing a boundary. An agent either has access to a payment system or it doesn’t. It may be allowed to approve refunds under a certain value, update specific records or make changes within a defined infrastructure environment. 

But once the action begins, another set of questions appears. There’s what the organisation authorised. There’s what the agent attempted to execute. Then there’s the state that actually exists afterwards. We tend to imagine those as one continuous event, but systems don’t always behave that neatly. 

Transaction integrity is the discipline of keeping those three things aligned. The authorised intent needs to remain valid as it moves through execution, and the resulting change needs to match that intent without being duplicated, altered or left in an uncertain state. This isn’t necessarily a security failure in the traditional sense. 

Nobody has to steal a credential, bypass a control or trick the agent into doing something malicious. A perfectly legitimate action can still produce the wrong outcome because the environment changed or the execution didn’t complete as expected. AID-Guard was designed around precisely this problem. 

Published as a preprint on 21 August 2026, the research argues that authorisation often ends when a request is admitted, while provider state, delivery, retries and recovery continue changing afterwards. Its proposed protocol keeps authorisation tied to the action throughout that lifecycle. 

An August 2026 Internet-Draft for the Agent Action Decision Protocol (AADP) approaches the problem from another direction. Rather than asking only who an agent is and which tools it can reach, it asks whether a particular action, using particular values, may be performed now. The proposal includes approval state, reservations, idempotency and evidence requirements. 

It’s still an individual Internet-Draft rather than an adopted IETF standard, but the distinction it makes is useful. Permission gets an agent to the door. It doesn’t tell us what happens once the transaction starts moving.

The Problem Starts When The World Changes

A lot can happen between deciding that an action is valid and actually carrying it out. Consider a purchase order. An agent checks the supplier, confirms the price, verifies that the order is within budget and receives approval to proceed. But there’s a delay before execution. By then the price has changed, another team has bought the same stock or the remaining budget has been allocated elsewhere. 

The original decision wasn’t necessarily wrong. It was made using conditions that no longer exist. This is why runtime validation becomes important for consequential agent actions. An organisation needs to know whether the conditions behind an approval are still true when the agent is about to change something, rather than assuming an earlier decision remains valid indefinitely. 

The World Economic Forum and Capgemini approached a related problem in their May 2026 AI agent governance playbook. Their Agent Capability and Authorization Profile is intended to connect delegated authority with system design and operational oversight across the deployment lifecycle, including ensuring that the conditions under which agents are authorised remain enforceable as systems evolve. 

That changes how we think about authorisation. Instead of treating approval as a permanent green light, some actions may need something closer to a conditional instruction: you can do this, under these circumstances, while these facts remain true. Payments make the idea easy to picture, but the same problem exists elsewhere. 

An employee’s role can change before an access request executes. The infrastructure state an agent planned to modify can change while it waits. A customer account can be updated by another workflow before an automated action reaches it. This isn’t really about whether the agent had enough context to make a sensible decision in the first place. 

It’s about whether yesterday’s, or even 30 seconds ago’s, valid decision is still valid now. Once state can change, an approval needs somewhere to stop and check before it becomes an effect.

Failure Gets Complicated When An Agent Can Try Again

There’s an old problem in distributed computing that becomes surprisingly important once AI agents can take real actions: sometimes you don’t know whether something worked. Imagine an agent sends a request to cancel a customer account. The receiving system processes it successfully, but the acknowledgement gets lost. All the agent sees is a timeout. 

From its perspective, the obvious response might be to try again. And sometimes that’s exactly what software should do. Networks fail. APIs time out. Temporary errors happen every day. Retry logic is one of the ways modern systems deal with those failures without asking a person to intervene every time a connection hiccups. 

The complication is what happens when repeating an operation also repeats its effect. This is where idempotency comes in. The word sounds more intimidating than the idea. An idempotent operation can be safely repeated without creating an additional result. If one authorised refund request is retried five times, the system still recognises all five requests as the same transaction. 

This isn't a new problem invented by AI. Payment APIs have dealt with it for years. Stripe, for example, supports idempotency keys so a client can retry an operation without accidentally creating another effect when the first result is uncertain. What AI changes is how retries may be initiated and managed. 

Traditional software normally follows retry behaviour written by developers in advance. An AI agent may be able to interpret an error, reconsider its plan, change a tool call or decide for itself that another attempt is appropriate. That flexibility is useful until the first attempt has already changed something. 

AWS now treats this as a high-risk reliability issue in its Agentic AI Lens. Its guidance warns that retries without idempotency can create duplicate side effects and recommends deterministic keys that allow the same logical operation to be recognised across repeated attempts and multi-step workflows. So a failed agent action isn’t always failed. 

Sometimes it failed. Sometimes it worked. And sometimes the only accurate answer is we don't know yet. That third possibility is where transaction design starts doing work that agent reasoning can't safely do on its own.

Agent Governance Needs To Extend Through Execution

Once you separate permission from execution, the controls an organisation needs start becoming easier to see. A useful way to think about transaction integrity for AI agents is as a lifecycle: 

Authorise → Revalidate → Reserve → Execute → Verify → Recover 

This isn't a universal technical standard, and different systems will implement each part differently. Rather, it gives governance, architecture and development teams a common way to ask what protects an authorised action between the original decision and the final result. 

• Authorise establishes that the proposed action is legitimate. 
• It answers the familiar permission question before anything consequential happens. 
• Revalidate checks whether the conditions supporting that approval are still true. 
  • Has the amount changed? 
  • Has the account state changed? 
  • Does the budget still exist? 
  • Is the instruction still within the limits originally approved? 
• Reserve binds that intent to a controlled execution path. The terminology will differ between systems, but the purpose is to stop concurrent workers, retries or recovery processes from independently turning one instruction into several effects. 
• Execute carries out the approved operation within those constraints. At this point, the system shouldn't be quietly changing critical parameters simply because an agent reconsidered its plan. 
• Verify establishes what actually happened in the target system. A successful tool call isn't enough if the resulting state can't be confirmed. 
• Finally, recover determines what happens when the transaction fails, stops partway through or ends in an uncertain state. That might mean retrying, resuming from a checkpoint, reconciling the target system or escalating the decision. 

The value of this lifecycle is the continuity between each step. Authority doesn't disappear after approval and then magically reappear in an audit log afterwards. It travels with the transaction. That also creates a clearer dividing line between what an AI agent should be free to reason about and what the surrounding architecture needs to control.

Consequential Actions Need Deterministic Guardrails

One of the reasons AI agents are useful is that they don't need every possible situation scripted in advance. They can interpret information, weigh alternatives and adapt their approach when something changes. If an agent is helping investigate an incident, for example, that flexibility lets it follow new evidence instead of rigidly marching through a checklist that no longer fits. 

But the same freedom becomes harder to justify at the moment an action changes an external system. Reasoning can be probabilistic. Consequential execution shouldn't be improvised. That doesn't mean an agent can never decide what action to take. It means the decision and the effect don't have to be controlled in exactly the same way. 

An agent might decide that a refund is appropriate by interpreting customer history, policy and the current case. A deterministic control layer can still confirm the authorised amount, verify the account state, bind the transaction to a unique identifier and prevent the agent from sending three refunds because two responses timed out. 

AID-Guard makes a similar separation between proposing an effect and enforcing it. Under the provider contracts and failure scenarios the researchers evaluated, one reservation produced at most one external effect across retry and recovery. Its Stripe tests matched the declared outcomes in all 210 trials, although the authors carefully limit those claims to the systems and failure schedules they tested. 

There was a trade-off too. The strictest configuration reduced benign task completion by between 35.4 and 43.8 percentage points. In other words, stronger controls weren't free. They made some legitimate actions harder to complete. That's an important reminder for enterprise architecture. 

The goal isn't to put the maximum possible restriction around every agent action. It's to match the strength of the control to what happens if the action goes wrong. A draft email and a completed payment don't need the same transaction architecture. Neither do a read-only database query and an infrastructure change that can interrupt production. 

The closer an agent gets to an irreversible effect, the less sensible it becomes to let the model improvise the rules around execution.

Verification Matters As Much As Prevention

There’s another uncomfortable question enterprises need to ask once agents begin acting on their behalf: what counts as proof that something happened? An agent can record that it called a tool. It can log the parameters it sent. It can even tell you that the action succeeded. None of those necessarily proves the target system ended up in the expected state. 

A payment provider, customer database or infrastructure platform has its own version of reality. If the organisation wants to know what an agent actually changed, AI agent verification has to reach that resulting state rather than stop at the agent's own record of events. This is particularly important when an outcome is disputed or uncertain. 

Emerging work around agentic payments is already moving in this direction. Google donated its Agent Payments Protocol (AP2) to the FIDO Alliance in April 2026, alongside an updated version that supports pre-authorised “Human Not Present” payments. Google and Mastercard also contributed Verifiable Intent work designed to preserve evidence connecting user authorisation to resulting agent actions. 

FIDO describes AP2 mandates as cryptographically signed records of what a user authorised an agent to do, while Verifiable Intent is intended to make that authority independently provable. The important question becomes whether the completed transaction stayed inside the bounds that were originally approved. 

Payments are ahead here because disputes about money create a very obvious need for evidence. But the same principle applies to enterprise systems. If an agent disables an account, changes a configuration or sends a customer communication, the organisation needs to be able to connect the resulting effect back to the authorised intent. 

Auditability then becomes more than a history of what the agent said it was doing. It becomes evidence of what actually changed. And once an organisation knows what happened, it can make a much better decision about what needs to happen next.

Recovery Isn't Always The Same As Rollback

“Just roll it back” is one of those phrases that sounds reassuring until the thing you've changed doesn't have an undo button. Some agent actions are reversible. A record can sometimes be restored. An access permission can be reinstated. A payment might be refunded. Other actions don't work that way. 

You can't unsend a customer email. You can't make a production restart never have happened. You can't necessarily reverse every downstream process triggered by a purchase order simply because the original action turned out to be wrong. So AI agent recovery needs more than a generic retry or rollback strategy. 

Sometimes the right response is to resume a workflow from the last confirmed state. Sometimes it means reconciling two systems to determine what happened. Sometimes the organisation needs a compensating action, which is simply a new transaction designed to counter the effect of the first one. 

And sometimes the safest thing an automated system can do is stop. AWS's Agentic AI Lens recommends checkpointing long-running workflows so agents can recover from the last completed state rather than starting again. But its guidance makes an important qualification: checkpointing only works safely when replayed steps are idempotent. 

Otherwise, recovery can reproduce side effects or corrupt state. That changes how recovery needs to be designed. If an organisation waits until something goes wrong before deciding whether an action can be retried, reversed or compensated for, the agent is already operating with incomplete rules. The recovery path belongs in the transaction design before the transaction begins.

Transaction Integrity Changes How Enterprises Think About Agent Risk

It’s tempting to measure agent risk mainly by autonomy. An agent that acts without asking a person feels riskier than one that waits for approval, while an agent that only recommends something feels safer still. That’s useful as a starting point, but it tells us surprisingly little about what happens when an authorised action goes wrong. 

A better question is what kind of effect the agent can create:

• Can the action be reversed easily? 
• Can the result be independently verified? 
• Would a duplicate have financial, regulatory or operational consequences? 
• How quickly can the environment change between approval and execution? 
• And if nobody knows whether the first attempt succeeded, is it safe to try again? 

Those questions start to separate AI agent risk management by consequence rather than autonomy alone. The need is becoming more immediate as enterprises move agents towards real workflows. The World Economic Forum reported in November 2025 that 82 per cent of executives planned to adopt AI agents within the next one to three years. 

Its subsequent 2026 work has focused increasingly on enforceable authorisation and accountability across the agent lifecycle rather than treating permission as a one-time decision. That doesn't mean every agent needs payment-grade transaction controls. A research agent collecting public information can tolerate more uncertainty than an agent moving money. 

An internal assistant drafting a purchase request isn't carrying the same consequence as the system that submits it. Even within one workflow, the level of control can change as the agent gets closer to the actual effect. That gives CIOs, architects and governance teams a more practical way to decide where stronger controls belong. 

The question isn't simply, “How autonomous is this agent?” It’s also:

• What can this action change?
• How quickly can the conditions behind it change?
• What happens if it occurs twice?
• Can we independently prove the result?
• What happens if we can't tell whether it succeeded?
• If it goes wrong, can we reverse or compensate for it safely?

Those answers tell you much more about the architecture a consequential agent action needs.

Final Thoughts: Agent Governance Can't Stop At Permission

For a long time, the difficult part of enterprise automation was deciding which systems could do what. AI agents make that question more complicated, but they also add another one. Once the organisation has legitimately said yes, how does it make sure that approval survives everything that happens between the decision and the final effect?

Because real systems don't freeze while an agent works. State changes. APIs fail. Responses disappear. Workflows restart. A transaction can succeed while looking unsuccessful, and a perfectly sensible retry can accidentally repeat something the organisation only approved once. None of that makes permissions less important. 

It simply means enterprise AI governance has to follow authorised intent further. Authorise it. Revalidate the conditions. Bind the action to a controlled execution path. Execute within those limits. Verify the resulting state. Then recover based on what actually happened, rather than what the agent assumes happened. 

As agents move deeper into enterprise operations, the strongest governance models are likely to be the ones that treat an action as more than a moment of permission. They'll protect the complete path between intent and effect. Because eventually the useful question isn't whether the agent was allowed to press the button. 

It’s whether the right thing happened when it did. As that architecture continues to evolve, EM360Tech will keep following the standards, controls and operating models shaping how enterprises turn autonomous AI into something they can safely rely on.