For payment and invoice approvals, treat the agent as an untrusted operator: it can prepare evidence and drafts, but it must not be able to send payments, approve invoices, or update payout destinations without machine-enforced gates. In Claw EA, you run the workflow on the OpenClaw baseline agent runtime, then enforce permissions with a WPC and job-scoped CST so the execution layer fails closed even if prompts are manipulated.
Prompt-only controls are not enough because prompts can be overridden by user input, injected invoice text, or tool output. Policy-as-code is how you force “dry-run only”, “two-person rule”, and “step-up approvals” at the tool and token boundary, with gateway receipts and a proof bundle to verify what actually happened.
Step-by-step runbook
-
Define the irreversible actions and split the workflow. Make “send payment”, “approve invoice”, and “update payout destination” separate steps from “collect invoice”, “match PO”, and “draft payment batch”. Keep irreversible actions behind explicit approval gates.
-
Write a WPC for payment approval work. Store a WPC = Work Policy Contract in the WPC registry (served by clawcontrols). Include: forced dry-run for payment tools, two-person rule, required approver roles, and caps for amount and vendor risk tier.
-
Issue a job-scoped CST for the run. Create a CST = scoped token (issued by clawscope) that is bound to the specific job and pinned to the WPC hash when you want strict policy immutability. This ensures a token minted for “draft-only” cannot later be replayed for “send payment” in another run.
-
Run the agent in a sandboxed tool environment. In OpenClaw, enable sandboxing for tool execution so file and process access is constrained. Keep elevated execution off for payment workflows unless you can justify it and you have compensating controls.
-
Force a dry-run phase and produce an approval packet. The agent generates a payment proposal: invoice metadata, matching results, exception notes, and a signed “intent” summary that includes vendor, amount, currency, and destination reference. The proposal is immutable input to the approval step (hash it and include the hash in the approval request).
-
Collect step-up approvals with a two-person rule. Route the approval to two distinct humans (for example AP manager plus controller). If you use Microsoft tooling, implement the approval workflow via official API and enforce identities with Entra ID, plus Conditional Access and PIM where appropriate for approver roles.
-
Execute payment only after approvals re-issue a new CST. After both approvals, mint a new CST with a narrower TTL and a higher-risk scope that allows only the exact payment action for the exact proposal hash. The agent executes the single irreversible step and then the token expires.
Threat model
Payment workflows fail when a model can directly reach payment rails or when it can change what humans think they approved. The controls below are operational and should be testable with red-team prompts and injected invoice content.
| Threat | What happens | Control (what you enforce) |
|---|---|---|
| Prompt injection via invoice text or email thread | The agent is convinced to skip checks, change amounts, or “approve now”. | WPC denies irreversible tools by default and forces dry-run. Approvals are required inputs, not optional instructions, and CST scopes prevent payment without the approval-bound token. |
| Payout destination manipulation | The agent updates bank details or swaps destination IDs before payment. | WPC blocks “update payout destination” entirely or requires a separate step-up approval and a separate CST. Approval packet includes destination reference and hash so changes are detectable. |
| Approval spoofing or ambiguous assent | A single person approval is treated as enough, or a chat message is mistaken for approval. | Two-person rule in WPC plus explicit approver identities (Entra ID) and a required approval object that binds to the proposal hash. No “free-form text means approved”. |
| Tool overreach from broad credentials | The agent can do more than intended if it obtains a powerful credential or token. | CST minted per job with minimal scope and short TTL. Optional policy hash pinning ensures the token is only valid under the specific WPC hash. |
| Replay of a previously valid payment token | A captured token is used to send another payment later. | Marketplace anti-replay binding (job-scoped CST binding) and short TTL. Require proposal-hash binding in the WPC so the token is useless for any other payload. |
| Unverifiable model behavior after an incident | You cannot prove what prompts and model calls caused the payment. | All model calls routed through clawproxy produce gateway receipts. The run emits a proof bundle for audit and verification, and can be stored as a Trust Pulse artifact for viewing. |
Policy-as-code example
This is a compact JSON-like example of the intent you encode in a WPC. Your real WPC will include your internal role names, risk tiers, and the exact tool names exposed in your OpenClaw deployment.
{
"wpc_version": "v1",
"workflow": "payment_and_invoice_approval",
"risk": "high",
"irreversible_actions": [
"send_payment",
"approve_invoice",
"update_payout_destination"
],
"defaults": {
"mode": "dry_run_only",
"require_evidence_packet": true
},
"approvals": {
"step_up_required_for": ["send_payment", "approve_invoice", "update_payout_destination"],
"two_person_rule": true,
"approver_identities": {
"provider": "EntraID",
"roles_allowed": ["AP_Manager", "Controller"]
},
"binding": {
"must_match_proposal_hash": true
}
},
"token_constraints": {
"require_cst": true,
"cst_ttl_seconds_max": 900,
"require_job_scoped_binding": true,
"optional_policy_hash_pinning": true
},
"limits": {
"max_amount_per_payment": 25000,
"max_payments_per_run": 20,
"token_cost_budget": {
"model_calls_max": 200
}
},
"model_routing": {
"require_clawproxy_receipts": true
}
}
Why this must be enforced as policy-as-code: if an attacker can influence the prompt, they can influence the agent’s “intent”. A WPC gives you a signed, hash-addressed policy artifact that tools and proxies can verify, so execution is permissioned even when the model output is adversarial.
What proof do you get?
Every model call routed through clawproxy yields gateway receipts that can be verified later. Receipts let you answer: which model was called, when, under which CST scope hash, and under which policy hash pinning (when enabled).
Each run emits a proof bundle that packages the gateway receipts plus run metadata, including the job binding needed to detect replay. For audit and review workflows, the proof bundle can be stored as a Trust Pulse artifact so reviewers can view what was executed and what controls were in force.
Rollback posture
Payments are not safely “rollbackable” in the same sense as database writes, so your rollback posture should focus on fail-closed execution, fast containment, and evidence preservation. Use dry-run by default and only mint “execute” CST after approvals, so the most common failure mode is “no payment sent”.
| Action | Safe rollback | Evidence |
|---|---|---|
| Invoice review and matching | Discard drafts and rerun under a stricter WPC. Keep the original proposal hash to compare deltas. | Proof bundle with gateway receipts showing the model calls used for extraction and matching. |
| Approval collection | Invalidate pending approvals and require re-approval if any proposal field changes (amount, vendor, destination reference). | Approval packet bound to proposal hash, plus proof bundle metadata tying the run to job-scoped CST binding. |
| Send payment | Containment: revoke or let execute-token TTL expire, freeze further runs, then use the payment provider’s reversal or recall process if available. | Gateway receipts for model calls leading to the execution step, plus the proof bundle proving which WPC and CST were used. |
| Update payout destination | Revert to last known good destination via official API, then require a separate two-person approval for any future destination changes. | Proof bundle showing the request sequence, including the policy gates that required step-up approval. |
FAQ
Can the agent ever be allowed to send payments directly?
Only if you treat “send payment” as a separate, approval-bound capability and mint a dedicated CST for that single action. In practice, most teams keep default mode as dry-run and require step-up approvals for any irreversible call.
Why is prompt-only approval logic unsafe for invoice approvals?
Because the prompt is not a control boundary. Invoice PDFs, vendor emails, and chat users can inject instructions that override the intended procedure, while policy-as-code is verified by the execution layer (WPC plus CST constraints) and can fail closed.
How do you implement the two-person rule in Microsoft environments?
Use Entra ID identities for approvers and implement the approval capture via official API in your workflow system. Apply Conditional Access and PIM to reduce the chance that a compromised account can satisfy both approvals.
What should be included in the approval packet?
At minimum: vendor identity, invoice ID, amount and currency, destination reference, supporting documents, and an exceptions list. Hash the packet and require the hash match at execution so the agent cannot switch details after approval.
What proof is available if finance disputes a payment later?
You can provide the proof bundle for the run, including gateway receipts emitted by clawproxy for the model calls. This gives a verifiable record of policy context (WPC hash) and token context (CST scope hash) that governed the execution.