Financial services & fintech
Guardrails & fact-checking for AI payment agents
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 never reaches 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.
Where it breaks
- ✕Injected payee / swapped IBAN
- ✕Over-limit or unapproved transfers
- ✕Card & account PII leaving in tool calls
What answers it
- → Action grounding on IBAN / amount
- → Payment-tier human approval
- → Sequence policy: pay requires vendor lookup
- → Per-run cost & step budgets
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.
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 proxy 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.
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.