How do I enforce segregation of duties so an AI agent cannot both create and approve a payment?

What should I check, step by step?

1. Name the two roles for every money move: creator (drafts or submits the payment request) and approver/settler (may authorize release). Write that the same principal_id and the same credential must never hold both.

2. Issue separate credentials: an agent key that can call request_human_approval (or create a pending payment) but cannot call decide_human_approval or hold the owner/approver key; an owner or second-agent key that alone can decide and that authorize_spend will accept for settlement.
3. Put create_principal_id (and optional create_credential_id) inside the action object the approval hashes. Reject any decide_human_approval where the approver equals the creator, and reject any settlement where the settler equals the creator.
4. Show the approver the same payee, amount, currency, rail and memo the creator submitted — not a rewritten chat summary. Hash those fields (RFC 8785 JCS then sha256) so a quiet change fails verify_human_approval.
5. At release, recompute the action hash, verify_human_approval against it, confirm approver_id ≠ create_principal_id, then call authorize_spend under the approver/settler credential only.
6. Write create and approve events as separate ledger entries (who, when, action hash, decision). The agent's API key must not UPDATE or DELETE either row.
7. Drill it: attempt self-approval with the agent key, attempt approve-with-creator-id, change amount between create and approve, and confirm every path denies.
8. Keep vendor or bank-detail changes on a third path or under the approver role — a creator that can also re-point payout accounts defeats the split.

Why create and approve must be different principals

If one agent credential can both queue a payment and mark it approved, a prompt injection, a fake invoice, or a compromised key completes the whole path alone. Segregation of duties (SoD) exists so no single actor finishes a sensitive money move by itself.

• NIST SP 800-53 Rev. 5 AC-5 (separation of duties) is the control language: divide duties so the person or process that initiates a transaction is not the one that authorizes it. For agents, that means separate principal ids and separate credentials, not two prompts in one session.
• How to keep segregation of duties when an AI agent pays bills covers accounting-system roles (clerk vs approver vs payer in QuickBooks). This page is the create-vs-approve credential and ledger split for any agent payment path, including wallets and APIs outside the books.

How this differs from four-eyes, quote-bound and named-approver controls

Four-eyes requires two independent humans on one action hash — still useful for high-impact moves, but it does not by itself stop the creator from being one of the approvers unless you also enforce the role split.

• Quote-bound approval binds a yes to a quoted amount and payee so settlement cannot drift. Named-approver pages record which human said yes and which policy version. Keep those; add SoD so the creator credential is never eligible to approve or settle.
• request_human_approval hashes the action you send (include create_principal_id); decide_human_approval needs the owner or designated approver key and refuses delegated agent keys that would let the creator approve itself; verify_human_approval is free and fails when the bound fields no longer match.

Recording both identities and gating settlement

Ledger both events: payment_request_created (create_principal_id, credential_id, action hash, amount, payee) and payment_approved or payment_denied (approve_principal_id, decision, same action hash). Denials matter as much as approvals.

• authorize_spend should run only under the settler/approver credential after a matching verified approval. set_spend_policy on that credential still caps per-tx and daily totals so a wrong yes cannot empty the wallet.
• ledger_verify is free and keyless: it recomputes every payload, leaf and block hash so an edited create or approve entry shows up. Pair with record_ai_run when you need the model output that produced the draft tied to the same trail.