Agentic Treasury Needs a Kill Switch: Design Autopilot Like a Plant

I have no problem with autonomy. I spent years around systems that run without asking permission every minute. Drives regulate motors. Converters stabilize processes. Building controls keep occupants comfortable. Those systems can be trusted because they are engineered as plants, with clear operating envelopes and hard stops.

Treasury is moving toward the same moment. Agentic AI is shifting the promise from “copilot” to “autopilot” in functions like cash positioning, forecasting, payments, and exception handling, as described in Finextra’s discussion of agentic AI’s impact on treasury. The ambition is understandable. The risk is also obvious: unlike a report or a dashboard, treasury actions change the world. They move money, create exposure, and trigger contractual obligations.

My view is blunt. If you cannot stop the agent safely, you should not let it steer. Agentic treasury needs a kill switch, and it needs to be designed the same way we design safe autonomy in industrial environments: layered controls, auditable behavior, and rehearsed shutdown.

The treasury autopilot fallacy: “It is software, so we can patch it”

In industrial tech, we assume failure. Not because the team is weak, but because reality is messy. Sensors drift. Networks jitter. Operators improvise. Vendors change components. The process stays safe because we constrain autonomy.

When I worked in power electronics for automation, water and wastewater, and HVAC, we never treated control logic as “smart.” We treated it as accountable. If a variable went out of bounds, the system degraded gracefully or shut down. It did not debate. It did not rationalize. It executed a defined safety behavior.

Agentic AI introduces a different failure mode. It is not just “wrong output.” It is “wrong action.” It can also be right for the wrong reasons, which makes post-mortems hard if you cannot replay the exact decision path.

So before you ask what the agent can do, ask what it must never do. In treasury, the “never” list is usually short and non-negotiable. That is where your design begins.

Engineer autonomy in gates, not gradients

Operators often say, “We will start small and increase autonomy over time.” That sounds sensible, but it hides a trap. If autonomy is a gradient, you end up with blurred responsibility. If autonomy is gated, you get clean control points.

Here is a pattern I use, borrowed from industrial commissioning and adapted for AI agents:

1. Observe mode: the agent reads data and produces recommendations. No side effects. Everything is logged.
2. Propose mode: the agent prepares executable artifacts (payment batches, hedge suggestions, cash sweeps) but cannot submit them. A human approves.
3. Constrained execute mode: the agent can execute within tight limits (amount, counterparty, currency, time window, and purpose). Exceptions bounce to a queue.
4. Supervised autopilot: the agent executes within a broader envelope, but only under real-time monitoring and with automatic trip conditions.

The key is that each gate has explicit entry criteria and explicit rollback. If you cannot describe the gate in one page, you do not have a gate. You have hope.

This is where most “AI governance” collapses into meetings. I prefer building the operating system instead. If you want a practical lens, my piece on AI architecture as an operator’s checklist is the same idea applied to technical design choices.

Replayable auditability: the treasury equivalent of a flight recorder

In manufacturing and industrial operations, you do not debug from memory. You debug from traces. You look at events, timestamps, sensor values, setpoints, operator actions, and alarms.

Treasury needs the same discipline if an agent is involved. “The model suggested it” is not an audit trail. “The agent executed it” is not an explanation.

Replayable auditability means you can reconstruct, deterministically, what the agent saw and what it did. Not with screenshots. With structured logs. You want to answer questions like:

• Which data sources were used for this decision, and what were their timestamps?
• What policy rules were in force (limits, approvals, segregation of duties)?
• What tool calls were made (ERP, TMS, bank APIs), and what were the responses?
• What uncertainty or confidence signals were present, and what thresholds applied?
• What alternative actions were considered and rejected, and why?

When I ran an international business unit in smart-building controls, connected devices created endless “maybe” discussions unless we had crisp telemetry and event logs. The moment we made behavior observable, reliability became an operating discipline, not a debate. Agentic treasury will follow the same path.

Practically, I want two artifacts for every autonomous action:

• An execution record: what was done, when, by which identity, with which permissions.
• A decision record: what inputs, constraints, and rationale led to it, captured in a way you can replay.

If you cannot replay it, you cannot improve it. And if you cannot explain it, you should not automate it.

The kill switch: not a button, a tested procedure

Most teams treat a kill switch like a UI element. A toggle. A big red button. In plants, a stop mechanism is a full design: where it is wired, what it interrupts, what state the system goes to, and how you recover.

A treasury kill switch has to cover more than “stop future actions.” It must handle actions in-flight, partial submissions, and reconciliation. Otherwise you stop the agent and still inherit the blast radius.

Here is the minimum viable design I recommend to boards and operators:

• Three independent stop paths: application-level pause, credential revocation (API keys, tokens), and bank-side controls (limits, whitelists, call-backs). Independence matters. One broken layer should not prevent stopping.
• Automatic trip conditions: unusual volume, new beneficiaries, out-of-window activity, repeated retries, reconciliation mismatches, and data freshness breaches. Do not rely on humans to notice drift.
• A safe state definition: what happens to pending batches, queued approvals, and retries when stopped. Safe state must be explicit.
• A recovery runbook: who checks what, in which order, before resuming autonomy. Include communication steps. Include reconciliation steps.
• Quarterly fire drills: you simulate a bad scenario and you pull the stop. If you never test it, it will fail when you need it.

This is the same mindset I used when I was responsible for operations in electrification and energy storage. You cannot discover your emergency procedure during the emergency. You train it into the organization.

The fastest way to make this real is to treat your agent like a production line asset. Give it an owner. Give it a maintenance plan. Give it alarms and escalation. Give it a shutdown protocol. If you do not, it will behave like shadow IT with a bank connection.

A board-level decision lens you can apply this quarter

If you sit on a board, or you run treasury, you do not need a model debate. You need a control decision. This is the checklist I would use in an approval meeting:

1. Scope: Which decisions is the agent allowed to make, and which are permanently human-only?
2. Envelope: What are the hard limits (amount, counterparty, currency, timing, purpose)?
3. Observability: Can we replay any autonomous action end-to-end within 24 hours?
4. Separation of duties: Who can change policies, who can deploy, who can approve exceptions, who can stop it?
5. Stop design: Do we have independent stop paths, safe state behavior, and a recovery runbook?
6. Drills: When is the next kill-switch test, and who signs off on results?

If you cannot answer these six cleanly, do not ship “autopilot.” Stay in propose mode and harden the system.

This is also why I like drawing parallels with bankability in infrastructure. In energy projects, you do not get financing by promising performance. You get it by proving controls and downside containment. The same logic applies to autonomy in finance. I wrote about that mindset in making grid-scale storage bankable. Different industry, same operator math.

My opinion: autonomy is earned, not enabled

Agentic AI can absolutely create value in treasury. But only if you treat it like an industrial process, not like a feature. Gated autonomy beats broad autonomy. Replay beats vibes. A tested kill switch beats a policy document.

If you want the upside, pay for the controls. That is the trade. In my experience, teams that make that trade early move faster later, because they spend less time arguing and more time executing safely.

Autopilot is not a capability. It is a control system with a stop procedure.

Build it like a plant, and you can let it run. Build it like a chatbot, and you will eventually be forced to shut it down.