The flagship question of this whole track: what may an AI agent do unsupervised in a system of record — and who signed off on that answer? This module builds the control set no vendor teaches: approval gates, audit trails you actually review, agent permissions that respect SoD, and an org policy an auditor accepts.
Everything in this track converges here. The verification discipline from tuning, the gate chain from change management, the guardrail stacks from MCP and NL-SQL, the eval mindset from platform agents — governance is those habits promoted to organizational controls, applied where the stakes are highest: agents acting on financial and HR data inside the systems the company's books and audits stand on. The vendors ship the capabilities and the trust marketing; the control design — thresholds, reviews, permissions, policy — is left to the org. That gap is this module, and it is the most defensible expertise in the track, because it compounds with regulation instead of being commoditized by the next release.
Nandini leads the business-platforms team at a Bengaluru BFSI-adjacent services company running D365 Finance. The 2026 wave brings payment agents of the Payflow pattern: autonomous execution "within configured parameters." A pilot goes live for vendor payment scheduling.
The agent has scheduled 300+ payments flawlessly. Finance ops is warming to it. The configured gate: auto-execute below ₹5,00,000, human queue above.
A vendor submits four invoices — ₹4.2L, ₹4.6L, ₹3.9L, ₹4.8L — against one PO, same week. Each is under threshold. The agent schedules all four. No rule is violated: ₹17.5L flows to one vendor with zero human eyes on it.
An AP analyst notices during a routine run. The invoices turn out legitimate — a split billing arrangement nobody documented. No loss. Everyone exhales.
Internal audit asks the question that matters: if they had been fraudulent, which control would have caught them, and when? The honest answer: none before payment. The gate tested per-transaction amounts; the risk was cumulative exposure. Split invoicing is the oldest AP fraud pattern there is — and the gate design had encoded none of that institutional knowledge.
Velocity limits per vendor per window, cumulative-exposure thresholds, same-PO aggregation checks, and an anomaly rule: any vendor's first week above historical baseline goes to the queue. Plus the meta-fix: gate designs now get red-teamed against known fraud patterns before activation, and reviewed quarterly.
The lesson generalizes: an approval gate is a fraud-and-error model, not a number. "Within configured parameters" is exactly as safe as the thinking that configured the parameters.
The design method, applicable on any platform (Agentforce action config, Copilot Studio approval steps, Fusion Agent Studio validation flows, or custom gates):
Steal from the fraud playbook, not just the approval playbook. AP teams have decades of split-invoice, ghost-vendor and velocity heuristics; encoding that institutional knowledge into agent gate design is the highest-value meeting a platform person can convene — and almost nobody convenes it.
Every platform now emits AI audit surfaces: the Einstein Trust Layer's prompt-to-response chain (user, timestamp, masked prompt, grounding sources, response — with its Data Cloud dependency), agent session logs across Copilot Studio and Agentforce, Fusion agent validation logs. The trap is treating their existence as the control. An unreviewed log is evidence of negligence, not oversight — it proves the org could have known.
The agent runs under an integration user with admin-adjacent rights "so it just works." Every prompt injection, model error and scope bug now executes with those rights; FLS/RLS mean nothing because the runtime identity bypasses them. The audit finding writes itself.
A dedicated agent identity per agent, a permission profile built from its action inventory and nothing more, platform entitlements (FLS/RLS/authorization objects) enforced in the agent's context, and an SoD check run over the profile before activation — the agent held to the same segregation rules as a human hire.
Segregation of duties is where AI helps govern AI: role matrices are large, agent action catalogs are new, and an LLM-assisted scan — "given these action grants and this SoD rule set, list conflicts an auditor would flag" — surfaces combinations like create vendor + schedule payment in one agent, the classic conflict that enables ghost-vendor fraud. The scan output is a draft for the compliance owner, evidence-per-claim style; the human rules on each finding. And permission review recurs: every new action added to an agent re-triggers the SoD check, because agents accrete capabilities exactly the way long-tenured employees accrete access.
An agent with an SoD conflict is worse than an employee with one — it executes at machine speed, around the clock, with no colleague noticing something odd at the next desk. The pre-activation SoD scan and per-action permission profile are not compliance decoration; they are the difference between an incident and a headline.
Wrong answers are a governed risk alongside wrong actions. The controls, assembled from earlier modules and formalized here:
ROI honesty is a governance control too, because inflated benefit claims corrupt the risk calculus that gates expansion. Against a backdrop where most enterprise AI pilots report no measurable return, the credible program defines baseline metrics before launch (deflection, cycle time, queue length), instruments agent analytics (Agent Studio ships ROI tooling; the others expose usage data), and reports actuals against baseline — including zeros. A governance function that certifies honest zeros earns the credibility that lets it approve the next pilot.
The policy is where the control set becomes durable. The auditable minimum:
| Policy element | What it specifies | Maps to |
|---|---|---|
| Feature-data matrix | Which AI features are approved per data classification (public → confidential → personal → financial) | DPDP purpose limitation; client MSAs |
| Sub-processor register | Which LLM providers see which data, retention terms, zero-retention contracts verified in writing | DPDP §8 obligations; GDPR Art. 28 |
| Agent change control | Gate thresholds, instructions, action grants and grounding changes go through the change board | SOX-style ITGC change management |
| Review procedures | Audit-trail cadence, SoD re-scan triggers, probe-set re-runs per release wave | NIST AI RMF Measure/Manage; ISO 42001 operation clauses |
| AI incident category | Misbehavior defined (out-of-policy action, leak, material wrong answer), reporting path, kill-switch authority | Incident-management alignment; RBI/SEBI reporting where applicable |
| Accountability map | Named owners: per-gate business owner, policy owner, review owners | ISO 42001 leadership clauses; the auditor's first question |
For India services, the policy work is client-facing casework. ERP master data is personal data under DPDP — employees, customers, vendors — so agent features that route data to LLM sub-processors trigger DPDP analysis plus the client's MSA, and BFSI clients layer RBI/SEBI localization on top. The consultant's duty is unglamorous and differentiating: read the sub-processor terms, map them to the client's obligations, and explain them in plain language to the client's DPO — "the vendor's trust page says it's fine" is not advice. The consultant who walks in with a gate-design method, a review procedure, and a DPDP mapping is selling governance, which outlasts every feature cycle.
NIST AI RMF and ISO 42001 are free to read and map against — govern/map/measure/manage gives your policy a recognized skeleton, and "our controls map to AI RMF" is a sentence that shortens audits. Use them as scaffolding, not as a substitute for the specific gates and reviews this module builds.
Check yourself: An auditor asks: "Your payment agent runs autonomously within configured parameters. Convince me that is a controlled process, not a delegated one." Name the five artifacts you produce, and what each proves.
This module anchors LAB-15 (governance capstone) — the full control set for a mock ERP agent: gate thresholds on the Payflow pattern, a least-privilege profile, an SoD scan with three seeded conflicts, an audit-log review, and the one-page policy mapped to DPDP and NIST AI RMF. Do it at work this week → pb-51 (approval-gate design for financial-data agents) and pb-52 (audit trails, review procedure, and the org policy).
Systems of record run on controls, and AI does not get an exemption — it gets the same treatment, redesigned for machine speed: gates that model fraud rather than trust thresholds, trails that are reviewed rather than retained, agent permissions that pass SoD before activation, and a one-page policy with named owners. Whoever builds that control set governs the platform wave instead of being governed by its incidents.