提示詞之前先有政策：為自主 AI 智能體強制執行機器可讀財務規則
Policy Before Prompt: Enforcing Machine-Readable Financial Rules on Autonomous AI Agents
自主財務 AI 智能體的付款權限須由可信後端按機器可讀政策核驗，不能只依賴提示詞或智能體提交的欄位。執行前須從權威服務取得關鍵資料，並明確取得允許決定。共享額度須以原子方式預留，審批及冪等記錄須綁定固定交易資料；支付結果不確定時，則須按支援的恢復流程處理。
An autonomous financial agent receives a simple instruction: pay approved suppliers before their invoices become overdue.
It identifies an invoice, checks the beneficiary, and proposes a transfer. The reasoning looks sensible. But does the customer’s delegation permit the payment? Have the beneficiary’s bank details changed? Has another worker already consumed the remaining spending allowance?
A prompt can describe these constraints. Trusted services must enforce them.
The Problem
“Policy before prompt” describes an order of authority. Financial rules remain authoritative regardless of what the model generates.
The agent proposes a structured operation. The backend verifies resource ownership, retrieves authoritative context, evaluates policy, and satisfies execution conditions.
Fields such as supplier_approved or approval_complete must not become trusted merely because the agent supplies valid JSON.
Likewise, authenticating the agent workload does not establish which customer delegated authority or which accounts that delegation covers.
Where It Gets Difficult
An allow decision does not reserve a budget. Suppose two workers each propose ₹20,000 payments against a remaining allowance of ₹30,000. Both can pass policy evaluation against the same snapshot. An atomic reservation mechanism must coordinate their combined consumption.
Approval must match execution. Human approval should bind to a specific version of the transaction details. Changing the amount, fees, or beneficiary’s underlying bank details should invalidate the previous approval.
A timeout does not establish payment failure. The provider may have accepted the operation before the response was lost. Creating a replacement transfer can produce a duplicate.
Current policy can still receive stale facts. Policy freshness and the freshness of delegation, approval, and beneficiary data require separate controls.
Architectural Direction
A practical execution path should:
- Retrieve decision-critical facts from authoritative services.
- Require an explicit successful allow decision.
- Reserve shared allowances atomically.
- Bind approvals and idempotency records to fixed transaction details.
- Resolve uncertain provider outcomes through supported recovery procedures.
Enforcement belongs at the financial execution boundary. An early tool-call check helps, but another caller must not be able to bypass the same controls.
The Takeaway
Authorization establishes permission. Transaction coordination and recovery carry that permission through execution.
Machine-readable policy makes financial authority explicit and reviewable. Its effectiveness still depends on trusted inputs, enforced boundaries, and reliable payment state management.
For the full architectural breakdown, Rego example, approval design, and operational considerations:
來源：DEV Community · dev.to