AI agents are moving from drafting work to executing work: creating tickets, sending messages, updating CRM stages, approving refunds, buying inventory, creating invoices, dispatching workflows, and calling APIs. The commercial opportunity is obvious, but so is the risk: if every action needs a human confirm click, the agent is not operationally useful; if no action has a gate, one bad instruction can create expensive cleanup.
Use this checklist to define which agent actions can run automatically, which require approval, which must be rate-limited, and what evidence must be logged before an agent can transact on behalf of a business.
The 12-minute quick pass
Before an AI agent can execute a business transaction, answer these eight questions:
- What counts as a transaction? Define the actions that change money, records, customer state, inventory, appointments, messages, or access.
- Who owns the risk? Name the human owner for each action family.
- What is the maximum automatic value? Set dollar, record-count, customer-impact, and frequency limits.
- What must always be human-approved? Include refunds above threshold, outbound customer messages, destructive changes, access changes, and legal/payment settings.
- How are duplicates detected? Define idempotency keys, recent-action checks, or same-customer cooldowns.
- What evidence is logged? Capture request, policy match, tool call, result, timestamp, and rollback reference.
- What is the emergency brake? Give an owner-editable switch that stops future transactions without logging into the agent runtime.
- What review cadence exists? Sample approved and auto-approved actions daily during rollout, then weekly.
Transaction risk tiers
| Tier | Agent action | Examples | Default gate |
|---|---|---|---|
| Tier 0 — Draft only | Prepares action but does not send or mutate | Draft email, proposed refund note, CRM update suggestion | No approval beyond initial scope |
| Tier 1 — Low-impact internal update | Changes internal status with easy rollback | Add tag, create task, update non-customer-facing note | Auto-approve with audit log |
| Tier 2 — Customer-visible but reversible | Sends or updates something visible but low-risk | Appointment reminder, support follow-up, quote-status email | Auto-approve only after tests + limits |
| Tier 3 — Financial or access-affecting | Moves money, credits, inventory, permissions | Refund, paid order, discount code, account role | Human approval above tiny limits |
| Tier 4 — Destructive or legal/account change | Hard to reverse or high blast radius | Delete records, rotate keys, change DNS/payment/legal settings | Human approval every time |
Default rule: agents may auto-execute Tier 1 actions first. Tier 2 requires a tested rollback and duplicate guard. Tier 3 requires explicit thresholds. Tier 4 stays manual.
Approval policy template
Copy this into the client/project runbook before enabling agent transactions.
Policy name: Business owner: Agent/workflow name: Systems in scope: Transaction types allowed: Transaction types prohibited: Auto-approval threshold: Human-approval threshold: Daily/weekly action limit: Duplicate-detection key: Required audit-log fields: Rollback method: Emergency brake location: Review cadence:
Example: support refund assistant
Policy name: Support refund assistant approval policy Business owner: Customer Ops Lead Agent/workflow name: Refund triage agent Systems in scope: helpdesk, Stripe test/live read, CRM notes Transaction types allowed: draft refund recommendation; add CRM note; create manager approval task Transaction types prohibited: issuing refunds directly; changing customer plan; sending legal language Auto-approval threshold: internal notes only Human-approval threshold: every refund, every plan/account change Daily/weekly action limit: 20 draft recommendations/day during pilot Duplicate-detection key: customer_id + invoice_id + requested_refund_amount Required audit-log fields: ticket_id, customer_id, invoice_id, policy tier, recommendation, evidence links, approver Rollback method: remove CRM note; close duplicate approval task; manager handles refund reversal if ever enabled Emergency brake location: REFUND_AGENT_ENABLED=false in workflow settings Review cadence: daily for first 10 business days
Transaction approval checklist
1. Define transaction boundaries
- Every mutating action is listed: create, update, delete, send, purchase, refund, approve, invite, revoke, publish, deploy.
- Each action has a named system: CRM, helpdesk, email, calendar, billing, warehouse, database, website, ad platform, code repo.
- Customer-visible actions are separated from internal-only actions.
- Financial, access, legal, and destructive actions are marked as approval-required by default.
- The agent has a written stop condition for ambiguous requests.
2. Set automatic-action limits
- Dollar limit per action and per day exists where money is involved.
- Record-count limit exists for CRM/database/bulk edits.
- Message-count and recipient-count limits exist for email/SMS/DM actions.
- Same-customer cooldown exists to prevent repeated touches.
- Time-of-day limit exists for customer-facing sends if relevant.
- Any limit breach creates a draft/approval task instead of executing.
3. Prevent duplicate or runaway transactions
- Idempotency key is defined before calling APIs.
- Recent-action lookup runs before execution.
- Retry logic distinguishes safe retry from duplicate execution.
- Failed execution writes a dead-letter record, not an infinite loop.
- Alert threshold exists for repeated attempts, repeated rejects, or repeated same-customer actions.
4. Require evidence for approval
- Approval requests show source evidence, not just agent reasoning.
- Approver sees exact proposed action, target record/customer, amount, message body, and rollback path.
- Approval is recorded with approver, timestamp, policy version, and action ID.
- The agent cannot approve its own approval request.
- The approval screen/task includes a one-click reject/escalate path.
5. Log every executed action
Minimum audit-log fields:
| Field | Why it matters |
|---|---|
| action_id | unique reference for rollback and support |
| policy_version | proves which rule allowed the action |
| actor_agent | names the agent/workflow/tool |
| human_owner | person accountable for policy |
| target_record | customer/order/ticket/invoice/workflow touched |
| policy_tier | shows automatic vs approval-required path |
| input_evidence | source links, IDs, snippets, or attachments |
| decision_reason | concise rule-based explanation |
| execution_result | success/failure, API response summary, timestamp |
| rollback_reference | how to undo or compensate |
6. Install the emergency brake
- Owner can disable transactions without editing agent prompts.
- Brake is outside the agent runtime where possible: env flag, workflow variable, feature flag, database setting, or integration permission.
- Brake has a visible current state.
- Brake is tested before launch.
- Agent reports brake-on as a blocker, not as a problem to bypass.
Human approval request template
Subject: Approval needed: {agent_name} wants to execute {transaction_type}
Policy: {policy_name} / {policy_version}
Risk tier: {tier}
Target: {customer_or_record}
Proposed action: {plain_english_action}
Amount / impact: {value_or_scope}
Evidence: {links_or_record_ids}
Duplicate check: {idempotency_key_and_recent_action_result}
Rollback path: {rollback_method}
Approve by: {deadline_or_sla}
Reject/escalate if: {red_flags}
Red flags that should force manual review
- The agent cannot cite source evidence for the action.
- The target customer, amount, email body, or record ID is ambiguous.
- The action affects billing, refunds, permissions, legal terms, DNS, payment settings, or production credentials.
- The same customer or record has already been touched recently.
- The action is a bulk operation or uses a wildcard/search result as the target.
- The API response is partial, timed out, or returned an unknown state.
- The rollback path depends on a person remembering what happened.
Consultant monetization angle
Package this as an AI Transaction Governance Sprint:
- $350–$750 fixed fee: map transaction tiers, thresholds, and approval policy for one agent/workflow.
- $750–$2,000 implementation: add idempotency keys, audit-log table, approval tasks, and emergency brake.
- $500–$2,500/month retainer: weekly sample review, incident drills, policy tuning, and client handoff evidence.
The easiest first sale is not “we automate your whole business.” It is “we let your existing agent take more real actions without creating a transaction mess.”
Related OperatorForge AI resources
- Web version: https://operatorforge-ai.pages.dev/guides/ai-agent-transaction-approval-gates-checklist.html
- AI Agent Safety Preflight & Rollback Checklist: https://operatorforge-ai.pages.dev/guides/ai-agent-safety-preflight-rollback-checklist.html
- AI Agent Skipped-Step Audit Checklist: https://operatorforge-ai.pages.dev/guides/ai-agent-skipped-step-audit-checklist.html
- OperatorForge AI launch kit: https://operatorforge-ai.pages.dev/