← Agent Governance collection
Agent Governance Regulation

Your AI Agent Has an Approval Gate. It Doesn't Have a Stop Button.

Article 14 of the EU AI Act names three human oversight capabilities. Most AI deployments have built one of them, and the two they skipped are the ones that matter after an agent starts running.

Christopher Wakare
Updated
8 min read
Agent Governance

The weekly replenishment run had been approved that morning. Plant manager looked at the plan, saw 340 lines inside the agreed bounds, signed off. Forty lines in, a buyer noticed the forecast feed had been stale since Friday and every quantity after line 12 was wrong. She had the authority to approve that run. She had no way to stop it. The number she called was the service desk, and by the time someone with credentials had disabled the service principal, the run was two-thirds posted and nobody could say cleanly which third was not.

The approval gate did its job. It was the wrong control for the problem.

The reveal

Approval authority decides whether an action starts. Suspension authority halts one already running, exercised by whoever notices the problem rather than whoever holds the credentials. They are different controls, built at different points in the stack, and a deployment can have the first in perfect shape while the second does not exist. Most do.

Regulators have been more precise about this than most vendors. Article 14 of the EU AI Act sets out what human oversight of a high-risk AI system requires, and paragraph 4(e) is unambiguous: the people assigned oversight must be able to "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" (EU AI Act, Article 14(4)(e)). Read the last clause twice. The obligation does not end at the halt.

AI agent human oversight is three controls, not one

Article 14(4) enumerates the capabilities a person exercising oversight has to actually possess. Three of them describe distinct engineering commitments.

The first is interpretation: 14(4)(c) requires the overseer to "correctly interpret the high-risk AI system's output, taking into account, for example, the interpretation tools and methods available." The second is reversal: 14(4)(d) covers the ability to "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output." The third is interruption, the stop button in 14(4)(e).

An approval gate lands on part of the second. It gives a named human the chance to disregard an output before it executes. That is real, and it is where almost all governance investment has gone, because it maps onto workflow software that already exists and it produces a satisfying artefact for an audit committee.

Now check the other two against a live deployment. Can the approver tell why the agent proposed what it proposed, from the same screen where they approve it? Once a write has posted, is there a defined reversal path, or does reversal mean a support ticket and a journal correction three days later? And can anyone stop the thing mid-run? A governance programme that reports human oversight as complete on the strength of an approval matrix has built one control out of three and counted it as the set.

Regulators moved from who approved it to who can stop it

The interesting signal this year did not come from an AI regulator. It came from a central bank.

On 30 June 2026, Reuters reported that Bank of England Deputy Governor Sarah Breeden had signalled the need for bespoke rules to contain the risks agentic systems pose to the financial system (Reuters, 2026). The line worth sitting with: "Our frameworks were not built to contemplate autonomous agents, and relying on a human in the loop for all agent actions is unlikely to be realistic."

That is a regulator saying the approval gate does not scale. The prevailing industry answer to agentic AI risk is more gates, more sign-off, more humans in more loops. Breeden's position is that this hits a ceiling, and the honest response is different machinery. The Bank is examining "enhanced recovery" arrangements that would let one institution take over another's core functions during a disruption, alongside market-wide circuit breakers or kill switches to halt trading if correlated model failures cascade. A Cambridge Centre for Alternative Finance survey she cited puts 52% of finance firms already running agentic systems.

Financial services is not manufacturing, and the Bank of England does not regulate your plant. The read-across is the reasoning, not the rule. A supervisor looked at autonomous systems acting faster than approval cycles and concluded the durable controls are interruption and recovery. The same logic arrives at the same place for a distributor running replenishment agents against an ERP, several years before anyone writes it into manufacturing supervision.

What Business Central and Copilot ship natively, and what has to be built

Map the three capabilities onto what a mid-market team actually has in the box.

Oversight capability What it requires operationally Native in BC + Copilot What has to be built
Interpret the output
Art. 14(4)(c)
The approver sees the data behind the proposal at the moment of decision, not a summary line Partial. Copilot surfaces a rationale; the source records sit elsewhere in the client A decision card carrying the underlying figures with the approval request
Override or reverse
Art. 14(4)(d)
A defined path to undo a posted write, with the reversal linked to the original action Reversing entries exist per document type. No link back to the agent action that caused them Reversal mapped to the originating agent decision, both visible in one trail
Interrupt mid-run
Art. 14(4)(e)
The operations owner halts a running agent without going through IT None. Stopping an agent means revoking credentials or disabling the service principal A halt control in the operations interface, scoped per agent, logged as an event
Halt in a safe state
Art. 14(4)(e)
In-flight work reconciled and the task continues manually None. A killed process leaves a partially posted batch and no statement of where it stopped Transaction boundary per run, an in-flight manifest, and a rehearsed manual fallback

The third column is not a criticism of Microsoft. Business Central is an ERP, and none of this is what an ERP is for. The point is that a roadmap treating "we have approvals in Business Central" as evidence of human oversight is reading one row of a four-row table.

"A safe state" means the work continues without the agent

Here is where the regulation says something operations teams rarely plan for. Article 14 does not ask for a stop button. It asks for a stop button that brings the system to a halt in a safe state, and safe is defined by the business process, not the software.

Kill the replenishment agent on a Wednesday afternoon and three questions land at once. What happened to the 200 lines already posted against a forecast now known to be wrong? Who runs replenishment tomorrow, and do they still know how? What tells the next shift that the agent is off, so they do not assume it ran?

The second question is the one that quietly decides the outcome. Teams that have run an agent for eighteen months have usually stopped maintaining the manual process it replaced. The spreadsheet still exists. The person who understood it changed roles. A stop button with no rehearsed fallback does not resolve an AI incident, it converts it into an operations outage. Which is why, in practice, nobody pulls it. The agent keeps running through the incident because stopping it looks worse than letting it continue, and that is a governance failure that no approval matrix will ever show up as one.

Reversibility carries a real cost, and pretending otherwise helps nobody. Maintaining a manual path for a process you have automated means running a drill nobody wants to schedule. The argument for doing it is that the alternative is discovering the fallback is gone at the worst possible moment, with a regulator's definition of oversight sitting unmet in the file.

Building suspension and recovery into an agent deployment

None of this is expensive at design stage. All of it is expensive at incident stage. The sequence that works:

  1. Set the halt boundary before you need it. Decide the smallest unit the agent can be stopped at: a line, a batch, a full run. An agent with no defined boundary can only be killed, and killing it is what leaves the ambiguous half-posted state.
  2. Put the stop where the problem gets noticed. The buyer who spots the stale forecast needs the halt control, in the interface where she already approves the agent's work. Suspension authority routed through a service desk has a response time measured in queue depth.
  3. Generate the in-flight manifest on halt. What posted, what was queued, what was mid-write, timestamped. Reconciliation without this is a manual audit of the ledger, which is the reason teams hesitate to stop anything.
  4. Name the manual fallback and date-test it. Who runs this process without the agent, and when did they last do it? A named owner and a test date within two quarters. An untested fallback is a fallback you do not have.
  5. Resume under narrowed scope. Restarting an agent at full autonomy after an incident wastes what the incident taught you. Bring it back on the narrower band, widen once the cause is closed out.

Most teams can score their own deployment against that list quickly, and the usual result is a strong step one and nothing after step two. For a structured read on where the gaps sit across the whole decision path, the Decision Latency Diagnostic scores Signal through Audit in 12 questions.

This is the part of decision infrastructure that gets least attention and holds up worst under pressure. OpsGrid puts the approval gate inside the write path to Business Central, and the same position in the stack is what makes a halt meaningful: a control sitting in the execution path can stop traffic through it, name a transaction boundary, and record the stop as a decision with an owner. A policy layer above the write path can approve. It cannot interrupt.

Frequently asked questions

What is suspension authority for an AI agent?

Suspension authority is the ability to halt an agent that is already running, held by the person who notices the problem rather than by whoever controls the service principal. It sits separately from approval authority, which only decides whether an action starts. EU AI Act Article 14(4)(e) names it directly: oversight requires the ability to intervene in the operation of the system or interrupt it through a stop button or a similar procedure that allows the system to come to a halt in a safe state. An approval gate satisfies none of that once execution is under way.

Does an approval workflow satisfy EU AI Act Article 14 human oversight?

Not on its own. Article 14(4) lists several distinct capabilities, including correctly interpreting the system's output, deciding to disregard, override or reverse that output, and intervening or interrupting the system through a stop button. An approval gate covers consent before execution. It does nothing about an agent mid-run, and it does nothing about reversing a write that already posted. A deployment reporting human oversight as complete on the strength of an approval matrix has built one control out of three.

What does coming to a halt in a safe state mean for an ERP agent?

It means the work the agent was doing carries on without it. For a Business Central agent, a safe state has three requirements: no half-posted batch left ambiguous, a documented manual path for the same task, and someone who has run that path recently enough to run it under pressure. Stopping the agent takes seconds. Reaching a safe state is the part that needs designing before the incident, because a stop button with no fallback converts an AI problem into an operations outage.

Who should be able to stop a running AI agent?

The person closest to the consequence, who is rarely the person holding the credentials. If halting a replenishment run requires an IT ticket, the real response time is the ticket queue rather than the click. Practical suspension authority means the plant manager or operations lead can halt an agent from the same interface where they approve its work, with the halt logged as its own event: who stopped it, when, and what was in flight at that moment.

Ask the operations lead who can stop your agents today, and ask when the manual process last ran. If the second answer is a shrug, the first one does not matter. For how the same records read when a regulator or opposing counsel asks for them, see why a correct AI decision still needs a named approver.

A gate that can't interrupt is half a control.

OpsGrid sits in the write path to Business Central, where approval, halt, and the record of both happen at the same boundary.

See the governance-first approach to BC AI

The Execution Edge

Monthly. For operations leaders building faster on AI. Real case studies, system blueprints, and tools — no fluff.

Your subscription could not be saved. Please try again.
Your subscription has been successful.