SR 26-2 pushes AI model risk governance into agentic workflows

At a glance

What this is: SR 26-2 is the 2026 U.S. banking model risk update that expands governance from traditional models to AI, LLMs, vendor systems, and agentic workflows.

Why it matters: It matters because IAM, NHI, and AI governance teams now need auditability, ownership, and control evidence for systems that can call tools, write to records, and influence material decisions.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Openlayer's analysis of SR 26-2 model risk management updates for AI

Context

SR 26-2 changes the governance baseline for AI model risk because it treats AI/ML systems, LLMs, vendor models, and agentic architectures as in-scope when they materially influence decisions. For AI model quality programmes, the question is no longer whether a tool looks like a traditional statistical model, but whether it produces decision-shaping outputs that need lifecycle validation and audit evidence.

That shift has a direct identity governance overlap whenever AI systems act with delegated access, call external tools, or write into systems of record. In practice, model governance now intersects with NHI controls such as service account ownership, token scope, auditability, and offboarding, because an agent that can act in production behaves like a governed non-human actor, not a passive analytics asset.

Key questions

Q: How should teams govern AI systems that can take actions as well as generate outputs?

A: Treat the agent as a governed actor, not just a model output stream. Require action-level logging, tool-call traceability, authorization boundaries, and approval gates before the system can write to records or invoke downstream tools. If an AI system can change state, its authority must be scoped, monitored, and revocable like any other privileged non-human identity.

Q: Why do vendor-supplied AI models still need internal validation under model risk rules?

A: Because governance follows the use case, not the supplier. If a third-party model materially influences a regulated or consequential decision, the institution still owns the validation obligation, the monitoring cadence, and the audit trail. Vendor attestations may support due diligence, but they do not replace internal evidence that the model behaves within approved bounds.

Q: What breaks when model inventories do not include LLMs and agentic workflows?

A: Exclusion claims become weak, ownership becomes unclear, and validation gaps stay hidden until an examiner or incident exposes them. Teams then cannot prove whether the system was in scope, who approved it, or whether it was monitored at all. A missing inventory entry is therefore a governance failure, not just an administrative miss.

Q: What frameworks align best with SR 26-2 for AI governance programmes?

A: NIST AI RMF is the clearest mapping for governance, risk identification, measurement, and ongoing management. For adversarial behaviour and AI-specific threat thinking, MITRE ATLAS helps structure attack-aware controls. Where agentic systems use delegated identities or secrets, NHI governance and lifecycle controls should sit alongside model risk oversight.

Technical breakdown

How SR 26-2 expands the model perimeter

SR 26-2 tightens the definition of a model around two tests: quantitative methods must produce the output, and that output must inform material business decisions. That pulls vendor scoring engines, LLM-based recommendation systems, and third-party APIs into scope when they shape credit, fraud, underwriting, or customer decisioning. The practical result is that exclusion claims need evidence, not labels. Teams can no longer rely on informal distinctions such as "tool" versus "model" when the output drives a regulated decision path.

Practical implication: Build a defensible inventory that records why each AI system is in or out of scope, with documented exclusion evidence where needed.

Why materiality-based tiering changes validation work

Materiality-based tiering formalises a simple but demanding idea: validation depth should match potential harm, but the justification for that depth must be documented. High-materiality models require independent review, outcome testing, and ongoing monitoring against defined thresholds. Lower-tier models can have reduced scope, but only when the risk rationale is explicit and repeatable. AI and LLM systems complicate the picture because their behaviour shifts with input distribution, making tiering itself part of the control design.

Practical implication: Treat tier assignment as a governed decision with named owners, risk criteria, and reviewable justification at every boundary.

Why agentic systems require action-level audit trails

Agentic systems do not just generate outputs. They sequence tool calls, invoke external services, modify records, and may trigger sub-agents, which means the governed object is the action chain, not only the final response. SR 26-2 therefore pushes teams toward logs that can reconstruct what the agent did, in what order, under which authorisation state, and with which inputs. A final output log is insufficient because it records the result but not the delegated execution path that produced it.

Practical implication: Instrument tool calls, authorization context, and decision sequences so auditors can reconstruct each agent action end to end.

NHI Mgmt Group analysis

Action-level governance is now the decisive control boundary for agentic AI. SR 26-2 shows that output-level review is not enough when a system can call tools, modify records, and chain decisions inside production workflows. That creates a governance requirement closer to privileged execution than to ordinary model oversight. For IAM and NHI teams, the practical conclusion is that agent identity, delegated authority, and action logging now belong in the same control conversation as model validation.

Model inventory gaps have become an examiner finding, not an internal housekeeping issue. The guidance makes exclusion harder to defend and shifts the burden onto the model owner to prove why a system is out of scope. That matters because AI estates often grow through product teams, API integrations, and vendor services that never pass through a central register. Model inventory gap: the failure mode where AI systems influence decisions before any formal ownership, validation, or monitoring record exists. Practitioners should treat that gap as a governance defect, not a documentation problem.

Vendor attestations do not transfer validation accountability. SR 26-2 makes clear that the institution using the model owns the governance outcome, regardless of who built it. That aligns with a broader identity lesson: delegated capability still requires local control. In regulated AI programmes, the control objective is not trust in the supplier, but proof that the system is observed, bounded, and reviewable inside the institution’s own governance stack.

The most important shift is from observation to enforcement. Monitoring dashboards can show drift, but SR 26-2 expects deployment gates, threshold checks, and documented escalation paths that stop promotion when criteria are not met. That is the same governance pattern security teams use when they move from passive detection to policy enforcement. Practitioners should assume auditors will ask for evidence that controls can block unsafe release, not merely report it.

AI governance now overlaps with NHI governance at the point of delegated execution. When an agent uses a service account, token, or API credential, the model problem becomes an identity problem. The relevant question is not only whether the model is accurate, but whether its authority is scoped, attributable, and revocable. Security teams should therefore align model risk controls with NHI ownership, secret lifecycle, and privilege boundaries.

What this signals

Identity governance will become part of AI model governance wherever agents can act on behalf of the enterprise. The practical signal is that model risk teams and IAM teams can no longer operate in separate lanes when a system uses delegated credentials, service accounts, or API keys. A useful way to frame this is as an agent authority boundary, the point where model behaviour becomes privileged execution and must be controlled with the same care as other non-human access.

Programmes should also expect examiners to ask for evidence of enforcement, not only monitoring. The relevant control pattern is familiar to identity practitioners: ownership, scope, revocation, and auditability. For reference, the NIST Cybersecurity Framework 2.0 and the NHI Lifecycle Management Guide both map cleanly to the governance problem that SR 26-2 is surfacing across AI estates.

For practitioners

• Inventory every in-scope AI system Create a register that includes internal models, vendor APIs, LLM-based workflows, and agentic systems that influence material decisions. Record owner, use case, decision impact, validation status, and exclusion rationale where applicable.
• Tie tiering to documented materiality criteria Define the factors that determine high, medium, and low materiality, then require recorded justification whenever a model crosses a tier boundary. Make the rationale reviewable by risk, audit, and model governance teams.
• Instrument action-level audit trails for agents Log each tool call, input set, authorisation state, and downstream action for agentic workflows so the full decision sequence can be reconstructed. Final output logs are insufficient for examination or incident review.
• Enforce deployment gates, not just monitoring Block promotion when evaluation thresholds, fairness checks, drift limits, or documentation requirements are not met. Use enforcement controls so governance evidence is created before production release, not after a failure.
• Align AI ownership with identity governance Where systems use service accounts, tokens, or API keys to act, assign clear ownership for both the model and the delegated identity. Review secret scope, rotation, and revocation alongside model approval and monitoring.

Key takeaways

• SR 26-2 turns AI model risk from a documentation exercise into an auditable control problem that reaches vendor models and agentic workflows.
• The most important governance gap is no longer whether a tool is called a model, but whether it can influence material decisions without traceable ownership and enforcement.
• Security and identity teams should align model inventories, delegated access controls, and action-level logging now, before examiners treat the gap as a control failure.

Key terms

• Materiality-Based Tiering: A risk classification approach that assigns different levels of validation and oversight based on the potential impact of a model’s failure. In model risk management, the tier determines how much independent testing, documentation, and monitoring the institution must maintain.
• Interaction-Level Audit Trail: A record that captures the full AI session rather than only network traffic or file events. It ties the prompt, model response, identity, and policy response together so auditors can reconstruct what happened and why the control acted the way it did.
• Model Inventory: A central record of all models in use, including owners, purpose, risk tier, lifecycle state, and control history. Inventory is the starting point for governance because organisations cannot validate, monitor, or retire models they cannot reliably identify.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.

What's in the full article

Openlayer's full article covers the operational detail this post intentionally leaves for the source:

• The article breaks down the SR 11-7 to SR 26-2 differences in a way that supports examiner-ready implementation planning.
• It shows how Openlayer maps evaluation results, drift thresholds, and deployment events into a structured audit trail.
• It explains how deployment gates enforce pass or fail decisions when validation criteria are not met.
• It expands the discussion of agentic AI governance at the action level, including tool-call traceability and decision sequencing.

👉 Openlayer's full post covers the validation workflow, audit trail structure, and agentic governance details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of delegated access and control boundaries. It is designed for practitioners who need to connect identity governance to operational security programmes.