Lab 15 · Governance capstone: AI in the system of record

Priya is the IT governance lead at a Hyderabad pharma distributor whose ERP vendor just enabled an AP automation agent, and the steering committee's enthusiasm has outrun its controls: the agent can do things — post, release, update — in the system of record, and the current "governance" is a demo recording and good intentions. This capstone is the counter-artifact: the pack that answers an auditor's four questions — what can it do, who approved the boundaries, how would you catch it misbehaving, and can you prove you looked. Nothing here requires an SAP license; everything here is the design work the license never includes.

Time & tier

~120 minutes hands-on · Capstone tier (maps to module M8 · Governing AI in Systems of Record).

Setup

An AI assistant, a text editor, DuckDB or a spreadsheet for the two data files. The agent's action catalog, action-catalog.md — twelve actions the vendor agent exposes:

ACT-01  Read vendor master record
ACT-02  Read open invoices and payment status
ACT-03  Match invoice to PO and goods receipt (3-way match)
ACT-04  Post matched invoice (creates FI document)
ACT-05  Block invoice for discrepancy
ACT-06  Release blocked invoice
ACT-07  Create new vendor (skeleton record)
ACT-08  Update vendor bank details
ACT-09  Schedule payment run entry (queued for run)
ACT-10  Release payment run (money leaves)
ACT-11  Reverse posted document
ACT-12  Send vendor query email (external comms)

The role matrix extract, roles.csv (users × ERP roles; the agent's service account included):

user,role
priya.g,GOV_AUDIT_VIEW
anil.k,AP_CLERK
anil.k,VENDOR_MAINT
sunita.r,AP_CLERK
sunita.r,PAY_RUN_RELEASE
mohan.v,VENDOR_MAINT
mohan.v,PAY_RUN_RELEASE
deepa.s,AP_SUPERVISOR
deepa.s,AP_CLERK
agent_ap_bot,AP_CLERK
agent_ap_bot,VENDOR_MAINT
agent_ap_bot,PAY_RUN_RELEASE
ravi.n,GL_POST
ravi.n,GL_APPROVE

Role capabilities: AP_CLERK = ACT-01..05, 09; VENDOR_MAINT = ACT-07, 08; PAY_RUN_RELEASE = ACT-10; AP_SUPERVISOR = ACT-06, 11; GL_POST / GL_APPROVE = post and approve journal entries; GOV_AUDIT_VIEW = read-only. And the audit-log extract, audit-log.csv:

ts,actor,action,object,amount_inr,approval_ref
2026-07-01 09:14,agent_ap_bot,ACT-03,INV-88231,412000,
2026-07-01 09:15,agent_ap_bot,ACT-04,INV-88231,412000,APR-1201
2026-07-02 11:02,agent_ap_bot,ACT-04,INV-88240,38000,AUTO
2026-07-03 14:21,agent_ap_bot,ACT-08,VEND-2044,,APR-1215
2026-07-03 14:22,agent_ap_bot,ACT-09,INV-88251,912000,APR-1216
2026-07-03 14:24,agent_ap_bot,ACT-10,PAYRUN-501,912000,
2026-07-04 10:05,sunita.r,ACT-10,PAYRUN-502,388000,APR-1220
2026-07-04 16:40,agent_ap_bot,ACT-07,VEND-2101,,APR-1230
2026-07-04 16:41,agent_ap_bot,ACT-08,VEND-2101,,APR-1230
2026-07-04 16:44,agent_ap_bot,ACT-09,INV-88260,245000,APR-1231
2026-07-05 09:00,deepa.s,ACT-06,INV-88203,155000,APR-1233
2026-07-05 09:30,agent_ap_bot,ACT-12,VEND-2044,,AUTO

Guided steps

1. 1Classify the action catalog by blast radius. Three tiers, argued action by action in gate-design.md: Tier A — auto-execute (read-only and reversible-with-no-external-effect: ACT-01, 02, 03, 05); Tier B — auto with threshold, else queue (state-changing but inside the ledger: ACT-04 below a value threshold with a clean 3-way match; ACT-09 similarly); Tier C — always human (ACT-06, 07, 08, 10, 11 — anything releasing money, altering payee identity, reversing the record, or overriding a block; plus ACT-12, external comms, at minimum reviewed-async). This is the Payflow pattern: autonomy is earned per action, bounded by amount, and identity-touching actions never graduate.
2. 2Set the thresholds like a controller, not a technologist. For ACT-04/ACT-09 auto-execution, define: the amount ceiling (justify against the company's existing DoA — delegation-of-authority — table; pick INR 50,000 for the mock and say why: it matches the clerk-level DoA), the match-quality condition (3-way match with zero tolerance breach), the volume circuit-breaker (max auto-posts per hour and per vendor per day — an agent gone wrong fails at machine speed, so rate limits are a control, not an optimization), and the kill switch (who can disable the agent, how fast, tested how often). Add the escalation SLA for the human queue.
3. 3Write the least-privilege profile — and indict the current one. Compare roles.csv against your tier design. The finding to make loudly: agent_ap_bot holds AP_CLERK + VENDOR_MAINT + PAY_RUN_RELEASE — the agent can create a vendor, change bank details, and release payment: the classic fraud triangle in one service account, and precisely the combination your Tier design forbids. Draft the corrected profile in agent-profile.md: the agent keeps ACT-01/02/03/05 rights, gains ACT-04/09 only through the gate service (so the threshold is enforced outside the model's judgment), and holds no role containing ACT-07/08/10/11. State the standing rule: the agent's permissions are what it can do when the model is wrong — profile for the failure mode, not the demo.
4. 4Run the LLM-assisted SoD scan. Give the assistant the role matrix and role-capability map with: "Identify segregation-of-duties conflicts. For each: user, conflicting roles, the fraud or error scenario the combination enables, severity, remediation. Standard SoD pairs apply (vendor maintenance vs payment release, posting vs approval, clerk vs release)." Expected: it finds the seeded conflicts — verify each against the matrix yourself before accepting (the scan is a hypothesis generator; the matrix is the evidence): mohan.v (VENDOR_MAINT + PAY_RUN_RELEASE — can redirect a vendor's bank account and pay it), sunita.r (AP_CLERK + PAY_RUN_RELEASE — can schedule and release the same payment), ravi.n (GL_POST + GL_APPROVE — approves own journals), and — the one the prompt did not ask about but the scan should surface, and must not be filed as merely a fourth row — agent_ap_bot's triple, which belongs in both the SoD findings and step 3's profile indictment. Also expected: the model may flag deepa.s (AP_SUPERVISOR + AP_CLERK) — adjudicate it honestly (release-block plus clerk duties is a genuine medium-severity finding in most frameworks). Record all findings with your verify-against-matrix note in sod-findings.md.
5. 5Review the audit-log extract with a written procedure first. Draft the procedure — five checks, each a one-line query or filter: (P1) every Tier-C action has a non-empty, non-AUTO approval_ref; (P2) every auto-executed Tier-B action is under threshold; (P3) no approval_ref is reused across unrelated actions; (P4) sequence checks — vendor created/bank-changed then paid within a short window flags for review; (P5) actor-vs-approver identity where resolvable. Then run it. Expected findings — the two seeded violations: the 2026-07-03 sequence — ACT-09 for INR 912,000 (far above any clerk threshold) followed two minutes later by ACT-10 with an empty approval_ref: the agent released a nine-lakh payment run with no recorded approval; and the 2026-07-04 sequence — vendor VEND-2101 created and bank-detailed by the agent at 16:40–16:41 under a single approval reference (one approval laundered across two Tier-C actions), then queued for a 245,000 payment three minutes later — the new-vendor-quick-pay pattern every AP fraud playbook flags. Note also the benign contrasts you must not flag (ACT-04 at 38,000 marked AUTO is legitimate under a 50k threshold; sunita.r's release carries a proper ref — her SoD problem is a role-design finding, not a log violation). Write up both violations with row citations in audit-review.md.
6. 6Draft the one-page org AI policy — mapped, not vibed. Have the assistant draft, then edit to one page, ai-policy.md with five sections, each carrying its framework anchor: Scope and roles (accountable owner per agent — NIST AI RMF GOVERN); Authorization boundaries (the tier/threshold model — MANAGE; DPDP: processing limited to defined purpose); Data handling (personal data the AP agent touches — vendor bank details are personal data of proprietors; DPDP consent/legitimate-use grounds, retention, and the log itself as personal-data store); Monitoring and review (the step 5 procedure, weekly cadence, MEASURE); Incident and kill switch (who pulls it, notification duties — DPDP breach reporting, MANAGE). One page is a constraint, not a summary: an auditor reads pages one and none.
7. 7Assemble and pressure-test the pack. Compile governance-pack.md linking all six artifacts. Then the capstone's closing move: feed the assistant your own pack with "You are an external auditor reviewing this AI governance package. Find the three weakest points." Adjudicate its critique — accept what lands (typical hits: no periodic re-certification of the agent's profile, no independent review of the gate service's own config changes, thresholds with no review date), rebut what does not, and append the adjudicated list as the pack's known-gaps register. A governance pack with a maintained known-gaps register is more credible to an auditor, not less.

Verify

• •
  gate-design.md tiers all twelve actions with per-action reasoning; identity-touching actions (07, 08) and money-releasing actions (10) are human-always.
• •
  agent-profile.md names the agent's current triple-role violation and specifies the corrected profile with gate-service enforcement.
• •
  sod-findings.md contains all three seeded human conflicts plus the agent's, each verified against the matrix by you.
• •
  audit-review.md catches both seeded violations with row citations, and does not false-flag the two benign contrast rows.
• •
  ai-policy.md is one page with DPDP and NIST AI RMF anchors on every section; the pack ends with an adjudicated known-gaps register.

Self-grading rubric (pass = 9/12): tiering defensible for all 12 actions (0–2); thresholds carry controller-grade justification including rate limits and kill switch (0–2); agent's fraud-triangle profile caught and corrected (0–2); all three seeded SoD conflicts found and independently verified (0–2, minus one if any accepted unverified); both audit-log violations caught with no false flags (0–2); policy mapped and one page (0–1); auditor pressure-test run and adjudicated (0–1).