OCC super intelligence framework: What it means for AI governance
On November 4, 2026, the OCC published Bulletin 2026-54, releasing its first supervisory framework evaluating how examiners should assess GenAI and autonomous agentic systems already running in production.
In April, the OCC jointly released SR 26-2, which left generative and agentic AI out of its scope. Now, with Bulletin 2026-54, examiners have a framework to evaluate these systems, and banks can treat it as an exam preview for GenAI and agentic AI.
In this blog, we’ll break down the framework, how it shapes an examiner’s role, and how to treat the super intelligence (SI) already in your inventory.
What is the OCC super intelligence framework?
While the OCC adopts the administration's SI terminology, the bulletin's scope targets technologies and systems encompassed by the term artificial intelligence, including GenAI, multi-agent frameworks, and autonomous decisioning workflows.
The framework covers OCC-supervised institutions, like national banks, federal savings associations, and federal branches and agencies of foreign banks. No asset threshold applies, so it covers OCC-chartered regional and community banks, with examinations tailored to each bank’s size, complexity, and risk profile.
The framework was written for OCC examiners, who can use it to decide where to look and how closely. For banks, this is a direct view of exam questions their GenAI and agent programs may face. The OCC plans to update the framework as the technology changes. Banks that review it closely now and anticipate the questions examiners may ask will have less to adjust when the framework changes later.
How the OCC evaluates AI risk and autonomy
Under Bulletin 2026-54, control intensity must match the potential consequences of an agent's actions rather than its technical complexity. In the OCC's view, an agent's delegated authority and the quality of human oversight matter far more than model size or architectural sophistication. A simple rules-based script authorized to transfer funds carries significantly more risk to a bank than a sophisticated foundation model that only drafts internal documents.
Examiners evaluate each use case against seven operational criteria: decision consequence, autonomy level, reversibility, customer and financial impact, data sensitivity, explainability, and provenance (whether built in-house, fine-tuned, or procured from a vendor). These factors determine placement across four risk tiers:
Tier | Level | Characteristics | Examples |
|---|---|---|---|
1 | Critical | Direct action, low or no reversibility, high impact, autonomous or partially autonomous | Autonomous payment agent, real-time credit decisioning, fraud-hold release, market access |
2 | High | Direct action or high-weight decision support, human-on-the-loop, moderate to high impact | SI-assisted underwriting, agent-initiated customer communications, AML alert disposition |
3 | Moderate | Decision support with mandatory human-in-the-loop, limited data sensitivity, reversible | Internal document summarization for credit memos, agent-assisted research |
4 | Low | No customer or financial data exposure, no direct action, fully human-controlled use | Internal productivity tools, code assistance, general employee Q&A |
Because tiering is driven by real-world consequence, strong backtesting results or benchmark scores alone will not justify a lower classification. Moving a system to a lower-risk tier requires concrete operational limits, such as restricting API permissions, requiring an independent sign-off before execution, or ensuring an action can be halted and reversed before financial or customer harm occurs.
Human oversight faces the same scrutiny. Reviewers must have the technical background, operational context, and explicit authority to reject an automated action. When alert fatigue leads an approver to bulk-approve hundreds of agent actions a day, examiners will view that control as purely nominal.
Why SI is not a separate risk category
The OCC tells examiners not to treat SI as a separate and distinct risk category, and says banks are not required to define a separate SI risk appetite. SI introduces, amplifies, or changes risk in categories banks already manage, such as operational, compliance, and credit risk. Those risks should now include SI risk and run through the bank's existing risk management framework.
While some assume AI governance requires a standalone inventory distinct from traditional models, this guidance suggests joining the inventory. When GenAI and traditional models live in different systems, reconciliation becomes manual, and a CRO has two partial views of the same risk.
AI governance decisions banks still need to make
An examiner guide describes what examiners look at. The bank builds controls to answer those questions. Below are governance areas banks must formalize now.
Governance area | What the framework leaves open | Decision for the bank |
|---|---|---|
Tiering methodology | Lists tiering factors and illustrative tier examples, but no method for weighting or combining them. | Define a scoring method that weights consequence, reversibility, and autonomy above model sophistication, and apply it the same way across the business. |
Risk concentration | Names shared providers, data, permissions, and infrastructure as sources of correlated risk, but sets no SI risk aggregation mandate. | Establish concentration thresholds for dependencies on the same model or provider, and define when that triggers a review. |
Third-party management | Suggests banks may require notice of new vendor SI features and retest when they ship, without defining what counts as a material change. | Determine re-review trigger when a vendor ships new agentic features or expanded read or write permissions. |
Continuous oversight | Describes systems that remain available while taking harmful actions, and lists containment tools, without setting thresholds or response standards. | Set the behavioral thresholds that pause an agent, assign who can halt or override it, and test the fallback process that keeps the work running. |
Validation documentation | Suggests repeated testing and consistency thresholds may say more than a single run, and larger samples for rarer failures, without setting a number. | Standardize repeated-run testing and keep the resulting distributions with the validation record before deployment sign-off. |
Where to start with GenAI and agent governance
Start by putting GenAI and agents through the same discipline your model risk program already applies, scaled to what each system can do.
- Write down each use case's purpose and permitted actions. Section 2.1 suggests stating the data, systems, tools, and accounts an agent may use in terms someone can test. Scope drift then becomes a detectable control failure.
- Tier by consequence and autonomy, and record the reasoning. Re-tier when an agent's permissions or tools change, because that changes its risk even if the model does not.
- Put approval in front of deployment. A reviewer separate from the builder signs off before a consequential system reaches production, and the approval expires on a schedule your policy sets.
- Collect evidence while the work runs. Section 2.14 describes how records of inputs, outputs, tool calls, approvals, and overrides can help reconstruct a material decision. Those records are hard to assemble after an examiner asks.
How Domino helps
Passing an OCC examination on agentic AI requires tracking what a system can do in production, not just how it was trained. Domino operationalizes these expectations by embedding independent sign-offs and automated release gates into development workflows. The platform enforces strict role separation, ensuring whoever builds an agent cannot authorize its production release. To protect against scope drift and unvetted access expansions, these approvals automatically expire on preset schedules, preventing autonomous systems from operating without current validation.
This approach also solves the risk fragmentation the OCC warns against. Rather than forcing compliance teams to juggle separate spreadsheets for traditional statistical models and GenAI, Domino unifies both under a single governance record. Risk teams can apply an existing SR 26-2 model policy and an agentic permission policy to the same system without duplicating work. Domino provides continuous oversight by automatically capturing the full lineage of every run, logging the code, environment, tool calls, and human approvals into an immutable audit trail that meets examiners' reconstruction requirements.
Built for the next supervisory revision
The OCC designed Bulletin 2026-54 as a living framework that will evolve alongside autonomous technology. Banks that rely on manual committee reviews and disconnected documentation will face substantial friction with every supervisory update. By tiering systems by operational consequence, gating releases on independent sign-off, and capturing auditable evidence automatically, banks create a defensible governance framework that adapts to future regulatory expectations.
Watch the model risk management demo to see how Domino is built for Bulletin 2026-54 and the future frameworks and policies that come.