Finance agents are about to run the money. The controls were built for clerks.
Vandal is the control layer for companies handing accounts payable to AI agents. It checks every action before money moves, and it keeps attacking its own checks so they get stronger with every change.
Why now
Agents are taking over accounts payable
Reading invoices, matching purchase orders, updating vendor bank details, paying on schedule. The work is repetitive, well-documented, and expensive to do by hand, so it is going first.
The controls assume a human is reading
Three-way match, approval thresholds, callback policies. They were written for a clerk who might notice a lookalike domain. An agent that follows instructions faithfully follows forged ones too.
Security has to attack itself
Every change to an agent, a prompt, or a policy opens new paths. A control layer that cannot search for its own gaps will be wrong within a quarter. Vandal searches, fixes, proves, and only then enforces.
How it works
Vandal Guard
Sits in the live path. Before any money moves it checks the action the agent is taking, a payment, a bank change, a refund, a journal entry, against an independent source of truth, then allows it, holds it, or escalates it to a human, and records the evidence.
Vandal Strike
Clones the company into a deterministic financial twin and searches for sequences of events that break the invariants. When it finds one, it computes the root cause from the authorization chain, synthesizes a control that closes the gap, and verifies it on fresh clones before anyone sees it.
The loop
Every gap Strike finds becomes a control Guard enforces. Fixes go into Guard's rules, never into the agent: no retraining, no prompt edits. A human approves each rule. The protection holds whichever agent does the work.
Watch the loop run on a simulated property manager, or open the workspace and point it at a company of your own description.
What is real, what is simulated, and how we know
| Real | Simulated | How we know it works |
|---|---|---|
| A double-entry ledger, the financial invariants, the policy gate, bounded search, and CEGIS verification: deterministic code with tests. | The company, its vendors, its bank accounts, and the money. | Hidden oracle labels act as an answer key that no agent can read. |
| Claude reading every document, proposing controls, and explaining decisions with citations. | Callbacks, deepfakes, and counterparty agents, modelled as channel events with forgeable attributes. No synthetic media. | Held-out variants the synthesizer never saw, plus a re-search under the new policy. |
| The synthesizer proposing controls, and search refuting or accepting them. | Bank behaviour and faults: timeouts, dropped acknowledgements, late feeds. | The scorecard: before-and-after rates from actual runs. |
| Replay of any recorded trace. | Approvers, when no human is present. | Replay-determinism tests in the backend suite. |
What we can and cannot claim
| We can say | We do not say |
|---|---|
| No violating sequence of length ≤ k within the modelled actions and capabilities. | Mathematically proven safe. |
| The root cause is computed from the authorization chain. | Finds every possible failure. |
| The control was verified by replay, re-search, held-out variants, and regression. | Works on your real systems today. |
| Exposure, measured on the twin. | Losses prevented. |
| Synthesizes controls from a bounded template library. | Rewrites arbitrary financial software. |
Every number on this site is measured by running the books on fresh clones against a hidden answer key. None is typed in. The scorecard from an actual run, and the tests behind it, are in the repository.
Read the design
Who is building it
- Angad Arora
- Mohith Ram Narendra Babu
Two people, one repository, and a demo you can run yourself. Talk to us if your company is handing payables to an agent, or about to.