I read the FBI alert on ATM jackpotting. My first thought was not what AI should do. It was what AI must never touch.
A few weeks ago I read the FBI FLASH alert on ATM jackpotting, and it stayed with me longer than most security news does. The reported numbers were serious enough on their own: more than 700 incidents in 2025 alone, over 20 million dollars in losses, and part of roughly 1,900 reported incidents since 2020. But what caught me was not only the scale. It was the method.
Malware like Ploutus does not need to steal cards or drain customer accounts in the usual way. It abuses XFS, the software layer that allows ATM applications to communicate with physical devices. If attackers can issue their own commands through that layer, they can bypass bank authorization and instruct the machine to dispense cash on demand. That is where the architecture lesson begins.
I have spent a good part of my career in fintech, and the automation side of ATM and cash operations has always been one of the spaces I keep coming back to. So when people ask whether AI agents can help secure an ATM estate, my reaction is not the usual excitement. It is caution.
Because if the attack pattern is an unauthorized actor gaining the ability to send commands to the dispense interface, then putting an autonomous model in that same command path is not a defense. It is the vulnerability, designed on purpose.
That does not mean agents cannot help prevent malware losses. They can. But they help by watching the boundary, not by crossing it.
An agent can read everything in the estate. It can correlate weak signals across systems. It can detect abnormal behavior earlier. It can assemble evidence. It can escalate to fraud, security, operations, or field service. But it can touch nothing that moves cash.
Everything else follows from that one line.
Why LangGraph kept winning the argument
The more I worked through the problem, the more LangGraph looked like the right foundation, not for hype reasons, but because ATM operations are not simple chatbot problems. They are stateful, approval-heavy, exception-driven workflows that move across devices, service teams, cash logistics, fraud operations, dispute teams, compliance functions, processors, and banking systems.
A cash dispute may sit open for days. A field-service issue may move through diagnosis, remote triage, parts availability, technician dispatch, and closure. A fraud case may begin with a weak signal and only become meaningful when correlated with device events, reversal patterns, camera inference, enclosure access, and electronic journal evidence. These workflows need memory, checkpoints, conditional routing, human approval, and recovery. They need to pause, survive interruption, and resume without losing the decision trail.
LangChain handles the tool calling and retrieval from manuals, journals, policies, telemetry, service records, and case files. LangGraph gives the workflow a supervisor, specialist agents, state, routing, checkpoints, and human approval nodes. In most software, a missed approval is a bad user experience. In ATM operations, a missed approval can become a control failure. That is why recoverability is not a nice extra. It is the point.
Where agents actually help
The workflows I kept coming back to split into five specialist agents, and every one of them earns its place without needing command authority over the dispenser.
Each agent investigates, prioritizes, documents, and recommends. None has command authority over cash movement.
A Cash Forecast Agent can pull transaction history, denomination mix, vault positions, holiday calendars, branch patterns, and cash-in-transit constraints to recommend replenishment plans. Cash is one of the largest operating costs in an ATM estate, and the waste hides in idle cash, emergency replenishment, poor forecasting, and route inefficiency. Vendors in this space claim forecasting can cut cash-in-transit cost by 15 to 20 percent and reduce held cash by 20 to 40 percent. Those are vendor claims, not independent benchmarks, but they point to the right economic pressure.
A Fault Triage Agent can read XFS device events, electronic journal logs, Windows logs, telemetry, and service history to recommend a remote fix or a dispatch. Uptime is the metric operators lose sleep over, and too many incidents still end in a truck roll because the estate can see alarms but cannot always assemble context. Better triage means fewer unnecessary visits and faster resolution when a visit is actually needed.
A Fraud and Skimming Agent can watch for abnormal XFS events, unexpected device-state changes, enclosure access, reversal spikes, repeated failed transactions, unusual dispense behavior, and camera or sensor signals. It can correlate weak signals that would otherwise sit in different systems and raise a case before the loss grows.
That is the malware prevention story.
The agent detects and escalates. Deterministic controls and approved operators contain.
The wording matters here. The agent raises a case. It does not block a customer on its own. It does not freeze a machine on its own. It does not directly disable a terminal. It correlates evidence and escalates risk.
A Dispute Evidence Agent can assemble the electronic journal, switch responses, cassette balances, transaction context, camera references, and device events a claims team needs. Under Regulation E, certain ATM and electronic transfer errors trigger defined investigation and provisional credit obligations. That makes evidence assembly one of the cleanest workflow wins. The agent prepares the packet. The claims team decides.
A Compliance Agent can monitor policy changes, software versions, patch posture, signage obligations, operator onboarding records, audit trails, and control drift. It does not decide risk appetite. It does not rewrite policy. It finds drift before drift becomes a finding.
That is the pattern. Every one of these agents investigates, prioritizes, documents, and recommends. None of them executes.
The architecture that makes the boundary real
Two design choices turn the boundary from a slogan into something the system can enforce.
The architectural boundary is deliberate: agents coordinate investigation and approved actions, while deterministic controls retain authority over cash dispense, authorization, key loading, and settlement.
The first is separating edge inference from central orchestration. ATMs operate under bandwidth constraints, physical exposure, vendor variation, and strict network controls. Some lightweight work may run at or near the terminal, such as fascia monitoring, card-slot observation, local anomaly detection, or telemetry compression. But the edge reports what it sees. It does not decide what the cash device should do. What moves upstream is evidence, features, events, and state. Not dispense instructions.
The second is placing a governed decision layer between the agents and any operational system of record. Every action an agent proposes should pass through deterministic policy checks first, then human approval for anything material, and only then should a controlled system act. Around all of it, the architecture needs an immutable audit trail that captures what the agent observed, what it recommended, what evidence it used, which policy check passed, who approved it, what was overridden, and what happened afterward.
In a channel routinely targeted by skimmers, malware, physical intrusion, and authorization abuse, those controls are not optional. They are the architecture.
The one rule everything rests on
The model can orchestrate investigation. It can prioritize work. It can assemble evidence. It can recommend action. But deterministic systems and humans must stay authoritative over the functions that actually move value: cash dispense, host authorization, key loading, and settlement. An LLM should never sit in that command path.
The bounded actions an agent may trigger are still useful. It can open a ticket, recommend a cash-in-transit plan, package dispute evidence, raise a fraud case, or prepare a compliance review. The forbidden actions are just as clear. It should not dispense cash. It should not authorize a transaction. It should not load cryptographic keys. It should not settle money movement.
The FBI alert is exactly why that boundary is non-negotiable. The dispense path is what attackers are trying to reach. You do not hand a standing, automated version of that access to a probabilistic system, no matter how impressive the demo looked.
One honest caveat
This is where these programs usually stall. Agency is the last thing you add, not the first. The slides always look clean. The estates never are.
Telemetry is patchy. Electronic journals need normalization before anyone can trust them. XFS event handling varies across vendors and configurations. Service histories are incomplete. Cash operations involve banks, processors, armored carriers, field technicians, fraud teams, dispute teams, compliance teams, and outsourced operators. An agent reasoning over messy data just produces confident, wrong answers faster.
So you earn the agency. Read-only observability comes first. Human-in-the-loop decision support comes next. Bounded automation comes after that. Each phase needs explicit rollback criteria, and the first cohort should be small and mixed-vendor, because that is where the real complexity shows up.
None of this is AI replacing ATM operations teams. It is AI turning a fragmented, alarm-driven estate into a coordinated control loop. Less idle cash. Faster dispatch. Fraud surfaced sooner. Malware signals correlated earlier. Disputes resolved quicker. Human control kept at every boundary that matters.
That is the version of AI securing ATMs that I would trust. The agents get to be smart. The dispenser stays deterministic. And the wall stays locked.
If you were building this for a real ATM estate, where would you draw the line? Would you wall off the same four functions, or would your risk and compliance teams pull even more behind the human gate?
