How to Audit AI Agent Decisions in Banking (A Practical Framework)
A practical, five-point framework internal audit and compliance teams can use to sample, test, and evidence AI agent decisions in banking — after the trail already exists.
- Luke SunejaClient Partner
In this article
You cannot audit "the agent." An agent is not a single thing with a single behavior — it is a policy that produces thousands of individual decisions, each shaped by a different prompt, a different context window, a different set of retrieved documents, and a different user session. What an internal audit or compliance function actually has to work with is a trail: a log of discrete actions, each with its own authorization, its own reasoning, and its own outcome. The practical problem is not "is the agent trustworthy" — it's "can we pull decision #4,812 from three weeks ago and prove, end to end, that it happened the way it should have." That is a sampling and evidence problem, and it has a methodology.
What makes an agent decision auditable
Before you can sample anything, the record has to already exist in a form that survives scrutiny. This is the part audit teams most often discover too late: you cannot retrofit a trail. If the agent's reasoning wasn't captured at the moment of the decision, no amount of post-hoc reconstruction, log correlation, or vendor testimony will produce it. An auditor asking "why did the agent do this" six weeks after the fact needs a record that was written down at the time, not a plausible narrative assembled afterward.
That means the prerequisite for an audit program is a tamper-evident ledger — a record of each decision that is written once, cannot be silently edited, and captures the inputs, the reasoning trace, the action taken, and the approvals involved. We've covered the mechanics of what that ledger needs to prove elsewhere: see What a Hash-Chained AI Ledger Actually Proves to a Regulator. The rest of this article assumes that ledger exists. If it doesn't, the actual finding of your first audit will simply be "insufficient evidence to audit" — and that's a finding worth surfacing on its own, because it means every decision made before the ledger existed is permanently unauditable.
A practical framework: 5 things to sample
Once the trail exists, the audit itself is a sampling exercise, not a full-population review. Below are the five categories we see internal audit and compliance functions test most consistently when they build an agent audit program, along with what a passing sample looks like and the red flag that ends it.
| What to sample | What you're checking | Red flag |
|---|---|---|
| Authorization chain | Whether the agent acted strictly within the permissions of the human user it was inheriting from — not a broader service account, not a cached credential from a prior session. | The agent's logged permission scope is broader than the initiating user's actual entitlement at the time of the action. |
| Approval gate compliance | Whether irreversible or high-impact actions actually stopped for a human decision, and whether that approval reflects genuine review rather than a reflexive click. | Approval timestamps sit 1-2 seconds after the prompt was surfaced, or the same approver clears hundreds of gates per day with no rejections. |
| Reasoning trace completeness | Whether you can reconstruct why the agent took the action — which retrieved documents, which policy passages, which prior turns informed it — not just a summary of what it did. | The logged trace is a one-line action summary with no linked retrieval context or intermediate reasoning steps. |
| Outcome vs. intent | Whether the action taken matches what was actually authorized, or whether the agent did something adjacent, broader, or in a different system than the request called for. | The agent modified a record, account, or limit outside the scope of the originating request, framed internally as a "related fix." |
| Escalation behavior | Whether the agent correctly declined, paused, or routed to a human when it hit an ambiguous, out-of-policy, or low-confidence case, rather than guessing. | Escalation rate near zero across a large sample — a sign the agent is resolving genuinely ambiguous cases on its own instead of raising them. |
An agent handling thousands of decisions a day makes 100% review impossible — which means your sampling methodology is as much a control as the audit itself. A statistically defensible sample (stratified by action type and dollar threshold, with oversampling on high-impact and escalation-adjacent cases) is a design decision that belongs in the audit charter, not something improvised the morning the audit starts.
What a finding actually looks like
Vague findings ("the agent's governance could be improved") don't get remediated because no one can act on them. A usable finding names the sample size, the specific gap, and the threshold that was crossed. A few examples drawn from the kinds of gaps this framework surfaces in practice:
Finding 1: Of 340 wire transfer decisions reviewed, agent A processed 12 above the $10,000 auto-approval threshold with no logged human approval event, despite the approval-gate policy requiring one for all transactions above $5,000. Root cause: a configuration drift left the threshold at the pre-migration value of $10,000 rather than the current policy value.
Finding 2: In 8 of 50 sampled credit line adjustments, the reasoning trace referenced a policy document version that had been superseded 11 days prior. The agent's retrieval index had not been refreshed since the policy update, meaning approved adjustments were made against stale underwriting criteria.
Finding 3: Across a sample of 200 customer dispute resolutions, escalation rate was 0.5%, versus a 6-8% baseline for the equivalent human-staffed queue over the same period. Manual re-review of 20 non-escalated cases found 3 that met the documented escalation criteria for suspected fraud indicators but were resolved autonomously instead.
Cadence and ownership
This is not a one-time exercise you run before go-live and file away. Under SR 11-7's ongoing monitoring expectations — the same model risk management foundation we cover in RAG for Financial Services: Compliance-First AI for Banking and Insurance — an agent's decision quality has to be monitored continuously, not just validated at deployment. That obligation maps cleanly onto the same three-lines-of-defense structure we detailed when we covered accountability: the second line validates the agent's behavior continuously against live data, and internal audit tests the control periodically and independently, sampling as described above. We won't re-walk that mapping here — see AI Agent Governance in Banking: Who's Accountable When the Agent Acts? for the full accountability breakdown. What matters here is cadence: continuous monitoring by the business line, quarterly or semi-annual sampling audits by internal audit, and a defined path for escalating repeat findings into a model risk review rather than closing them as one-off exceptions.
Frequently asked questions
An audit framework only works if the underlying architecture was built to be inspected — permission inheritance, approval gates, and reasoning traces aren't things you bolt onto an agent after the fact. If you're designing or re-architecting an agent deployment for a regulated environment, talk to a Sphere AI engineer about building it audit-ready from day one.