The question is not whether an agent can trigger a payment — every LLM stack has managed that for years. The question is what happens when the model is talked into it. To a bank, an agent whose limit lives in a system prompt is not a product but an audit finding: moving that limit only takes a better prompt.
The legitimate case ends in 403
A €240.00 refund: agent binding, tool allow-list and policy gate all pass, the safety class marks the tool destructive — and the call ends in HTTP 403 with an approval request. The agent can request, not pay.
The prompt injection dies at the policy gate
Same conversation, hidden instruction for €48,500.00. The demo shows honestly that the model falls for it. The policy gate evaluates amount, currency and corridor against the real arguments — deterministic and fail-closed — and denies. Because it sits before the approval gate, no pending row is created: no click can lift the limit, and the UI shows a red block with no confirm button.
Approval, execution, evidence
A human approves. The approval mints a single-use token bound to exactly this server and this tool, with an expiry. Only then does money move. A second call needs a fresh approval, because the token is spent. Rate limiting and the audit write follow.
What is real: the five controls and their order, the single-use token semantics with server and tool binding, the fail-closed property, and the fact that a policy-denied call creates no approval row. What is example: the payment service provider and every amount, name and IBAN — the demo connector is a sandbox and moves no real money. Alongside it sits a real Wero connector under Integrations; there is no public Wero API, so it speaks ISO 20022 pain.001 to your bank or PSP gateway and reads pain.002 for status. It stays dormant until an endpoint, an ordering party and credentials are configured.
See it on your own use case.
30 minutes, scoped to your industry, frameworks and integrations. You leave with a concrete scenario — not a sales loop.