AI Agent Governance in Banking: Who's Accountable When the Agent Acts?

A bank's AI agent drafts a wire instruction, updates a customer's risk profile, or clears a transaction as non-suspicious when it shouldn't have. When a regulator asks who is accountable, "the agent decided" is not an answer any bank can give. Agent governance in banking isn't a new category of compliance — it's the old question of accountability, applied to a system that can now act at machine speed across dozens of internal systems.

Why banking treats this differently

Most enterprises adopting agentic AI ask whether the agent's authorization and audit trail are sound engineering practice. A bank has to answer the same question as a supervisory obligation, not just a best practice. An agent that touches credit decisioning, fraud detection, AML screening, or customer communications is, for governance purposes, a model — and banking already has a well-established framework for who is accountable when a model behaves badly. That framework doesn't pause for the fact that this particular model can now take actions on its own.

Two things make agents harder to govern than the models banks are used to. First, an agent typically chains several actions and tool calls to complete a task, so a bad outcome can be the product of a reasoning error two steps upstream, not the final action itself — accountability has to trace the whole chain, not just the last click. Second, an agent can act on systems of record directly. A traditional model scores a loan application; a person still enters the decision. An agent can update the record itself, which removes the natural checkpoint most banking workflows were built around.

Mapping agent accountability to the three lines of defense

Banks already have a structure for distributing accountability: the three lines of defense. Agent governance doesn't replace it — it has to plug into it, or the agent becomes a fourth, ungoverned line that nobody owns.

The first line — the business unit deploying the agent — owns the agent's day-to-day behavior and is accountable for defining what it's allowed to do, the same way a branch manager is accountable for what their staff do. The second line — risk and compliance — validates that the agent's permissions, approval gates, and monitoring actually match the bank's risk appetite before it goes live, and owns the model risk management record once it's a model in production. The third line — internal audit — independently tests whether the first two lines' controls actually held, the same as it would for any other automated decisioning system. An agent deployed outside this structure, as a business unit's own tool with no second-line review, is the accountability gap examiners look for first.

Who is accountable when the agent acts

The practical answer splits into three separate questions, and a bank needs a clear answer to each before an agent touches a regulated workflow.

Who authorized the action? An agent should only ever be able to do what the human it's acting for could do — it inherits that person's permissions rather than a separate, broader grant. So the first answer is always a named person or role, not "the system."

Who approved it, if it was consequential? Irreversible or high-stakes actions — releasing funds, closing an account, filing a report — sit behind a human approval gate. The agent proposes; a specific person approves; that approval is itself part of the accountable chain.

Who owns the model? Separately from any single action, someone in the second line owns the agent as a governed model — its validation, its monitoring, its documented limitations — the way SR 11-7 already requires for any system that influences a decision or a customer communication. That ownership exists whether or not any particular action that week required a human approval.

Transparency requirements: what a bank has to be able to show

Accountability is only real if it's demonstrable. For an acting agent, a bank should be able to reconstruct, for any action, on demand: what the agent did, on whose behalf, under what permission, with what approval if one was required, and what it retrieved or reasoned from to get there. That's a higher bar than logging a model's output — it means the full chain of reasoning and action is captured, not just the final result.

This transparency has to extend to customers and staff as well as regulators. A customer interacting with an agent-driven process — a chat that can actually update their account, not just answer questions — is generally entitled to know that, in language that doesn't bury the disclosure. And staff overseeing an agent need visibility into why it did something, in plain language, not just a log line — the same human-oversight requirement that shows up across AI regulation generally, applied here to a system that acts rather than only advises.

Why private deployment makes accountability easier to prove

An agent built on a hosted, general-purpose platform is harder to hold accountable in exactly the way a hosted LLM is: the bank can see the output but not always the full record of what the agent retrieved, reasoned, or was permitted to do at the time. A private or self-hosted agent deployment keeps the permission model, the approval gates, and the audit ledger inside the bank's own environment, under the bank's own control — which means the answer to "who is accountable" can always be reconstructed from the bank's own record, not requested from a vendor's dashboard that may not retain it as long as an examiner requires.

FAQ

Scoping accountable agent deployment for a regulated workflow? Talk to a Sphere AI Engineer.