Design Approval Gates for Agents Touching Financial Data

Tier: Advanced · Workflow area: Governance & Audit · ~45 minutes

pb-42 built one approval gate; this playbook designs the control system — the written, defensible policy that decides which agent actions on financial and HR data execute on their own, which queue for a human, and which no agent may perform at all. The framing that makes it tractable: you already run this exact control for humans. Release strategies, approval limits, segregation of duties — agents don't need a new philosophy, they need to be enrolled in the existing one, with two additions humans never needed: a kill switch and the assumption that the actor can be confidently wrong at machine speed.

When to use

• Before any agent's first write to financial, payroll or vendor datathe gate design is a prerequisite for go-live, not a fast-follow; retrofitting control onto a live agent is incident response.
• When agent adoption is fragmenting into per-team improvisationthree teams with three ad-hoc approval habits is how the audit finding writes itself; one control matrix ends it.
• After a near-missan agent that almost double-paid a vendor is the cheapest tuition you will ever get; spend it on this design while attention is high.

When NOT to use

• As a paper exercise detached from enforcementa threshold matrix nobody wires into Agentforce action config or Copilot Studio approvals is compliance theater; every row must map to a platform enforcement point.
• Copying thresholds from a blog post (or this playbook) unadjustedauto-execute limits derive from your materiality, your fraud history and your approval culture; the structure transfers, the numbers never do.
• For decisions that are prohibited, not gatedsome actions (changing vendor bank details, master-data merges, payroll changes) may belong on the never-list for agents entirely; a gate implies the action is sometimes acceptable, so decide the never-list first.

The recipe

1. 1.

   Inventory agent-reachable actions and classify each. List every action every agent can invoke (the pb-42 tool sort is your seed), and tag: data class (financial / HR / vendor-master / operational), reversibility (reversible / compensable / irreversible), and value exposure (bounded by what amount?). This table is the raw material; most orgs are startled by how many write paths exist once listed.

2. 2.

   Draft the tier matrix with AI, then argue with it.

   Copy

   Draft an approval-gate matrix for AI agents acting on ERP data.
   Tiers:
   T0 PROHIBITED  - never agent-executable
   T1 HUMAN GATE  - executes only after named-role approval of the
                    exact payload
   T2 AUTO + REVIEW - auto-executes; sampled post-review, daily cap
   T3 AUTO        - auto-executes; logged only
   Assign each action (inventory attached) to a tier with a one-line
   rationale referencing data class, reversibility and value.
   Constraints: irreversible + financial => T0 or T1, no exceptions;
   anything touching vendor bank details => T0; T2 requires a
   defined sampling rate and a value cap per transaction AND per day.
   Flag every assignment you are least confident about.
   

   The review meeting for this draft — controller, IT security, process owners — is the actual control-design act; the AI's role was making the meeting concrete.

3. 3.

   Set thresholds like a treasurer, not a technologist. For each T2 action: per-transaction cap, daily aggregate cap, and rate limit. Anchor them to existing human approval limits — an agent auto-executing what a junior clerk would need a signature for is an SoD hole with extra steps. Write the numbers in the matrix with their anchor ("T2 cap ₹50,000 = clerk self-approval limit").

4. 4.

   Make agent identity carry SoD. Each agent runs as a dedicated service identity with roles derived from — never exceeding — the human role it assists, and the same SoD rules apply: the agent that creates purchase requisitions must be technically unable to approve them, enforced in the ERP's authorization layer (SAP role design, Salesforce profiles/permission sets, Dataverse security roles), not in prompts. Run agents through the same SoD-conflict analysis (GRC ruleset) you run humans through; an agent identity appearing in a conflict report is a design bug to fix before go-live.

5. 5.

   Build the kill switch and rehearse the rollback. The kill switch is a single, documented action — deactivate the agent identity or disable the agent — executable within minutes by named on-call people who are not the agent's builders, tested quarterly like any DR control. The rollback path answers: for each T2/T3 action, how do we identify everything the agent did in a window (the audit trail from pb-52, filtered by agent identity) and reverse or compensate it (reversal documents, compensating journal entries, record restoration)? Rehearse once on synthetic actions in a sandbox: kill, enumerate, reverse, reconcile. An unrehearsed rollback plan is a wish.

6. 6.

   Wire enforcement and prove each gate with a hostile test. Map every matrix row to its mechanism — Agentforce: action-level confirmation requirements and permission sets; Copilot Studio: Power Automate approval nodes per pb-42; SAP: workflow release strategies the agent's postings park behind. Then test like an attacker: attempt a T0 action through the agent (must be impossible, not declined), a T1 without approval (must queue), a T2 breaching its daily cap (must halt), and confirm each attempt landed in the audit trail. Screenshots of these four failures are your control evidence.

Make it yours

• SAPlean on what finance already trusts: park-and-post, release strategies and workflow. Agent postings enter parked/held; existing release workflow is the T1 gate, which auditors already understand — the strongest possible answer to "how is the agent controlled?"
• Oracle Fusionroute T1 through Approval Management (AMX) rules keyed to the agent's identity attribute, and let Risk Management Cloud's SoD analysis include agent roles in its ruleset.
• Microsoft Dynamics 365combine Copilot Studio approval nodes with F&O workflow on the target documents (vendor invoice journals in workflow), so the gate holds even if someone bypasses the agent layer and calls the API.

Quality check

• Every matrix row names its enforcement mechanisma tier without a platform control is a sentence, not a gate; audit the mapping row by row.
• The hostile tests ran and their evidence is filedincluding the T0 impossibility test; "we configured it" is a claim, a failed attempt log is proof.
• Agent identities passed the same SoD analysis as humanswith the conflict report retained.
• The kill switch drill is on the calendarquarterly, timed, by the on-call rota, with the last drill's minutes findable.
• Thresholds anchor to human approval limits in writingany T2 cap exceeding its human anchor has a signed exception, or it's a finding.