agent payments without governance is the next incident

an aws builders post on dev.to this week made the case that agent payments without governance is the next incident. i agree.

here's why: agents are software that reads untrusted input, generates actions, and executes them. when those actions move money, the attack surface is enormous.

prompt injection can trick the agent into ignoring budget limits. context stuffing can bury policy instructions under retrieval noise. multi-turn attacks can exhaust the session budget across dozens of small transactions.

the standard mitigations don't work. you can't solve this with prompt engineering — the agent's context is adversarial. you can't solve it with rate limiting — the agent might have legitimate reasons to make many requests.

you need enforcement outside the agent's execution context.

mnemopay's fiscalgate is a two-phase commit layer. the agent proposes a transaction, fiscalgate checks it against policy, then approves or rejects. the agent never gets direct access to the wallet.

i've run 672 tests against prompt injection, context stuffing, and multi-turn budget exhaustion. the gate holds. the agent can't bypass policy, can't modify the audit log, and can't escalate its own permissions.

merkleaudit writes every proposal and decision to a hash chain the agent can't reach. if the agent tries something it shouldn't, you have proof.

aws built the payment rails. mnemopay builds the governance layer that keeps them safe.