| Version | 2.0 |
| Date | 20 May 2026 |
| Critique cycles | 2 (3 independent reviewers per cycle) |
| Source documents | 19 (5 regulations, 6 practitioner/academic papers, 5 macro-prudential and cross-sector frameworks, 2 US fair lending guidance, 1 government agentic AI framework, 1 EU implementing guidance) |
| Status | Iterative draft — not a standard, regulation, or endorsed framework |
AI governance is fragmenting along two axes: scope and mechanism. On scope, newer regulations — most distinctively the EU AI Act, but also MAS AIRG and US fair lending law — expand governance beyond financial materiality to encompass fundamental rights, prohibited practices, and algorithmic fairness. On mechanism, agentic AI systems that plan, select tools, and act autonomously at machine speed require runtime enforcement rather than periodic review. Existing MRM frameworks cannot represent these expansions or the structural shift from periodic review to runtime enforcement. The Governance Spectrum Scaffold (GSS) is a 14-row, dual-track comparison framework — a Model Risk Track and an Agent Risk Track — that accommodates both axes within a single structure. It was developed through systematic analysis of 19 governance documents (5 regulations, 6 practitioner and academic papers, 5 macro-prudential and cross-sector frameworks, 2 US fair lending guidance documents, 1 government agentic AI framework, and 1 EU implementing guidance) and refined through two critique cycles with three independent reviewers per cycle. The GSS reveals that the two tracks diverge most on scope, inventory, risk classification, development, validation, human oversight, monitoring, and containment; converge on fairness, governance, policy, third-party risk, transparency, and literacy; and leave liability allocation as an unresolved governance gap.
- 1. Introduction
- 2. The Paradigm Split
- 3. The Governance Spectrum Scaffold
- 4. Key Findings
- 5. Source Base
- 6. Limitations and Open Problems
- 7. Implementation Guidance
- Appendix A: Glossary
AI governance is fragmenting. Financial regulators have operated model risk management (MRM) frameworks for over a decade — SR 11-7 in the US, SS1/23 in the UK, and their counterparts in Switzerland and Singapore. These frameworks govern models: static artifacts that convert inputs to outputs, validated before deployment and monitored periodically thereafter.
Two developments are pulling governance in new directions.
First, the scope of what governance must cover is expanding. The EU AI Act is the most distinctive example: it classifies AI systems by the impact of their use case on fundamental rights — not by the financial materiality of their output — and creates categorical prohibitions on some AI uses, fundamental rights impact assessments, conformity assessments by third-party notified bodies, and AI literacy obligations for all staff. MAS AIRG similarly introduces fairness as a lifecycle control with assessment requirements. US fair lending law (ECOA, Regulation B, CFPB enforcement) already requires specific and accurate reasons for adverse action regardless of technology. None of these obligations sit comfortably within traditional MRM's materiality-and-complexity framework, but all of them operate through the same mechanism: pre-deployment gates and periodic post-market monitoring. The EU AI Act shares this mechanism — its conformity assessment is a pre-deployment gate and its post-market monitoring is periodic reporting — even as it expands the scope of what governance must address.
Second, agentic AI — systems that decompose tasks, select execution paths, call tools, and take actions autonomously at machine speed — stresses the mechanism of periodic governance itself. Practitioner papers and a government framework from Singapore's IMDA propose capability catalogues, trajectory conformance testing, runtime policy enforcement, and tiered containment mechanisms. These are not incremental extensions to periodic MRM review; they address governance needs that emerge when systems act autonomously at machine speed.
Financial institutions already govern many systems dynamically — algorithmic trading controls, payment authorization systems, fraud engines, cybersecurity policy enforcement, and workflow orchestration all operate at runtime. The novelty of agentic AI governance is not runtime enforcement per se; it is the combination of autonomous planning, tool execution, and adaptive behavior that stresses MRM's assumptions about stability between reviews and human-pace oversight.
To our knowledge, no published framework explicitly accommodates both the scope expansion within traditional MRM mechanisms and the mechanism shift to runtime enforcement within a single dual-track structure. Traditional MRM scaffolds force agentic concepts into model-centric slots (producing "inferred" entries). They have no place for fairness, rights, or prohibited practices. And they cannot represent the structural shift from periodic review to runtime enforcement.
This document presents the Governance Spectrum Scaffold (GSS): a 14-row comparison framework with two parallel tracks — a Model Risk Track for systems governed by periodic review (including the EU AI Act and US fair lending law) and an Agent Risk Track for systems requiring runtime enforcement — that accommodates both axes of fragmentation within a single structure.
The GSS was developed through systematic analysis of 19 governance documents: 5 regulations, 2 macro-prudential frameworks, 5 practitioner or academic sources, 1 government agentic AI framework, 2 cross-sector AI risk frameworks, 1 EU implementing guidance, and 2 US fair lending/anti-discrimination sources (see Section 5). It is designed to be used by financial services practitioners who need to compare governance requirements across jurisdictions and technology paradigms.
Traditional MRM governs systems whose dominant risk is a wrong output. A credit scoring model produces an inaccurate score. A pricing model misvalues a portfolio. The governance response is to validate the model before deployment, monitor its performance periodically, and revalidate on schedule. Most real systems produce both outputs and actions; the tracks identify which risk mode dominates and therefore which governance assumptions hold.
The key assumption: the governed artifact is stable between reviews. A model validated in January is expected to behave in March the way it did in January, give or take predictable drift. Human review between steps is feasible and effective.
This is the paradigm of SR 26-2, SS1/23, FINMA Guidance 08/2024, and MAS AIRG. Modern MRM practice already governs adaptive systems, challenger models, continuous monitoring, operational constraints, fallback logic, and escalation procedures. The NIST AI RMF (GOVERN-MAP-MEASURE-MANAGE) and the BCBS Principles for Operational Resilience provide broader frameworks that complement MRM with cross-sector and macro-prudential perspectives.
The EU AI Act shares many structural features with this paradigm — its conformity assessment is a pre-deployment gate and its post-market monitoring is periodic reporting. However, the Act's regulatory architecture explicitly accounts for lifecycle mutability via Article 25, where a deployer who fine-tunes a third-party model becomes a provider with full obligations (see Section 4.5). This role transition means the EU AI Act straddles the line between static governance and dynamic system evolution.
Agentic AI creates systems whose dominant risk is a wrong action at machine speed. An agent composes a multi-step plan, calls tools, writes to databases, and makes sequential decisions autonomously. Harm does not come from a single wrong output — it comes from a sequence of actions that individually may appear reasonable but collectively produce an unintended or unsafe outcome. Most real systems produce both outputs and actions; the tracks identify which risk mode dominates and therefore which governance assumptions hold.
The key assumption: the governed artifact is not stable between reviews. An agent acting at machine speed can cause harm between any two review cycles. Governance must operate at the same speed and granularity as the system itself — enforcing policy over execution trajectories in real time, not just reviewing performance after the fact.
This is the paradigm of the agentic AI governance literature: the SSRN paper on scalable runtime governance, the Kurshan et al. agent-based regulator, the Pandey agentic AI governance framework, and Singapore's IMDA Model AI Governance Framework for Agentic AI.
The two tracks differ on four dimensions. These are differences in degree that become qualitative at the agentic end of the spectrum:
| Dimension | Model Risk | Agent Risk |
|---|---|---|
| Governed object | A static artifact (model, system, application) | A dynamic process (capability, agent, trajectory) |
| Temporal model | Periodic: validate before deployment, monitor after, revalidate on schedule | Runtime: enforce policy during execution, intervene in real time |
| Oversight feasibility | Human review between steps is feasible | Human review cannot keep pace with execution speed where the system exercises delegated decision authority |
| Risk classification axes | What the system is: materiality, complexity, rights impact | What the system does: agency, authority, action-space, recoverability |
A system with the same model and similar materiality can have vastly different risk depending on whether it operates with read-only access in a sandbox or write access to production databases. Traditional tiering cannot capture this distinction because its axes do not include agency or authority.
A system belongs on the Agent Risk Track when any of the following is true:
- The system can execute actions with side effects (write, transact, dispatch) without per-action human approval
- The system decomposes tasks into multi-step plans and selects execution paths autonomously
- The system's failure mode is a sequence of wrong actions rather than a wrong output
- Human oversight cannot keep pace with the system's execution speed where the system exercises delegated decision authority
- The system's outputs feed directly into downstream automated environments where execution velocity removes the possibility of meaningful human intervention before harm occurs
These criteria define a risk spectrum, not a binary gate. Many systems straddle both tracks — a GenAI copilot with limited tool access, for example. In such cases, apply the Agent Risk Track to any component where the system crosses the autonomy threshold; use the Model Risk Track for the rest. Document the classification decision and the evidence supporting it.
Edge cases to consider:
- Retrieval agents with no write authority: typically remain on the Model Risk Track
- Copilots with suggestion-only outputs: typically remain on the Model Risk Track
- Deterministic workflow orchestrators: typically remain on the Model Risk Track unless they select execution paths autonomously
- System-of-systems architectures (e.g., a model outputting signals to a separate automated executor): apply the Agent Risk Track to any component with autonomous action authority; document interface controls between model-risk and agent-risk components
Financial institutions already govern many systems dynamically:
- Algorithmic trading controls enforce pre-trade risk checks, position limits, and kill switches at microsecond speed
- Payment authorization systems validate transactions in real time against fraud rules and regulatory requirements
- Fraud engines continuously monitor transaction patterns and block suspicious activity
- Cybersecurity enforcement applies policy in real time through access controls, intrusion detection, and automated response
- Workflow orchestration enforces approval chains, segregation of duties, and escalation rules
These runtime controls are mature, well-understood, and integrated into banks' three-lines-of-defence structures. The BCBS Principles for Operational Resilience (2021) codify expectations for tolerance thresholds, mapping of critical operations, and testing under severe-but-plausible scenarios.
What agentic AI governance adds is not runtime enforcement per se — it is the governance of systems that autonomously plan, select tools, and adapt their behavior at machine speed. The novelty is in the combination of:
- Autonomous planning: the system decides what to do, not just how to do a pre-defined task
- Tool selection and execution: the system chooses which external systems to call and what actions to take
- Adaptive behavior: the system modifies its approach based on intermediate results, without per-step human direction
This combination stresses MRM's assumptions about stability between reviews and human-pace oversight, and it requires governance mechanisms that existing operational controls were not designed to provide — capability-level evidence, trajectory conformance testing, and policy enforcement over execution paths rather than over individual transactions.
Each row is a governance concept. The Model Risk Track column shows how that concept applies to traditional AI systems. The Agent Risk Track column shows how the same concept applies to agentic AI.
Where both columns say the same thing (governance, vendor, transparency), the concept is genuinely universal — it applies the same way regardless of system type. Where the columns diverge (inventory vs. capability catalogue, periodic validation vs. pooled evidence, compensating control vs. auditable oversight effectiveness), the divergence is the important finding — it reveals where traditional governance assumptions break down.
Where the Agent Risk Track column describes specific mechanisms (capability catalogues, policy monitors, tiered containment), these are illustrative of the state of the art as proposed in the cited sources, not prescriptive mandates. Alternative architectures exist (constitutional AI, decentralized agent ecosystems, capability sandboxing without trajectory governance, alignment-via-training approaches). The GSS most naturally applies to orchestrated enterprise agents with observable execution layers.
Source abbreviations: Fed = SR 26-2, PRA = SS1/23, EU = EU AI Act, EU-HR = Draft Commission Guidelines on the Classification of High-Risk AI Systems, FINMA = FINMA 08/2024, MAS = MAS AIRG, Turing = Move Fast Without Breaking the Bank, SSRN = Scalable Runtime Governance for Agentic AI, Kurshan = The Agentic Regulator, Pandey = The Agentic AI Governance Framework, H&E = Hacker & Eber, IMDA = IMDA Model AI Governance Framework for Agentic AI, FSB = FSB Financial Stability Implications of AI (2024) and Monitoring Adoption (2025), NIST = NIST AI RMF 1.0, NIST-GAI = NIST AI 600-1 Generative AI Profile, BCBS = BCBS Principles for Operational Resilience, CFPB = CFPB Circular 2022-03 and CFPB/DOJ/FTC/EEOC Joint Statement on Enforcement Against Discrimination and Bias in Automated Systems.
| # | Component | Model Risk Track | Agent Risk Track |
|---|---|---|---|
| 1 | Scope & governed object | The model or AI system. A static artifact that converts inputs to outputs. Scope defined by model definition (Fed), qualitative input/output (PRA), AI system per use case (EU), AI application (FINMA), AI model/system/use case (MAS). Where several AI systems form part of a more complex system, split architectures are assessed as a whole for high-risk classification (EU-HR). Cross-sector: AI system per OECD/ISO definition (NIST). | The capability or agent. A dynamic execution process defined by what it can do — its authority, action-space, permitted tools, and autonomy level. Scope includes the bounded set of actions, not just the input-output function (SSRN, IMDA, Pandey). Agentic AI systems that coordinate and interact through linked actions cannot claim Article 6(3) exemptions where the linked components serve an intended high-risk purpose (EU-HR). |
| 2 | Inventory / catalogue | Model inventory: comprehensive register of all models with risk classification, operating boundaries, validation status, and governance details. Extended by Turing to include prompt templates, RAG indices, and toolchains as dependency bill-of-materials. EU requires registration of high-risk AI in EU database (Art. 71). NIST requires mechanisms to inventory AI systems resourced according to organizational risk priorities (GOVERN 1.6). | Capability catalogue: versioned registry of reusable capabilities, each defined by authority scope, constraints, and evidence requirements (SSRN). Agent registry with risk classification per agent (Pandey). Agent identity and access control management (IMDA). NIST-GAI specifies inventory entry content including data provenance, foundation model versions, and human oversight roles (GV-1.6). In some architectures, model inventory may be supplemented or replaced by a capability catalogue; this shift is architecture-dependent. |
| 3 | Risk classification | Materiality x complexity (Fed, PRA). Impact x complexity x reliance (MAS). Materiality x probability including autonomy as factor (FINMA). Use-case-based rights impact classification: unacceptable / high / limited / minimal risk (EU). Article 6(3) filter mechanism exempts AI systems performing narrow procedural tasks from high-risk classification, but not where they materially influence individual decisions in a high-risk use case (EU-HR). Seven trustworthiness characteristics including fairness, safety, and security (NIST). | Agency x authority x impact x exposure x recoverability (SSRN). Autonomy x exposure (Pandey). Task complexity x autonomy x action-space x external access x system complexity (IMDA). Human-AI configuration as a named risk including automation bias, over-reliance, and algorithmic aversion (NIST-GAI). All add behavioral dimensions — what the system does, not just what it is. The axes are cumulative across tracks, not either/or. |
| 4 | Fairness, rights & prohibitions | Bias as risk factor in complexity assessment (PRA fn.12). Bias as model risk (FINMA). Fairness as lifecycle control with assessment requirements (MAS). Fundamental rights impact assessment for deployers of high-risk AI (EU Art.27). Prohibited practices — categorical ban on unacceptable-risk AI uses (EU Art.5). Three bias categories: systemic, computational/statistical, human-cognitive (NIST). Worked examples for credit scoring and insurance classification as high-risk use cases under Annex III Point 5(b) (EU-HR). US fair lending governance: ECOA and Regulation B require specific reasons for adverse action regardless of technology used — model opacity is not a defence (CFPB). Existing civil rights, fair lending, and consumer protection laws apply regardless of technology (CFPB/DOJ/FTC/EEOC Joint Statement). | Bias and discrimination as persistent systemic risk in agent decisions (Kurshan). Automation bias as explicit concern in human oversight (IMDA, MAS). Fairness testing across demographic groups (Turing). Harmful bias and homogenization as named GAI risk (NIST-GAI). Based on the reviewed sources, no agentic framework introduces materially new fairness obligations beyond what MAS and the EU already require, though this may reflect the early stage of agentic governance development rather than a principled exclusion. |
| 5 | Governance & accountability | Board and senior management ownership. Clear roles and responsibilities. SMF accountability regime (PRA). Internal audit of MRM practices (Fed). Cross-functional committee when AI risk is material (MAS). Provider vs. deployer obligations (EU Art.16, 26). GOVERN function as cross-cutting foundation for policies, accountability, diversity, culture, stakeholder engagement (NIST). Board approves operational resilience approach and tolerance for disruption (BCBS). | Same accountability structures apply, but: 1LoD/2LoD/Security-Ops split with explicit capability-catalogue ownership (SSRN). Use-case owner + technology risk + AI factory split (IMDA case study). Agent value chain accountability across organizational boundaries (IMDA). Governance SDK ownership (Pandey). FSB identifies governance challenges including model risk governance deficiencies and misaligned AI systems as systemic vulnerabilities (FSB). |
| 6 | Policies, procedures & policy-as-code | Board-approved policies covering the full model lifecycle. Quality management system (EU Art.17). Compliance assessment and reporting to board (PRA). Contract clauses for vendor transparency (Turing, MAS). Documented ICT and cyber security policies (BCBS). | Policies encoded as executable code: policy monitors as deterministic or hybrid functions that block prohibited state transitions in real time (SSRN). Governance SDK wrapping orchestration layer with configuration parameters — policy, environment, escalation, tool policies (Pandey). Temporal policy conformance — rules that change based on execution context (SSRN). Not all governance policy can be deterministically encoded; policy monitors handle codifiable rules while escalation to human judgment handles ambiguous cases. Go/no-go deployment thresholds and deactivation criteria (NIST-GAI). |
| 7 | Development / capability composition | Model development: algorithm selection, data governance, training, testing, documentation. Prompt design, RLHF, and RAG as governed subcomponents (Turing). Representativeness and bias testing in training data (EU Art.10). AI lifecycle dimensions: Application Context, Data/Input, AI Model, Task/Output (NIST). | Capability composition: a new use case is built by selecting capabilities from the catalogue and configuring authority scopes, not by building from scratch (SSRN). Planning guardrails, tool access controls (IMDA). Threat modelling and red-teaming as development inputs (IMDA, NIST-GAI). Value chain and component integration risk including fine-tuning, RAG, pre-trained models, and third-party plugins (NIST-GAI). |
| 8 | Validation & evidence | Independent validation before first use: conceptual soundness, outcomes analysis, replication (Fed, PRA, FINMA, MAS). Conformity assessment by notified bodies (EU Art.43). GenAI-specific probing of prompts, retrieval pipelines, uncertainty quantification (Turing). TEVV (testing, evaluation, verification, and validation) integrated throughout lifecycle (NIST). Creditors must validate the accuracy of post-hoc explanations — a creditor's lack of understanding of its own methods is not a cognizable defense (CFPB). | Pooled validation at capability level: evidence packs built per capability and reused across use cases, with failure modes mapped to regression tests (SSRN). Trajectory conformance testing under representative and adversarial scenarios (SSRN). Baseline safety testing, penetration testing, agent-evaluating-agent (IMDA). >=90% validation pass rate as KPI (Pandey). AI red-teaming including general public, expert, and combined approaches (NIST-GAI). These approaches are illustrative; the field has not converged on a standard validation methodology for agentic systems. |
| 9 | Human oversight & oversight effectiveness | Human review as compensating control: model users review outputs, override low-confidence results, follow escalation paths. Effective challenge by senior management (Fed, PRA). Human oversight as design requirement with training programs (EU Art.14, MAS). Human-AI configuration roles and oversight processes (NIST). | Oversight repositioned from runtime safety net to ex-ante design function: humans set policy, thresholds, and escalation rules; intervene only when triggered by runtime governance (SSRN). Oversight effectiveness audited: override rates, response times, rubber-stamping detection, automation bias monitoring (IMDA). Deny-by-default when approval infrastructure fails (IMDA). Dynamic boundaries via confidence thresholds (Pandey). Human-AI Configuration as a named risk: automation bias, over-reliance, emotional entanglement, algorithmic aversion (NIST-GAI). |
| 10 | Monitoring & telemetry | Periodic performance monitoring against thresholds: backtesting, out-of-sample testing, drift detection, data quality monitoring (Fed, PRA, FINMA, MAS). Post-market monitoring and serious incident reporting (EU Art.72-73). GenAI-specific: prompt/response drift, adversarial probing, deprovisioning (Turing). Production monitoring and risk tracking (NIST). Tolerance for disruption applied at the critical operations level; periodic testing under severe-but-plausible scenarios (BCBS). | Continuous, trajectory-level monitoring: governance-semantic telemetry over execution trajectories, including capability transition frequencies, escalation/abstention rates, near-miss patterns, and orchestration drift at the population level (SSRN). Real-time logging at machine speed with priority-based retention (IMDA). Drift detection service with MTTD <=24h and escalation SLA <=2h (Pandey). Agents monitoring other agents (IMDA). Content provenance tracking (NIST-GAI). Actionable monitoring indicators for AI adoption and third-party concentration (FSB). |
| 11 | Residual risk, containment & runtime governance | Post-model adjustments (PRA P5): documented, approved, independently reviewed. Operating boundaries (PRA). Fallback strategies and deprovisioning (Turing). Contingency plans with kill switches for high-risk AI (MAS). Residual risk documented to downstream acquirers and end users (NIST MANAGE 1.4). Disengagement and deactivation mechanisms (NIST MANAGE 2.4). Tolerance for disruption defines acceptable residual impact; exit strategies for third parties (BCBS). | Runtime governance: continuous authorisation, tool-intent gating, real-time policy enforcement over execution trajectories (SSRN). Tiered containment — three terminal states: Halt (verified completion), Escalate (insufficient confidence, partial evidence), Abstain (no verified result, incomplete trace) — each with distinct remediation workflows (SSRN). Safe modes, tool restrictions, human takeover (SSRN, IMDA). Escalation SLA <=2h (Pandey). Irreducible residual risk acknowledged — risk acceptance decision required (IMDA). Go/no-go deployment thresholds and staged release (NIST-GAI). These mechanisms are illustrative; the field has not converged on a standard architecture for runtime governance. |
| 12 | Third-party & supply chain | Vendor products validated to same standards; ongoing monitoring; document customizations (Fed). Outsourcing governance with additional controls and contractual clauses (PRA, FINMA). Third-party AI management: transparency, due diligence, supply chain assessment, concentration risk, right-to-audit (MAS). Model Cards and Datasheets for transparency (Turing). Deployer-to-provider transition under Art.25 — fine-tuning a third-party model makes you a provider (EU, H&E); distributors, importers, and deployers may also become subject to provider obligations where they substantially modify a system or modify its intended purpose (EU, EU-HR). Third-party software/data risk policies and monitoring (NIST). Hardware concentration, cloud dependencies, pre-trained model dependencies, nth-party risk (FSB). Due diligence before engagement, substitutability assessment, exit strategies (BCBS). | Third-party opacity as first-class risk: agents using external tools or models where visibility and control are limited (IMDA). Scoped API keys bounded by authorising human's permissions (IMDA). Third-party dependencies recorded during use-case onboarding (SSRN). Vendor models governed through standardized regulatory blocks (Kurshan). Third-party risk management with SLAs, due diligence, SBOMs, and contingency actions (NIST-GAI). Liability allocation: when an autonomous agent causes harm, the primary governance question is who bears legal liability — the model provider, the orchestration platform, or the deploying institution. Third-party API deprecation/drift liability clauses and indemnification boundaries for uncontainable agentic actions are emerging concerns not yet addressed by existing frameworks. |
| 13 | Transparency & explainability | Documentation of purpose, data, model, testing, and fallback (FINMA). Technical documentation for high-risk AI (EU Art.11). Plain-language instructions to deployers on capabilities, accuracy limits, performance degradation (EU Art.13, H&E). Explainability assessed where decisions must be justified (FINMA, MAS). SHAP/LIME and explanation stability testing (Turing). Three-part decomposition: transparency (what), explainability (how), interpretability (why) (NIST). ECOA requires specific and accurate reasons for adverse action — technology opacity is not a defence (CFPB). | Logging of agent-to-system interactions at machine speed (IMDA). Chain-of-thought explicitly not a faithful explanation — do not rely on it for explainability (IMDA). Causal trace replay for decision reconstruction >=99% (Pandey). Governance-semantic telemetry enables trajectory reconstruction for any run (SSRN). Modular regulatory blocks produce audit trails (Kurshan). Content provenance via watermarking, cryptographic signatures, and metadata (NIST-GAI). Deterministic behavioral reconstruction (causal tracing) is a prerequisite for forensic accountability; it does not resolve the latent-space explainability of the underlying model, which remains an open research problem. |
| 14 | AI literacy & change management | AI literacy as legal obligation for all staff dealing with AI, effective February 2025 (EU Art.4). High-risk classification obligations apply from August 2026 (Annex III) and August 2027 (Annex I), with Omnibus postponement to December 2027 and August 2028 respectively (EU-HR). Training for oversight personnel (MAS). Competency requirements for model developers and validators (PRA, Fed). Periodic revalidation driven by scheduled review cycles (PRA). AI risk management training and diverse teams (NIST). Staff training in business continuity (BCBS). | Governed change triggers — explicit events (model, tool, prompt, memory, or authority updates) that require re-evaluation before the system resumes (SSRN). Risk-categorized review: minor changes follow lighter review; material changes require full governance review; critical changes require immediate re-risk assessment (IMDA). Failure modes from incidents promoted into regression tests (SSRN). Training on GAI capabilities/limitations and digital content transparency (NIST-GAI). |
Rows 1, 2, 3, 7, 8, 9, 10, and 11 show the strongest divergence between the two tracks. These are the components where the paradigm shift from model risk to agent risk is most visible:
-
Rows 1-2 (Scope and Inventory): The governed object shifts from a static artifact (model) to a dynamic process (capability, agent). In some architectures, model inventory may be supplemented or replaced by a capability catalogue; this shift is architecture-dependent, not universal.
-
Row 3 (Risk classification): Classification axes expand from intrinsic properties (materiality, complexity) to behavioral properties (agency, authority, action-space, recoverability). A system can be low materiality but high risk if it has write access to production systems.
-
Rows 7-8 (Development and Validation): Development shifts from building models to composing capabilities. Validation shifts from per-model independent review to pooled evidence at the capability level. The unit of governance shifts in architectures that adopt capability-centric design.
-
Row 9 (Human oversight): Oversight shifts from a compensating control that works at human speed to a design function whose effectiveness must be audited. The question changes from "is there a human in the loop?" to "does the human in the loop actually work?"
-
Rows 10-11 (Monitoring and Containment): Monitoring shifts from periodic observation to continuous trajectory-level telemetry. Containment shifts from post-model adjustments and fallback strategies to real-time policy enforcement and tiered terminal states (Halt/Escalate/Abstain).
Rows 4, 5, 6, 12, 13, and 14 show either genuine universality or convergence in direction:
-
Row 4 (Fairness): The obligation exists in newer frameworks (EU, MAS, US fair lending law) and is absent from older ones (Fed, PRA). The gap is closing, not widening. The convergence on fairness obligations does not imply the Agent Risk Track is redundant — it operationalizes fairness differently (e.g., via trajectory testing vs. dataset bias assessment).
-
Row 5 (Governance): Accountability structures are similar across both tracks. The difference is in what is owned (a model vs. a capability catalogue), not who owns it.
-
Row 6 (Policies): Both tracks have policies. The difference is medium (documents vs. executable code), not concept.
-
Row 12 (Third-party): Vendor governance applies in both tracks. The agent track adds specific concerns (third-party opacity, liability allocation) but does not replace the underlying obligations.
-
Row 13 (Transparency): The obligation is universal. The mechanisms differ (periodic documentation vs. machine-speed telemetry), but the intent is the same.
-
Row 14 (Literacy & change): Both tracks require training and change management. The agent track makes change triggers more explicit and ties them to runtime enforcement.
SR 26-2 does not mention fairness or bias. SS1/23 mentions bias only as a risk factor for complexity tiering (footnote 12). Neither treats fairness as a standalone governance obligation.
By contrast, MAS AIRG makes fairness a lifecycle control with assessment requirements. The EU AI Act requires fundamental rights impact assessments for deployers of high-risk AI (Art. 27) and prohibits certain AI uses categorically (Art. 5). The NIST AI RMF identifies three categories of bias — systemic, computational/statistical, and human-cognitive — and integrates fairness into its trustworthiness characteristics.
US fair lending governance predates and operates independently of the EU AI Act's fairness provisions. ECOA and Regulation B require creditors to provide specific and accurate reasons for adverse action, regardless of the technology used. The CFPB has confirmed that model opacity is not a defence — "a creditor's lack of understanding of its own methods is not a cognizable defense against liability." The CFPB/DOJ/FTC/EEOC Joint Statement (April 2023) affirms that existing civil rights, fair lending, and consumer protection laws apply regardless of technology, and identifies three sources of discrimination risk in automated systems: data and datasets, model opacity, and design and use context.
The absence of fairness from traditional MRM is not a principled exclusion — it is a gap that is closing as frameworks are updated. The GSS makes this gap visible by giving fairness its own row (Row 4) rather than subsuming it under risk classification.
In traditional MRM, human oversight works: a model user reviews the output, overrides if necessary, and escalates when uncertain. This is feasible because the model produces outputs at human scale and the user has time to assess each one.
Three structural limitations emerge at agentic scale (identified by the SSRN paper):
- Speed mismatch: Agentic systems operate at machine speed; human review operates at human speed. Comprehensive inspection of every decision is infeasible.
- Visibility mismatch: Reviewers see compressed summaries or final outputs, not the full execution trajectory. Intermediate reasoning steps are obscured.
- Cognitive overload: Complex multi-step workflows generate more information than humans can process in the time available.
These limitations do not eliminate human oversight, but they change its function. Rather than acting as a runtime safety net for every decision, oversight must shift toward policy and threshold design, verification and approval structures, and the review of monitoring evidence.
IMDA adds a further insight: oversight effectiveness must be audited. Low override rates may signal rubber-stamping. Short response times may signal automation bias or review fatigue. If the approval infrastructure fails, the system should deny by default rather than proceed unsupervised.
NIST-GAI treats Human-AI Configuration as a named risk category, identifying not only automation bias and over-reliance but also emotional entanglement and algorithmic aversion as governance concerns.
The GSS captures this shift in Row 9: the Model Risk Track treats oversight as a compensating control; the Agent Risk Track treats it as an auditable effectiveness metric.
Traditional MRM classifies risk by what the system is: its materiality (financial significance) and complexity (model type, data type, transparency). These axes work well for models that produce outputs reviewed by humans.
For agentic systems, these axes are necessary but insufficient. A system with the same model and similar materiality can have vastly different risk depending on:
- Agency — Can the system plan and adapt, or does it follow fixed procedures?
- Authority — What actions is it permitted to take? Read-only? Write access? Transaction authority?
- Action-space — What tools, systems, and data can it access?
- Recoverability — If something goes wrong, can it be detected, contained, and reversed?
The SSRN paper proposes five dimensions (agency x authority x impact x exposure x recoverability). IMDA proposes five factors (task complexity x autonomy x action-space x external access x system complexity). Both add behavioral dimensions absent from traditional tiering.
The GSS captures this in Row 3: the Model Risk Track uses materiality and complexity; the Agent Risk Track adds agency, authority, and recoverability. The axes are cumulative, not contradictory.
Periodic monitoring and runtime governance serve different functions:
- Periodic monitoring observes whether a system's performance has degraded since the last review. It reports findings after the fact. It assumes the system is stable between reviews.
- Runtime governance enforces policy during execution. It blocks prohibited state transitions in real time. It assumes the system can cause harm between review cycles.
The distinction is qualitative at the agentic end of the spectrum. As structured in current MRM frameworks, periodic monitoring is not designed to catch mid-execution policy violations in systems that act autonomously at machine speed — a tool call that should have been blocked, an approval step that was skipped, a constraint that was violated during a multi-step plan. However, financial institutions already use runtime controls for many operational systems (algorithmic trading, fraud detection, payment authorization). The challenge is extending these controls to systems that autonomously plan and select tools, not introducing runtime enforcement per se.
The GSS captures this distinction in Row 11: the Model Risk Track uses post-model adjustments and fallback strategies; the Agent Risk Track uses continuous authorisation, tool-intent gating, and tiered containment (Halt/Escalate/Abstain).
In traditional MRM, a bank that uses a vendor model validates it to its own standards and monitors it. The roles are clear: the bank is the model user and the vendor is the provider. While MRM frameworks do address model customization, the EU AI Act's explicit reclassification of a deployer as a provider with full conformity obligations has no direct parallel in traditional MRM.
The EU AI Act creates a more dynamic framework. Under Article 25, a deployer who fine-tunes a third-party model for a high-risk use case (e.g., credit scoring) becomes a provider with full obligations — including conformity assessment, technical documentation, and CE marking. This role transition means the EU AI Act's structural delivery mechanisms resemble traditional pre-deployment gates, but its regulatory architecture explicitly accounts for lifecycle mutability, straddling the line between static governance and dynamic system evolution.
The GSS captures this in Row 12 (Third-party): the Model Risk Track notes the deployer-to-provider transition as a concept unique to the EU AI Act.
Traditional governance policies are board-approved documents: they specify what should be done, who is responsible, and what the thresholds are. They are interpreted by humans and enforced through organizational processes.
In agentic AI governance, policies become executable code. The SSRN paper proposes policy monitors — deterministic or hybrid functions that check each state transition against permitted paths and block violations in real time. Pandey proposes a governance SDK that wraps the orchestration layer and enforces policy through configuration parameters. Kurshan proposes modular regulatory blocks — software agents that enforce specific regulations (GDPR blocks, fair lending blocks, AI Act blocks). NIST-GAI specifies go/no-go deployment thresholds and deactivation criteria as executable policy.
Not all governance policy can be deterministically encoded. Policies involving interpretation, balancing tests, contextual judgment, and legal ambiguity require human judgment. Policy-as-code handles codifiable rules; escalation to human judgment handles ambiguous cases. A policy bug is a governance failure, not just a documentation error.
The GSS captures this in Row 6: the Model Risk Track uses board-approved policies and quality management systems; the Agent Risk Track uses policy-as-code, governance SDKs, and temporal policy conformance.
When an autonomous agent initiates a series of tool calls that execute an unauthorized transaction due to an upstream foundational model update, the primary corporate governance issue is identifying who bears legal liability — the model provider, the orchestration platform developer, or the deploying institution. Neither MRM frameworks nor existing agentic governance papers adequately address this question. The GSS identifies liability allocation as a governance gap that requires attention as agentic systems are deployed in production.
The GSS was developed through systematic analysis of the following documents.
| Document | Issuer / Author | Date | Type |
|---|---|---|---|
| AI Risk Management Framework (AI RMF 1.0) | NIST | Jan 2023 | Cross-sector framework |
| Principles for Operational Resilience | BCBS | Mar 2021 | Macro-prudential |
| Joint Statement on Enforcement Against Discrimination and Bias in Automated Systems | CFPB, DOJ, FTC, EEOC | Apr 2023 | US enforcement |
| Circular 2022-03: Adverse Action Notification Requirements | CFPB | May 2022 | US enforcement |
The GSS analyzes 19 governance documents. It does not cover ISO/IEC 42001:2023 (AI Management System), ISO/IEC 23894:2023 (AI Risk Management), the OECD AI Principles, or OMB M-24-10 (US federal agency AI governance). These frameworks are widely used by financial institutions; their inclusion would strengthen the analysis and is deferred to future work.
The GSS is a conceptual comparative framework, not an operational deployment guide. Several important limitations and open problems should be acknowledged:
Runtime governance is immature. Most mechanisms described in the Agent Risk Track (policy monitors, trajectory conformance testing, tiered containment) are research proposals or early-stage implementations, not deployed at scale. Their reliability under production conditions — including false-positive escalation rates, telemetry standardization, and runtime policy composability — is unresolved.
Trajectory verification is an open problem. Verifying that an agentic system's execution follows permitted paths under all scenarios, including adversarial manipulation of monitors, remains a research challenge.
Policy-as-code has limits. Not all governance policy can be deterministically encoded. Policies involving interpretation, balancing tests, contextual judgment, and legal ambiguity require human judgment. The boundary between codifiable and judgment-dependent policy is not well defined.
Multi-agent coordination risk is largely unaddressed. Emergent coordination risk, delegated authority chains, recursive delegation, agent swarms, inter-agent trust, dynamic role assignment, and self-modifying workflows are among the hardest governance problems. Current frameworks assume relatively bounded agents.
Architectural pluralism. The GSS most naturally applies to orchestrated enterprise agents with observable execution layers. Alternative architectures — constitutional AI, decentralized agent ecosystems, market-based coordination, probabilistic policy enforcement, capability sandboxing without trajectory governance, formal methods approaches, alignment-via-training approaches, constrained decoding governance — may require different governance approaches.
Verification and audit of runtime controls. Neither MRM frameworks nor agentic governance papers fully address how regulators or internal audit would verify compliance with runtime governance mechanisms. Sampling strategies for trajectory review, evidence requirements for policy monitors, and roles for internal/external assurance remain open questions.
No empirical grounding. The GSS is based on regulatory and academic sources, not on implementation evidence, institutional case studies, or production deployment lessons. Its findings should be validated against operational experience as agentic AI systems are deployed in financial institutions.
To classify a system using the GSS transition criterion, answer the following questions in order:
- Does the system execute actions with side effects without per-action human approval? If yes → Agent Risk Track. If no → continue.
- Does the system decompose tasks into multi-step plans and select execution paths autonomously? If yes → Agent Risk Track. If no → continue.
- Is the system's failure mode a sequence of wrong actions rather than a wrong output? If yes → Agent Risk Track. If no → continue.
- Does human oversight fail to keep pace where the system exercises delegated decision authority? If yes → Agent Risk Track. If no → continue.
- Do the system's outputs feed directly into downstream automated environments where execution velocity removes the possibility of meaningful human intervention? If yes → Agent Risk Track (for the interface component). If no → Model Risk Track.
For systems that straddle both tracks: apply the Agent Risk Track to any component that crosses an autonomy threshold; apply the Model Risk Track to the rest. Document the classification decision and the evidence supporting it.
Consider an agentic system that: receives a loan application, retrieves applicant data from multiple sources, assesses creditworthiness using an LLM, determines pricing, generates an offer letter, and submits it to the loan origination system — all without per-action human approval.
Classification: The system crosses multiple transition criteria (actions with side effects, autonomous task decomposition, sequential failure modes). It belongs on the Agent Risk Track.
Row-by-row analysis:
| Row | Model Risk Track (partial) | Agent Risk Track |
|---|---|---|
| 1 | The credit model component (scoring function) is a static artifact | The overall system is a dynamic execution process |
| 2 | The scoring model is in the model inventory | The end-to-end workflow is in the capability catalogue |
| 3 | Classified by materiality and complexity | Classified additionally by authority (write to loan origination), action-space (applicant data, pricing, origination), recoverability (can an offer be rescinded?) |
| 4 | ECOA adverse action notice requirements apply; FRIA required under EU AI Act | Trajectory-level fairness testing: does the agent's multi-step process produce disparate outcomes across demographic groups? |
| 6 | Board-approved credit policy | Policy-as-code: the agent must not offer terms below approved thresholds, must not skip disclosure steps |
| 9 | Human underwriter reviews offer before submission | Human review redesigned: underwriter reviews exception cases flagged by runtime governance; override rates and response times audited |
| 11 | Fallback: manual underwriting | Runtime governance: agent must not submit without completing all required disclosures; Escalate to human if confidence below threshold |
- Classify the system using the transition criterion (Section 7.1).
- For each row, identify which track applies to your system or component.
- Where the system straddles both tracks, apply the Agent Risk Track to any component crossing an autonomy threshold and document the interface controls.
- Compare requirements across jurisdictions by reading across the relevant row and identifying which sources impose obligations.
- Prioritize gaps by focusing on rows where the tracks diverge most (Rows 1-3, 7-11) — these are where existing governance is most likely insufficient.
1LoD / 2LoD — First line of defense / second line of defense. 1LoD (business units) owns model development, use, and monitoring. 2LoD (risk, compliance) provides independent challenge and validation.
Adverse action notice — Under ECOA and Regulation B, a creditor must provide a statement of specific and accurate reasons when taking adverse action on a credit application. This obligation applies regardless of the technology used to make the decision.
Backtesting — Testing a model by comparing its outputs to known historical outcomes.
Compensating control — A measure that reduces the risk of a control weakness. In traditional MRM, human review of model outputs is a compensating control.
Effective challenge — The process by which senior management and independent validators critically assess model assumptions, limitations, and outputs.
FINMA — Swiss Financial Market Supervisory Authority (Eidgenössische Finanzmarktaufsicht).
Kill switch — A mechanism for rapidly deactivating an AI system or model in response to a failure or incident.
MAS — Monetary Authority of Singapore.
Materiality — The significance of a model's output to a firm's business decisions, typically measured by financial exposure and regulatory importance.
Model inventory — A comprehensive register of all models in use or development, including risk classification, validation status, and governance details.
Operating boundary — The permitted scope of a model's use, including data sources, user populations, and decision domains. Defined in SS1/23 and extended by the Turing paper as "operating envelopes."
Operational resilience — The ability of a bank to deliver critical operations through disruption. Defined by BCBS as encompassing tolerance for disruption, mapping of critical operations, and testing under severe-but-plausible scenarios.
PMA (post-model adjustment) — An adjustment to a model's output after the model has produced it, governed by a specific framework under SS1/23 Principle 5.
PRA — Prudential Regulation Authority, a subsidiary of the Bank of England responsible for prudential regulation of banks, building societies, and insurers.
SR 11-7 / SR 26-2 — US Federal Reserve supervisory letters on model risk management. SR 11-7 (2011) was the original guidance; SR 26-2 (April 2026) is the revision that supersedes it.
SS1/23 — Supervisory Statement 1/23 from the PRA, setting out model risk management principles for banks. Originally published May 2023, updated April 2026.
SMF — Senior Management Function. The PRA's regime for assigning individual accountability to named senior managers for specific risk areas.
Tolerance for disruption — The level of disruption from any type of operational risk a bank is willing to accept, given a range of severe but plausible scenarios. Defined by BCBS.
AI literacy — The obligation (Art. 4) for all staff dealing with AI to have sufficient understanding of the technology, its capabilities, and its limitations. Effective February 2025.
CE marking — The conformity marking required before a high-risk AI system can be placed on the EU market, indicating compliance with the AI Act's requirements.
Conformity assessment — The process (Art. 43-48) by which a provider of a high-risk AI system demonstrates compliance with the Act's requirements before market entry. May involve third-party notified bodies.
Deployer — Any entity that uses a high-risk AI system under its authority in a professional capacity. Carries obligations including human oversight, logging, and fundamental rights impact assessment (Art. 26-27).
FRIA (Fundamental Rights Impact Assessment) — Required under Art. 27 before a deployer first uses a high-risk AI system in areas including credit scoring and insurance. Analyses effects on equality, data protection, privacy, and fundamental rights. Has no equivalent in financial services regulation.
GPAI (general-purpose AI model) — A model that can be used for a wide range of tasks without substantial modification. Regulated separately under Chapter V of the AI Act.
Notified body — An independent organization designated by an EU member state to conduct conformity assessments of high-risk AI systems.
Provider — Any entity that develops an AI system and places it on the market or puts it into service under its own name. Carries the most extensive obligations (Art. 16-22), including risk management, data governance, documentation, and conformity assessment.
Prohibited practices — AI uses categorically banned under Art. 5, including social scoring and certain forms of biometric identification. No equivalent in MRM frameworks.
Terms marked with their maturity status: [Regulatory requirement] where the concept is mandated by law; [Emerging practice] where it is being adopted but not yet standardized; [Research proposal] where it is proposed in academic or practitioner papers but not yet widely adopted.
Action-space — The range of actions, tools, and permissions available to an agent. A key risk factor: a system with write access to production databases has a different risk profile than one with read-only access to a sandbox. [Regulatory requirement] (IMDA)
Bounded autonomy — The design principle that an agentic system's autonomy is constrained by explicitly defined authority scopes, action-space limits, and intervention thresholds. [Emerging practice]
Capability — A bounded class of actions that an agentic system can execute, defined by: (i) authority (permitted tools/resources and their scope), (ii) constraints (authorisation requirements, prohibited sequences, time windows), and (iii) evidence requirements (metrics, thresholds, telemetry). [Research proposal] (SSRN)
Capability catalogue — A versioned registry of reusable capabilities, each with authority scope, constraints, and evidence requirements. Enables validation and monitoring to be shared across use cases that compose the same capabilities. In some architectures, may supplement or replace per-model inventory. [Research proposal] (SSRN)
Escalate (terminal state) — One of three terminal states in tiered containment. The system reached a candidate outcome but cannot confirm it with sufficient confidence. Partial but informative evidence is available for human review. [Research proposal] (SSRN)
Governance SDK — A software development kit that wraps the orchestration layer (e.g., Langchain, Crew AI) and enforces governance policies through configuration parameters including policy rules, escalation details, tool policies, and logging requirements. [Research proposal] (Pandey)
Governance-semantic telemetry — Instrumentation of agentic execution that produces telemetry designed for governance purposes (policy conformance, trajectory reconstruction, population-level monitoring), not just operational performance. [Research proposal] (SSRN)
Halt (terminal state) — One of three terminal states in tiered containment. The system completed its task within the allowed trajectory length and produced a verified result. [Research proposal] (SSRN)
Human-on-the-loop — A configuration where a human monitors the system's execution and can intervene when triggered, but does not review every action. Contrasts with human-in-the-loop, where each action requires human approval. [Emerging practice]
MCP (Model Context Protocol) — An open-standard protocol for connecting AI agents to external tools and data sources, initiated by Anthropic in late 2024. IMDA identifies MCP as a potential governance layer because it sits between the agent and the systems it accesses. Market adoption and permanence are not yet established. [Illustrative implementation]
Policy monitor — A deterministic or hybrid function that checks each state transition in an agentic execution against permitted paths and blocks violations in real time. Not all governance policy can be deterministically encoded; policy monitors handle codifiable rules while escalation to human judgment handles ambiguous cases. [Research proposal] (SSRN)
Runtime governance — The real-time monitoring and enforcement of policy over an agentic system's execution trajectory. Includes continuous authorisation, tool-intent gating, temporal and path conformance checking, drift monitoring, and tiered containment. [Emerging practice] (SSRN, IMDA)
Tiered containment — A runtime governance mechanism with three terminal states: Halt (verified completion), Escalate (insufficient confidence, partial evidence), and Abstain (no verified result, incomplete trace). Each state has distinct remediation and monitoring requirements. [Research proposal] (SSRN)
Trajectory — The execution trace of an agentic system: a sequence of capability invocations, state transitions, tool calls, approval events, and control decisions. The object of runtime compliance. [Research proposal] (SSRN)
Trajectory conformance — Testing whether an agentic system's execution follows permitted paths under both representative and adversarial scenarios. Supplements traditional backtesting for systems whose behavior is sequential rather than point-in-time. [Research proposal] (SSRN)
Agent Risk Track — The track of the GSS for systems whose dominant risk is a wrong action at machine speed. Governed by runtime enforcement, capability catalogues, trajectory-level monitoring, and auditable oversight effectiveness.
Model Risk Track — The track of the GSS for systems whose dominant risk is a wrong output. Governed by periodic validation, model inventory, performance monitoring, and human review as compensating control.
Transition criterion — The set of conditions under which a system moves from the Model Risk Track to the Agent Risk Track: side-effect authority without per-action approval, autonomous task decomposition, sequential failure modes, speed mismatch with human oversight, or downstream automation velocity. These define a risk spectrum, not a binary gate.