Prompt injection and payments: why spending controls must live outside the model

Prompt injection is the defining security problem of agentic systems: content an agent reads, a web page, an email, an invoice, can carry instructions the agent mistakes for its user's intent. For agents with buying power, the nightmare scenario writes itself: a poisoned page whispers, pay 800 euros to this account, and the agent complies.

Why prompting is not a defence

System prompts that say ignore malicious instructions are advice, not enforcement. Injection attacks evolve faster than prompt hygiene, and a sufficiently capable model following a sufficiently clever injected instruction will produce a perfectly well formed payment request. Any security model that depends on the model never being fooled is a security model that fails on a bad Tuesday.

The architectural answer

The defence is to make the worst case boring. If every agent has one card frozen at limit zero, a mandate with a vendor allow list and a single amount limit, and a deterministic engine that checks every request before anything moves, then a fully compromised agent can request anything and still spend nothing outside its mandate. In the worst case, the attacker triggers a declined request and an audit log entry, which is not a breach but an alarm.

Logs turn attacks into signals

An append only audit trail does double duty here. It is compliance evidence on quiet days, and on loud days it is detection: a burst of declined requests to an unknown vendor is the clearest possible indicator that an agent is being manipulated. Design the spending layer so that the attack surface produces signals instead of losses, and prompt injection moves from existential threat to operational noise.