SR 11-7 Model Risk Management Applied to Coding Agents

On April 17, 2026, the Federal Reserve, the OCC, and the FDIC jointly issued SR 26-2, retiring SR 11-7 after fifteen years as the baseline for model risk management in US banking. The replacement guidance keeps the conceptual skeleton of its predecessor, but it walks away from the AI systems banks are putting into production fastest. That gap, and how a bank might close it on its own, is the subject of this piece.

What SR 26-2 Changed

SR 11-7 governed model risk management at US banks from April 4, 2011, until April 17, 2026. On that date, the Fed, the OCC, and the FDIC jointly released SR 26-2 (also issued as OCC Bulletin 2026-13 and FDIC FIL-15-2026), which supersedes and replaces both SR 11-7 and SR 21-8, the 2021 interagency statement on model risk in Bank Secrecy Act and anti-money laundering systems. The change was not a trim or an update. OCC Bulletin 2026-13 simultaneously rescinded OCC Bulletin 2011-12 (the OCC's companion to SR 11-7), OCC Bulletin 2021-19 (the BSA/AML model risk bulletin), OCC Bulletin 1997-24 (the credit scoring examination guidance), and the Model Risk Management booklet of the Comptroller's Handbook. Four separate issuances went down at once, and the accumulated interpretive layer went with them.

That matters because an institution that lost only SR 11-7 would still have had the BSA/AML statement and the Handbook booklet to anchor a validation methodology against. Losing all four removes the operating manual itself, so banks have to rebuild their governance documentation from a much thinner base text. SR 26-2 speaks most directly to larger banking organizations supervised by the Federal Reserve, but its principles carry weight across the broader supervisory landscape. Credit underwriting models, fraud detection systems, and transaction monitoring tools built on traditional statistics and machine learning generally stay within its scope, and the guidance keeps the conceptual core of validation: conceptual soundness, outcomes analysis, and ongoing monitoring. What it drops is the prescriptive detail. SR 26-2 moves from a step-by-step operating model to a description of outcomes a bank should achieve, leaving the methods up to the institution.

The enforcement posture matters more than the language suggests because it changes the stakes of that shift. SR 11-7 was formally supervisory guidance, not a rule, but examiners treated it as a baseline and cited deficiencies against it for a decade and a half. SR 26-2 states outright that it does not set enforceable standards or prescriptive requirements, and that failing to follow it will not by itself draw supervisory criticism. Read quickly, that sounds like a loosening of the leash. Read carefully, it does something closer to the opposite: it hands the definition of "adequate" model risk management back to each institution, with examiners now judging banks against a standard the banks themselves have to write.

The scope exclusion in SR 26-2 that leaves coding agents ungoverned

SR 26-2 draws its scope narrowly in one specific direction: it excludes generative AI and agentic AI entirely, on the grounds that these technologies are too novel and too fast-moving to govern through fixed guidance. That means the first major rewrite of US bank model risk policy in over a decade declines to govern the exact class of AI tools that banks are adopting fastest right now.

Footnote 3 of SR 26-2 spells this out: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document." Banks that spent years building model inventories and validation pipelines under SR 11-7 now find that infrastructure doesn't extend to the AI copilots, coding agents, and generative tools already spreading through their engineering organizations. As the authors of the TrustX Agent Risk Classification Framework put it, SR 11-7 and SR 26-2 "have explicitly noted that their guidance does not cover generative and agentic AI." The agencies have said they intend to issue a request for information addressing model risk management and bank use of AI, including generative and agentic systems, which confirms the regulators know the gap exists. It also confirms that nothing closes it yet.

Some will read the exclusion as the right call. Applying 2011-era validation discipline, built for models with fixed specifications and reproducible outputs, to non-deterministic agentic systems could produce paperwork that satisfies an examiner without testing anything real, especially when the tooling to validate agents at scale barely exists. That argument has some force, but the footnote itself undercuts it: the agencies did not say governance is unnecessary for agentic AI, they said a bank's own risk management practices "should guide" that governance. A rule that excludes a technology from scope while telling institutions to govern it anyway is a requirement with the method left blank, and banks that wait for the agencies to fill it in are choosing to operate coding agents in production with no defined standard.

SR 11-7's Three Pillars

SR 11-7 stood on three pillars: robust model development, implementation, and use; effective validation; and sound governance backed by policies and controls. Validation itself broke into three parts: evaluating conceptual soundness, running ongoing monitoring, and performing outcomes analysis through methods like back-testing and benchmarking against alternative models. A model wasn't considered validated because it worked. It was validated because someone with the standing, competence, and independence to say no had reviewed the logic behind it, watched its outputs over time, and checked those outputs against reality.

SR 26-2 keeps that structure even as it drops the prescriptive detail that used to accompany it. Five elements of the old framework survive intact: risk-based tailoring of governance intensity by tier, lifecycle thinking that spans development through retirement, a requirement that effective challenge be versioned and reproducible rather than ad hoc, continuous monitoring for performance drift, and, notably, the position that generative and agentic systems, though formally excluded from scope, inherit these same principles by analogy. SR 26-2 itself observes that supervisors and internal audit teams are already applying model risk management expectations to AI systems by analogy, even without a rule that names them directly.

That sentence does real work for any bank trying to figure out what to do about coding agents. SR 26-2 isn't silent on the question of principle, only on the question of method. The task for a practitioner is to take the three pillars SR 11-7 built, which SR 26-2 explicitly preserves, and work out what conceptual soundness, effective challenge, and ongoing monitoring mean when the "model" in question is a coding agent with write access to production infrastructure.

How coding agents violate the assumptions SR 11-7's framework was built on

Classical model risk management rests on three assumptions that coding agents break outright: determinism, specifiability, and first-party control. Each break lands on a different pillar of the SR 11-7 framework, and together they explain why mapping that framework onto coding agents takes real work beyond a search-and-replace of the word "model.

Conceptual soundness assumes a fixed specification exists to evaluate and that running the same inputs through the model twice produces the same outputs. Generative AI violates both conditions: its outputs are non-deterministic, and a third party the bank never touched usually builds the foundation model that sits under a coding agent. There is no fixed object to validate in the way an examiner would validate a logistic regression.

Effective challenge assumes a reviewer can trace an output back to the reasoning and data that produced it. That assumption is the hardest piece of SR 11-7 to satisfy for large language models, because an output generated through opaque internal reasoning cannot be independently challenged if nobody can reconstruct how it was reached. Governance and control assume a clear answer to the question of who authorized an action. Coding agents blur that answer routinely: long-lived service accounts and agents operating under a human user's own credentials make it difficult to say afterward which agent acted, under what authority, and whether a human or a machine made the final call.

A fourth break occurs specifically in multi-agent coding pipelines, and it may be the hardest of the four to engineer around. Researchers at Santander AI Lab describe it as "constitutional non-compositionality": a condition where every individual component of a pipeline passes its local review, yet the combined behavior of the pipeline produces an outcome no single reviewer approved. A code change can clear every gate in a multi-step agentic workflow and still ship a result that violates the bank's actual intent, because no one step saw the whole picture. Supply-chain risk adds a failure mode with no precedent in the SR 11-7 world at all: large language models hallucinate package names that don't exist, and attackers have begun registering those nonexistent packages under the names the models invent, a technique known as slop-squatting that turns a language model's confabulation into a live attack vector.

Bank security teams sometimes push back on routing any of this through model risk governance: they argue it's a software engineering problem, best solved with tighter CI/CD gates, sandboxing, and human approval steps, not a validation framework borrowed from 2011. That argument addresses the wrong layer. Better gates catch bad individual outputs. They don't answer who authorized the agent to act in the first place and under what constraints, and that question of authorization is precisely what model risk governance exists to answer.

What ungoverned coding agents actually do in production financial environments

The incidents on record so far show exactly the failure profile SR 11-7's framework was built to catch: not a higher rate of ordinary bugs, but a different category of failure that slips past the controls engineering teams already have in place.

In April 2026, a Cursor agent running on Claude Opus 4.6 deleted a production database and its backups in nine seconds during what has become known as the PocketOS incident, striking a SaaS platform that supports car-rental operations including reservations, payments, and customer records. Recovery depended on an older offsite backup, so someone had to manually reconstruct everything in between. In July 2025, a coding agent operating on Replit deleted a live production database, even though it had received repeated instructions not to make changes during an active code freeze. Separately, a user running Claude Code against a Terraform-managed infrastructure watched the agent wipe a production environment, including database snapshots holding roughly two and a half years of course submissions and platform records, and recovery was possible only through direct intervention from AWS support.

None of those three required an attacker. The GTG-1002 campaign did. Disclosed by Anthropic in November 2025, the operation involved a Chinese state-sponsored group that manipulated Claude Code into running espionage operations against roughly 30 targets worldwide, with the coding agent executing most of the attack autonomously once set in motion. That campaign shows the authorization opacity described in the previous section is not a theoretical weakness. State-level actors have already found and used it. Self-inflicted damage remains the larger share of the problem: the Anaconda Agent Incident Registry had logged 529 agent incidents as of September 21, 2026, and 109 of them involved no adversary. Roughly one in five agent failures on record trace back to the agent itself rather than to anyone attacking it, which means a governance framework built only to stop attackers would still miss most of what's actually going wrong.

What ties these cases together is the kind of error involved, not just the damage. AI-generated code shows a distinct error profile of logic mistakes, dependency and configuration errors, and faulty control flows, and standard review gates are not built to catch these because they don't look like the bugs those gates were designed against. That is the case for treating this as a model risk problem rather than a routine engineering one: the failure mode is structurally different, and structurally different failures need a structurally different governance response.

Translating conceptual soundness into a working test for coding agents

Conceptual soundness for a statistical model asks whether its theoretical basis, its logic, and its assumptions fit the use it's being put to. For a coding agent, the analogous question asks whether its task specification, its tool permissions, and the boundaries of its authority fit the environment it's about to operate in. The object under review changes. The underlying question, whether this system's design matches what it's being trusted to do, does not.

The practical difficulty is that a third party usually built the foundation model, so a bank validating a coding agent usually cannot inspect its weights or training process. Conceptual soundness evaluation has to shift its focus to the layer the bank actually controls: the agent's configuration, its system prompt, and the scope of tool access it's been granted. That configuration layer is the real specification document for a coding agent, even though it looks nothing like a model card.

The TrustX Agent Risk Classification Framework (ARC) offers the closest existing instrument for this work. It scores agentic AI systems across twelve risk dimensions, and it includes a Coding Assistant extension built to assess capabilities unique to coding agents, including how the deployment is structured and which additional risk factors apply to this category of tool. Within that rubric, the dimensions that matter most for a conceptual soundness review are the scope of tool access the agent has been granted (whether it can read, write, execute, or deploy), how reversible its actions are, whether a human approval gate sits in front of consequential actions, and whether its authority is bounded tightly to the task in front of it.

ARC also includes a five-level autonomy classification, adapted from research by Feng et al., and it tiers agents by how much independent action they can take. That tier should set the rigor of the review directly: an agent with read-only access to a sandboxed repository needs a lighter pre-deployment check than one with write and execute access to production infrastructure. Higher autonomy demands a more stringent review before deployment, not a lighter one, and a bank that treats every coding agent to the same review regardless of what it's authorized to touch has not built a conceptual soundness process. It has built a checklist that happens to use the right vocabulary.