Arjen Hendrikse, Founder, Aivance Consulting
The question boards are asking
Somewhere in the past twelve months, every board with a meaningful AI programme has asked a version of the same question: if something goes wrong with our AI agent, can we stop it?
The question is correct. It is exactly the right thing to want to know. The problem is the answer almost every engineering team gives.
“Yes, we can stop the container.” “We can revoke the API key.” “We have a monitoring dashboard and an on-call rotation.” Sometimes: “We can just turn it off.”
These answers describe a power switch. A governance kill switch is a different thing, and confusing the two is how organisations discover the gap under pressure rather than before it.
What a power switch actually stops
Stopping a container terminates execution. The agent stops processing. This is useful in the way that unplugging a server is useful: the machine stops, but nothing about what happened before the stop is resolved.
If your AI agent has spent the past four hours executing against a customer dataset, and you stop the container at hour four, you have halted the process. You have not:
- Determined whether the actions taken in the prior four hours were within the authorised scope
- Established who authorised the task and on what terms
- Created a recoverable audit trail that shows which decisions were made under which conditions
- Ensured that downstream systems that received outputs from those four hours are not continuing to act on them
A power switch produces a stopped system, not an accountable one. Governance requires the second, not only the first.
The three things a deterministic kill switch actually requires
Deterministic human override, what the IMDA’s Model AI Governance Framework for Agentic AI calls enforcing human approval through system-level controls rather than prompt-layer guardrails, requires three components. Each one has to be present for the overall control to hold.
Trigger conditions that are technically encoded, not procedurally described.
The control starts before execution, not when something goes wrong. A deterministic kill switch requires a defined set of conditions under which autonomous execution is not permitted, expressed as technical constraints the system checks before proceeding, not as policy language the system reads and interprets.
“If the agent is about to access more than 10,000 customer records, execution halts” is a trigger condition. “The agent should avoid processing large datasets without oversight” is a policy statement. The first stops the system. The second hopes the model complies.
Most AI governance programmes have produced the second. The question a risk executive should ask is: where are the trigger conditions in the codebase?
An override authority matrix that names a person, not a role.
When a trigger condition fires and execution halts, the system has to know who is authorised to resume it. “The risk team” is not a sufficient answer. The risk team is a group of people whose availability varies. A deterministic control names a person, and in most production deployments, a secondary.
The override authority matrix, per system and per trigger condition, specifies: who holds the kill switch, who holds it if the primary is unavailable, and under what conditions override is permitted at all. If the matrix does not exist as a document with named individuals, the system does not have a kill switch. It has a process that depends on someone knowing who to call.
A halt mechanism the agent cannot route around.
This is where most current implementations fail, and it is the reason the IMDA framework specifically says human approval must be enforced architecturally, not through prompts.
A prompt that instructs an agent to seek approval before proceeding creates a soft halt. The agent reads the instruction as part of its context. That instruction competes with everything else in the agent’s context, including tool outputs, accumulated reasoning, and any subsequent instructions it receives. Under pressure, under adversarial input, or simply under model drift, a soft halt can be bypassed.
A hard halt is architectural: the execution environment itself requires an external signal before execution can resume. The agent does not decide whether to comply. The system does not proceed until a human ratifier has provided explicit authorisation through a channel outside the agent’s own context. This is what Aivance calls the Suspended Handoff State: not a behavioural constraint on the agent, but a technical precondition on execution.
The difference matters under exactly the conditions where override is needed most: when the agent is behaving unexpectedly, when inputs are adversarial, or when the situation has moved beyond the original scope. A soft halt is least reliable precisely when reliability matters most.
Why most agentic deployments do not have this
The components above are not difficult to understand. They are difficult to build, because they require governance to be present at the architecture stage, not after deployment.
A team building an agentic system makes dozens of decisions before launch: how tool calls are authorised, what the agent’s memory architecture looks like, what gets logged, how task scope is defined, whether there is a gated commit cycle for changes to the agent’s instructions. Each of those decisions either encodes a governance control or assumes the default, which is generally to proceed.
By the time a governance function reviews the deployment, those decisions have already been made. Retrofitting a deterministic halt onto a system designed for fluent execution requires changing the architecture, not adding a configuration flag. Most organisations do not do it. They add monitoring instead, and treat the dashboard as the kill switch.
Monitoring tells you what happened. It does not stop what is happening.
What the regulators now expect
Singapore’s AI regulatory environment has moved specifically on this point.
The IMDA’s MGF v1.5 addresses AI agents directly, including a four-dimension framework for agentic AI governance. On human oversight, it states explicitly that approval mechanisms should be enforced at the system level, citing cases where application-layer guardrails were insufficient. The Terminal 3 payroll agent case study in the accompanying Google sandbox report is the clearest published example: hardware-speed verification and immutable audit logs, not prompt-level instructions, are what make that implementation hold.
MAS’s proposed AIRG Guidelines, under which Singapore-regulated financial institutions are preparing now, set expectations for human oversight that are operationally meaningful: board oversight, named override authority, and audit trails that reconstruct decisions at the level of a regulator examination, not a dashboard summary. The question “who holds the kill switch for each material AI system” is one a financial institution should be able to answer specifically and in writing.
The enforcement question for this is simple: if the agent’s designated human ratifier were unavailable right now, would the system halt and wait, or proceed?
If the answer is “proceed,” the system does not have a kill switch. It has a monitoring programme and a hope.
What this looks like in practice
Building a deterministic kill switch into an agentic deployment requires four things to be in place:
First, the trigger condition inventory: a list of the conditions under which autonomous execution requires human authorisation, expressed technically, reviewed against the risk materiality of the system. For a financial services agent touching credit decisions, this list is long. For an internal productivity assistant, it is shorter but still not zero.
Second, the override authority matrix: per trigger condition, the named primary and secondary authorisers, the channel through which override is granted, and the evidence that override leaves behind.
Third, the architectural halt: a mechanism at the execution layer that requires an external signal before proceeding once a trigger has fired. This is not a feature of the agent. It is a constraint on the environment in which the agent runs.
Fourth, the audit binding: every authorisation and every halt is recorded with the decision context that produced it, in a form that a regulator or an audit committee can examine. Not logged after the fact. Bound to the execution event before it completes.
The Override Architecture that combines these four components is not a sophisticated engineering problem. It is a governance and architecture problem that requires the two disciplines to work together before the system reaches production.
Aivance works with CROs, CISOs, and Enterprise Architects in Singapore and Southeast Asia to design override architecture into agentic AI deployments before production, not after an incident. The free 30-Minute Enforcement Gap Diagnosis maps whether your current agentic systems have a deterministic kill switch, or a monitoring programme. Book the diagnosis here.