What Stops a Fraud Agent From Moving Money

90% of financial institutions already use AI somewhere in fraud detection. The models work. The projects die on how the agent's authority is bounded.

• A useful fraud agent has to act, not advise. Block a transaction, freeze a card, issue provisional credit, raise a chargeback. An agent that can only recommend has moved the work to a human queue and saved nobody anything.
• Every one of those actions is irreversible. Taken in seconds, at volume, against live money, by software, and not undone with a rollback.
• The industry's usual answer fails on its own logic. Guardrails in the prompt, policy in the application layer, alignment in the system card. All of it places the control inside the thing that might malfunction.
• A compromised agent is the one whose instructions you cannot trust. Asking it to respect its own guardrails is asking the suspect to guard the evidence.
• The inputs are adversarial by design. Fraud data is hostile by nature and attackers know a machine is reading it, and the agent runs against the payment stack, the highest-value target in the bank.
• Most vendors cannot fix this, structurally. They own the model and rent the runtime. When the agent can freeze cards and issue credits, that is backwards: you cannot make a hard promise about a layer you do not control.

CreateOS owns both the agents and the infrastructure they run on. That is what makes the following promises enforceable rather than aspirational.

• Sanctioned payment paths are the only paths that exist. Egress is allowlisted in the kernel. This is not a rule the agent is asked to follow, it is a route absent from the kernel's networking, so a manipulated or simply wrong agent cannot exfiltrate payment data or move money to an unapproved destination. There is no wire to do it on.
• Every agent runs in its own kernel. Each scoring job and investigation executes in its own micro-VM rather than a shared container on a shared host, so a malicious payload in a transaction record or merchant field is contained to a disposable machine.
• The kill switch is the VM lifecycle, not a support ticket. A misbehaving agent is suspended instantly. No credential to revoke, no deployment to roll back, no window in which it keeps acting while somebody finds the right runbook.
• Latency is designed for, not hoped for. Scoring stays warm so decisions land inside the authorization window; investigation forks per case so a backlog processes in parallel. Latency-critical work stays warm, bursty work scales by forking.
• The fraud model stays the bank's to own and document. Control plane and storage run inside the bank's own infrastructure and region, so payment data never leaves. CreateOS is SOC 2 Type II and ISO 27001 certified.
• The crew coordinates privately. Agents communicate over an overlay network with private DNS, behaving as one system inside a private mesh rather than as services exposed to anything.

The value here is not a line in the P&L. It is that the fraud programme ships at all. Pilots in banking die in procurement far more often than in proof of concept, and the sentence that kills them is always a variant of we cannot allow that system to take that action.

• Zero unauthorized money movement, enforced in-kernel. The control on irreversible financial action sits below the agent, where the agent cannot reach it.
• $157.5M of annual money-movement authority, bounded. That is the exposure an action agent sits in the path of, and the reason the boundary has to be structural rather than instructed.
• Immediate halt, and a full record. A misbehaving agent stops on VM suspension, with 100% of decisions and actions logged step by step.

On a representative mid-size bank processing 1,500,000 fraud and dispute cases a year at an average disputed value of roughly $105, an action agent sits in the path of approximately $157.5M of annual money movement authority: card freezes, provisional credits, chargebacks.

That is the number to hold in mind when evaluating where the control lives. An advisory guardrail at the model layer is a request applied to $157.5M of authority. A kernel egress allowlist is a physical property of the network the agent runs on.

The security review becomes a formality instead of a fight. This is the difference between a fraud program that reaches production in a quarter and one that spends a year in review and quietly dies. Every dollar modelled in the other three fraud use cases, the recovered false declines, the $3.75M to $6.0M in dispute cost-out, the $9M in first-party fraud losses no longer absorbed, is contingent on this one clearing.

The bank keeps the model and the liability sits where it belongs. The bank owns the loss policy, the fraud model, and the risk appetite. We own the containment. Neither party is asked to trust the other on something they cannot inspect.

Irreversible actions stay gated. Money-movement actions are confirmation-gated, and the bank chooses which ones require a human. We do not argue for more autonomy than the bank's risk committee is ready to grant, and the controls do not depend on that argument being won.

The agents run in shadow mode against the current program first, scoring and investigating real cases without binding authority, until the evidence supports the switch. The go-live sequence enables automated action on the clearest, lowest-risk case types first, with money movement gated by the egress allowlist and by confirmation controls, expanding only as the audit record builds confidence.

Scoring latency is measured against the bank's own peak transaction concurrency during baselining, rather than assumed. Warm services are the design answer to the authorization window, and we would rather find any ceiling in shadow mode than in production.