The problem AI Payflow solves

Accounts payable is slow, and the obvious fix is dangerous.

Paying suppliers is repetitive judgment work: read the invoice, check the supplier is real, check the wallet is the one on file, decide whether paying today still leaves enough cash for payroll, catch the 2% early-payment discount before it expires. Finance teams do this by hand across inboxes and spreadsheets, so invoices sit unpaid, discounts lapse, late fees accrue, and nobody has a live answer to "can we afford this right now."

The tempting fix is to hand it to an AI agent. That's the dangerous part. Today an agent's spending authority lives in its prompt and its API key — both of which an attacker can reach. A prompt injection buried in an invoice PDF, a hijacked supplier email thread, or a plain hallucination, and the money is already gone. Invoice-redirection fraud is one of the most expensive attacks in business today; an autonomous agent with a wallet just makes it faster.

AI Payflow's answer: let the AI decide, but never let it be the authority.

The model does judgment — parsing invoices, forecasting cash position, weighing discounts, flagging anomalies. The Sui smart contract decides what actually happens. Every payment is judged by ten checks before a coin moves, and the agent's capability object has no mutable field at all, so even an attacker in full control of the prompt and the API key cannot raise a limit, approve a supplier, or reach the vault.

Built for finance and ops teams processing recurring supplier invoices — and for anyone piloting AI agents with real spending authority who needs the limits to live somewhere the agent cannot edit them.

Challenges we ran into

The bug: we shipped an approver capability we could never take back.

Large payments need a human signature, so we issued each approver an ApproverCap — an owned object carrying its own max_single ceiling. It looked right, it tested fine, and we deployed it to testnet.

Then we tried to lower one approver's limit and hit a wall that isn't a bug in our code, it's how Sui works: only an object's owner may mutate an object. Once that cap was transferred, the admin couldn't touch it. We couldn't lower the ceiling, and we couldn't revoke it — there was no revocation function in the module, and there couldn't be one, because revoking means mutating an object we no longer owned. The cap sitting live on testnet authorized $25,000,000 against a vault holding $88,200.

The fix was a principle we'd already applied elsewhere and failed to apply here: state the admin owns is state the admin can change. Agent limits were never inside AgentCap — they live in Treasury.agents, which is exactly why an agent can't rewrite them. Approvers needed the same shape. We wrote approve_scoped, which keys authority by the approver's address in treasury state: per-payment ceiling, daily ceiling, expiry, recipient allowlist, enabled flag — all mutable by the admin.