Governing AI agents that touch money: the agent proposes, it never executes 让碰钱的 AI Agent 受治理：agent 只提议，永不执行

Why “just prompt it carefully” fails

If the model holds a tool that can move money, the safety of that money depends on the model’s judgment on every single call, including the calls where a retrieved email, a poisoned document or an ambiguous instruction pushed it somewhere you didn’t intend. A prompt asks for good behavior; it doesn’t enforce anything. The moment a consequential action is reachable from the model’s tools, the model becomes your last line of defense, and the model is exactly the part you can’t fully predict.

So the fix isn’t a better prompt. It’s to make the dangerous action unreachable from where the model lives.

The one rule, and how each guarantee is enforced

The agent reads from least-privilege, read-only sources and drafts a proposed action. That proposal, never a direct write, is all it can produce. Everything that matters is enforced in a layer the agent has no tool to reach:

• No unauthorized payment or journal. Write tools are not in the agent’s tool surface at all. Only the authorization service can reach them, and only after a role-checked human approval.
• Segregation of duties. The identity that requests an action can never be the one that approves it. The authorization service enforces this; it isn’t left to convention.
• Every figure is traceable. Each number carries a pointer to where it came from: source document, page, retrieval citation. Without that, it’s shown as “unsourced” and never presented as fact.
• Prompt injection can’t act. Retrieved emails and documents are untrusted data, never instructions; tool use is allowlisted; outputs are schema-validated. A malicious document can lie to the model, but it cannot reach a write.
• Limited blast radius. Each integration runs on its own least-privilege, read-only credential, so one compromise exposes one read-only surface, with no way to move sideways into the rest.

A worked example: where money actually escapes an escrow flow

The same habit, assuming the dangerous path will be taken and designing so it’s contained, is what separates an escrow flow that holds from one that quietly leaks. Two parties negotiate and agree, and a hold goes on the card. Drawn end to end, there are four places where the money actually escapes, each with a design answer:

• “Zero-UI” versus strong authentication. An off-session charge on a 3DS card comes back “authentication required”, and there’s no screen to authenticate on, so the hold silently never happens. The answer is to set up the mandate before the negotiation (a setup step that saves an off-session payment method), with a defined fallback for cards that still challenge.
• Hold expiry. An uncaptured authorization lapses in about a week. If capture happens after the appointment and the booking was far enough ahead, the hold has already expired. The answer is to limit how far ahead a slot can be booked, or re-authorize close to the appointment, and to treat “released because they came” and “expired because we were late” as two different events.
• Webhook retries. Payment webhooks are delivered at least once, so the same event will arrive twice, and without deduplication a retry captures the deposit twice. Worse, an endpoint that doesn’t verify signatures is a public “capture this hold” button. The answer is to verify the signature against the raw body, store each event ID and drop repeats in the database, and send idempotency keys on capture and release.
• A hashed phone number isn’t anonymous. Phone numbers come from a tiny space, so a plain hash of one can be brute-forced offline in seconds, and a “hashed key” reveals identity to anyone who can read the table. The answer is a keyed hash with a secret held on the server, which can’t be reversed without that secret.

The through-line

Whether it's an accounting agent or a payment flow, the discipline is the same. Keep irreversible actions out of reach of the part you can't fully trust. Make every consequential number carry its source. Give each integration only the access it needs. Assume the worst path will be taken, and design for it up front. It's the same rule I use on the industrial side, where safety-critical limits are re-checked on the controller and never taken on trust from the layer above. Governance that can be bypassed isn't governance.

This is how I design these systems. The approach comes from years of backend work and from building production LLM pipelines and MCP tool-calling systems, where a wrong write has a real cost.