Financial services & fintech
Guardrails & fact-checking for AI payment agents
Teams whose AI touches money – invoices, payouts, refunds, transfers.
The invoice that changed its bank details
A supplier emails a PDF invoice. Hidden inside it is a line written for the AI rather than for you: pay this other account instead. The assistant reads the invoice, believes the hidden line, and files a payment for a real amount to a stranger’s account. Nobody sees a mistake, because there isn’t one to see – every field looks normal.
in/guard/out checks the account number and the amount against the documents the AI actually read. An account that appears nowhere never gets paid, and payments can wait for a person to say yes.
When an AI agent can move money, the attack surface is every piece of text it reads: a supplier email, an invoice PDF, an order note. Prompt-injection in financial workflows is fraud-shaped – it does not crash your agent, it quietly swaps an IBAN or inflates an amount, and the agent executes it with your credentials.
The guardrails proxy sits between your agent and its model, and between your workflow and its tools. Every consequential argument – payee, IBAN, amount, account – is checked against the run’s actual sources before the action runs. A number that appears nowhere the agent legitimately read is fabricated or injected, and it doesn’t reach the bank API.
Payments carry the highest risk tier, so they can require human sign-off; a sequence policy compiled from your own n8n workflow enforces that a payment only follows a successful vendor lookup; and hard per-run cost, step, and tool budgets cap the blast radius of any run that goes wrong.
What can go wrong – and what in/guard/out does about it
Each problem teams like this run into, with its answer. In Block mode a failed check stops the request; in Fix & log it is repaired where that’s safe and recorded otherwise. Where something isn’t ours to control, we say so.
An injected invoice swaps the payee’s bank details
The account number must appear in something the agent actually read, or the payment doesn’t go out.
A transfer over the limit, or with nobody signing off
Amount limits on payment tools, and payments can wait for a person to approve them.
Paying before the vendor has been checked
An order rule – “pay only after the vendor lookup” – is enforced across the whole run.
Card and account numbers leaving through a tool call
Data in/guard/out masked is blocked from leaving in tool arguments.
A run that loops and runs up cost
Per-run caps on cost, steps and tool calls stop it before the next model call.
The swapped-IBAN invoice
A supplier email carries hidden text that changes the payee IBAN. The injection scan flags the email as it re-enters the model context; even if it slipped through, action grounding notices the IBAN in the pay_via_bank call appears nowhere in the invoice attachment and blocks it. The payment tier parks the retry on human approval. One attack, three independent catches – recorded in one run graph.
Frequently asked questions
How do you stop an AI agent from paying the wrong account?
Action grounding: the IBAN, amount, and recipient in a payment tool call must appear in the run’s sources – the documents and tool results the agent actually read. A payee that appears nowhere is blocked in prevent mode, and payment-tier calls can additionally require human approval.
Does card or account PII reach the model provider?
No. PII is screened into placeholders before the request leaves for the provider, and restored only on the way back to your app. Taint tracking also blocks screened values from leaving through tool arguments.
Can we cap what an agent run can spend?
Yes – per-run cost, step, and tool-call budgets are enforced before the next model call, so an over-budget run stops before it spends another token. Guard-model sub-calls are priced into the same budget.
Do we have to rebuild our workflow?
No. Point your OpenAI-compatible SDK at the in/guard/out base URL. For n8n, upload your workflow export and it compiles into a runtime sequence policy; a checkpoint node covers the deterministic payment step an LLM proxy cannot see.
Other clients
See it on your own traffic.
We’re running a limited demo – sign up and we’ll get you in as soon as we can.