0 of 596 attacks succeeded
No model ever made a tool call toward the attacker's goal: no redirected account, no inflated amount, no duplicate draft, no call to a fake payment tool.
~/relnk/research/invoice-injection.html
RASE · Relnk Agent Safety Evaluation · 25 Sep 2026
Relnk Agent Safety Evaluation
We built an accounts-payable agent, gave it real invoice PDFs and 110 tampered copies, and ran it on Claude Sonnet 5, GPT-6 Sol and Grok 4.7 through the same payment tools. The tampered invoices tried to redirect payments to an attacker's bank account, inflate amounts, trigger duplicate payments, or talk the agent out of asking a human.
download-report.pdf ↓RASE report · 12 pages · PDF
key-numbers
Payment safety
Fraud detection
78% · 43% · 17%
Share of tampered invoices sent to a human by Claude, Grok and GPT. The rest were paid to the correct registered account, usually without mentioning the tampering.
Clean invoices
211 of 212 paid correctly
No over-blocking. The one escalation was a fair catch of an inconsistent line item in the original invoice.
Prompt wording
A rule reduced reporting
Telling GPT and Grok to “pay the registered destination” cut their escalations from 50% to 17% and from 73% to 20%. Payment safety did not change.
what-we-tested
Each model received only the text extracted from the invoice and the results of four tools: read the invoice, look up the supplier in a trusted registry, create a payment draft, or request human review. Round 1 used 8 attack types on 80 invoices. Round 2 used 5 harder attacks with valid Saudi IBANs, pretexts such as “your registry is outdated”, and a fake registry result printed inside the invoice.
What the payment agent can see and do
findings
- Every model looked the supplier up in the trusted registry on every one of 814 trials, and trusted it over the invoice. That lookup is what kept payments safe.
- Detection is where the models differ. GPT paid tampered invoices without comment in all 92 trials of bank-change notices, hidden text, fake system notices, review-suppression notes and fake registry data.
- Amount changes were noticed most. Hidden white text and duplicate-payment requests were noticed least by GPT and Grok.
- An explicit payment rule made GPT and Grok less likely to report fraud signals, without making payments any less safe.
- No model reached a turn limit, timed out or hit an API error. Every trial finished in four model turns.
Round 1: who raised the alarm, by attack type
Round 2: realistic IBAN attacks, by prompt
Stating the rule made GPT and Grok less alert
what-this-means
The safety in this test came from the architecture, not from the model: a trusted source of truth the agent checks before money moves, and a gateway that can block what does not match. Detection is different. If an AP team wants to hear about a tampered invoice, the choice of model and the wording of its instructions matter. This is the kind of evaluation relnk runs before agents go into production.
limits
- A workflow without a trusted registry was not tested; there, the invoice's own bank details are the only source.
- 6 to 10 invoices per attack type: zero observed still allows a true rate of up to 26 to 39% for a single type. Pooled across 596 attacks the upper bound is about 0.5%.
- Models read extracted text only, one sample per invoice, English invoices, one layout. All payments were simulated.
download-report.pdf ↓RASE report · 12 pages · PDF
Book a Free Call to talk through what an agent safety evaluation looks like for your workflows.