Governance Architecture

Section 3 of Agentic Banking Architecture: A Practitioner's Guide

Every conversation about agentic AI in banking eventually arrives at the same question: how do you govern this? The reference architecture describes what agents do. The governance architecture describes how you keep them under control.

The Governance Model

Governance for agentic banking maps onto the existing three lines of defence — but requires new mechanisms at every layer. The model has four horizontal components: human governance at the top and bottom, and automated governance in the middle.

Human Governance — Defining the Rules

Humans define the rules. The inputs are regulatory requirements, risk appetite, architectural standards, and business strategy. These are not new — every bank has them. What's new is that these rules need to be expressed in a form that agents can consume: structured policies that can be codified into prompts, guardrails, and hard limits.

The Policy Codification Pipeline

This is a new component that does not exist in today's architectures. A pipeline that transforms human-authored policies into executable agent configurations: author → version → test → deploy to the policy registry. Each policy is versioned, tested against scenarios, and promoted through environments exactly like code. Because in an agentic architecture, policy is code.

The Agent Control Plane

The control plane sits at the centre of the governance architecture. It's where policies are enforced at runtime: tool-use allowlists, resource quotas, escalation triggers, and the hard circuit breakers that agents cannot override. Every agent action passes through the control plane. Every decision is logged to the observation bus.

The Observation Bus

A continuous stream of agent decisions, reasoning traces, tool calls, and outcomes. This is the audit trail — not a periodic report, but a real-time feed that the assurance functions consume. Every agent decision is traceable: what goal was it pursuing, what data did it access, what reasoning led to the decision, and what was the outcome.

Three Lines of Defence — Reimagined

The three lines of defence model is well established in banking. In an agentic architecture, each line operates differently.

First Line: The Agent Itself

The agent's own guardrails, policies, and boundaries. These are embedded in the agent's configuration: what tools it can call, what data it can access, what decisions it can make autonomously versus what requires escalation. First line governance is preventive — it stops the agent from doing things it shouldn't before they happen.

Second Line: Assurance Agents

Agents that monitor other agents. They consume the observation bus, validate decisions against policy baselines, and flag anomalies. This is where the power of agentic governance becomes apparent: second line assurance can be continuous rather than periodic. Instead of sampling 2% of decisions quarterly, assurance agents can validate every decision in real time.

A key distinction raised during development of this framework: there's a difference between "governing agents" (new capabilities needed specifically because agents exist) and "doing existing governance with agents" (using agents to perform traditional compliance monitoring). Second line assurance is the former — it's a new function that exists because agents make decisions. Using agents to automate existing KYC checks is the latter. Both are valuable, but only the former is part of the agentic governance architecture.

Third Line: Audit and Challenge

Independent validation that the governance framework itself is working. Third line agents replay decisions, challenge policy baselines for gaps, and test whether the first and second lines are catching what they should. This is adversarial by design — red-team agents that try to find ways through the governance controls.

Hard Circuit Breakers

Some controls cannot be probablistic. No matter how good the agent's reasoning, certain limits are absolute: transaction limits that cannot be overridden, regulatory thresholds that trigger mandatory escalation, and PII boundaries that no prompt can circumvent. These hard circuit breakers are enforced by deterministic code — not by prompts or policies that an agent could theoretically work around.

The Identity Question: Acting on Behalf of a User vs Acting on Its Own Authority

One of the most consequential design decisions in agentic governance: under whose authority is the agent acting? Two paradigms:

Agent acting on behalf of a user: The agent operates within the authority of an identified principal — a customer, an employee, a role. It inherits that principal's permissions and acts in their name. The audit trail records both the agent's actions and the user on whose behalf they were taken. Accountability flows back to the principal: if a relationship manager's agent makes a poor lending recommendation, the RM is accountable for what their agent did on their behalf. This model maps cleanly to delegation patterns that already exist in banking — a trader's algorithmic execution, an RM's support staff acting in their name.

Agent acting on its own authority: The agent is a principal in its own right. It has its own identity, its own permissions, and its own accountability. It acts not as a delegate but as an autonomous actor within boundaries the bank has granted it. A fraud detection agent that blocks a transaction is not acting on behalf of a specific person — it's acting on behalf of the bank, under authority granted to it directly. Accountability is architectural: the agent's scope, controls, and decisions must all be governable without a human principal behind every action.

The distinction matters because the governance mechanisms are different. On-behalf-of agents inherit the authorization, monitoring, and accountability frameworks already in place for the principals they act for — agentic governance extends existing controls. Own-authority agents need new mechanisms: a way to define what authority the bank is granting directly to the agent, a way to hold the agent accountable when there's no human behind the action, and clarity about who bears responsibility when the agent's autonomous decisions go wrong.

Most banks will need both models, applied to different classes of agents. Customer-facing agents assisting a relationship manager act on behalf of the RM. Back-office surveillance agents and autonomous control agents act on their own authority. The governance architecture needs to support both — and, critically, needs to make the distinction explicit for every agent deployed, because the controls, logging, and escalation paths are fundamentally different.

Human Governance — Closing the Loop

At the bottom of the governance architecture, humans re-enter: reviewing escalations, calibrating thresholds, approving policy updates, and holding accountability. The assurance agents surface findings. The audit agents surface gaps. Humans decide what to change. Updated policies flow back through the codification pipeline. The loop closes.

This is not a fully autonomous system. It's a human-governed system with automated enforcement and automated assurance. The humans set the rules and review the outcomes. The agents execute and monitor. The architecture ensures that the feedback loop is fast, comprehensive, and auditable.

This section expands on ideas first published in Part 3 of the LinkedIn series. The governance diagram was iterated through nine versions based on feedback from the LinkedIn community, including contributions on adversarial assurance, hard circuit breakers, and the agent identity question.