Blog

By Steve Carroll, Principal, BNP, Inc. · November 4, 2026

Introduction

On November 4, 2026, the Office of the Comptroller of the Currency (OCC) issued a supervisory framework that tells its examiners how to evaluate a bank’s use of “Super Intelligence” (SI), the OCC’s new term for what most of us have been calling artificial intelligence (OCC News Release 2026-97). The framework does not create a new risk category. Instead, it tells examiners to look for SI inside the programs banks already run, which puts business continuity, third-party risk management, and information security squarely in scope.

This article summarizes what the OCC issued, how the framework is organized, and what it says about each of those three disciplines. Where a point comes from the OCC documents, it is cited by section. Where it comes from BNP, Inc.’s own experience supporting banks and credit unions, it is labeled Practice-based.

What the OCC issued, and what it is not

The release was accompanied by OCC Bulletin 2026-54, “Super Intelligence: Supervisory Framework”, and the framework itself, a 22-page PDF titled “OCC Supervisory Framework on Bank Use of Super Intelligence”.

Three points about its status matter most:

• It is an examiner resource. The bulletin states that the framework “does not establish supervisory expectations for banks” and that banks “are not expected to use this document to assess their use of SI.”
• SI is not a separate risk category. Examiners “should not treat SI as a separate and distinct risk category,” and banks “are not required to define a separate SI risk appetite.” The framework explains that SI “can introduce, amplify or modify risk in existing risk categories, such as operational, compliance and credit.”
• It is proportionate. Examiners “should tailor their examination of banks’ use of SI based on the materiality of the SI use case,” and the bulletin’s note for community banks calls for tailoring to “the bank’s size, complexity, and risk profile.”

On terminology, the bulletin defines Super Intelligence by reference to the technologies previously called “Artificial Intelligence” under 15 U.S.C. 9401(3), citing Executive Order 14434. The framework also notes that the model risk principles in OCC Bulletin 2026-13 cover non-generative, non-agentic models, so the new framework is “more applicable to generative and agentic SI.”

How the framework is organized

The framework’s overarching principle is that “a bank’s control intensity could increase with the potential consequences of an SI agent’s failure or misuse” (section 1.1). It groups sixteen components into six pillars (section 1.2):

Section 3 offers an illustrative way to scale controls. Each use case may be scored on seven factors: decision consequence, reversibility, customer/financial impact, autonomy level, data sensitivity, explainability, and provenance. “Direct action carries materially higher risk than decision support.” The factors combine into four illustrative tiers (section 3.2):

The OCC adds that a fully autonomous, customer-facing payment agent sits at Tier 1 “regardless of how well it performs in testing.”

Business continuity: when the system is up but wrong

The most important idea for business continuity professionals is in section 2.10, Operational Resilience: resilience for SI “includes both loss of service and incorrect operation.” An agentic system “could remain available while taking inappropriate or harmful actions, requiring the bank to detect, contain, recover, remediate harm, and continue the underlying business process.” The framework’s summary table names the risk as “a system that remains available while acting incorrectly, with no tested containment, continuity, recovery, or remediation path.”

Section 2.10 lists the arrangements a bank may document and test for consequential or autonomous uses:

• Misfire detection and containment: monitoring, observability tools, control agents, deterministic rules, circuit breakers, rate limits, least-privilege permissions, and kill switches.
• Business continuity and fail-over: testing “whether the business process can continue through trained personnel, a narrower fallback agent, or another approved process.”
• Recovery and post-incident review: rollback, data correction, restoration of decision support, root-cause analysis, model-risk review, and controlled return to service, which “could be incorporated into recovery exercises.”
• Customer remediation: a separate workstream to identify the complete affected population, assess individual harm, provide notice or correction, and independently verify completion.
• External SI agent interactions and systemic effects: controls over customer, fintech, or agentic-commerce systems the bank does not control, and scenario analysis of “correlated or cascading activity.”

Section 2.2 also asks banks to consider interdependencies and aggregate exposure through shared providers, and section 2.14 calls for version and change control over models, prompts, data, configuration, providers, tools, and permissions. That record is what a recovery team needs to roll an agent back to a known-good state.

Practice-based: Most BIAs and threat assessments treat technology failure as an outage. Adding “incorrect operation” as a threat scenario, and recording SI tools as resources supporting the business functions that rely on them, brings SI into the BIA without building a separate program.

Third-party risk management

Banks “frequently obtain SI capabilities from third parties,” and that reliance can introduce risks “not fully addressed by conventional service-level and information-security reviews” (section 2.9). The framework states that SI third-party risk management “may supplement existing interagency third-party risk management guidance.” It does not replace it.

Section 2.9 names four areas:

Two related points sit elsewhere in the framework. Section 2.4 notes that even when development or hosting is distributed across vendors, “accountability for managing the bank’s risk generally remains with the bank.” The summary table names the third-party risk as “opaque provider chains, weak contractual rights, switching constraints, or concentration in common models and infrastructure.”

Practice-based: The vendor most likely to add SI without a new contract is one you already have. Adding the four areas above to annual due diligence questionnaires and contract renewal checklists catches those changes.

Information security

Section 2.11 treats SI as both a target and an accelerant. Prompts, model inputs, training pipelines, connected tools, and non-human identities “create attack surfaces that may not be fully addressed by controls designed for conventional code and network perimeters.” The framework names five threats:

• Prompt injection and jailbreaking: inputs that alter behavior or cause an agent to misuse tools “without a conventional network breach.”
• Data and model poisoning: compromised training or feedback data that embeds behavior “difficult to detect after deployment.”
• Model extraction and data leakage: crafted queries that recover sensitive training information or confidential data.
• Tool use and excessive agency: broad permissions that let a manipulated agent “cause fraud, data exposure, or operational disruption at machine speed.”
• Non-human identities: agent identities, credentials, and logs governed “in a manner comparable to privileged users.”

On incidents, section 2.16 describes internal escalation and notification thresholds based on severity, duration, customer impact, financial exposure, legal requirements, and systemic effects, and notes that “various notifications required by laws and regulations, as well as contracts, could be applicable to SI use cases.”

Practice-based: Map the five threats to the control framework you already use, such as NIST control families. That shows where existing controls already cover SI and where the gaps are, and it matches the OCC’s direction not to treat SI as a separate category.

Who it applies to

The framework is written for examiners of national banks, federal savings associations, and federal branches and agencies of foreign banks. State-chartered banks and credit unions are supervised by other agencies, so this issuance does not apply to them directly. Practice-based: It is still a useful view of how one federal regulator is thinking, and its structure is a reasonable reference point for any institution’s own program.

What institutions can do now

Practice-based. None of the following is an OCC requirement. They are steps BNP, Inc. sees as practical ways to fold SI into existing programs.

1. Inventory SI use cases and record each as a resource supporting the business functions that rely on it.
2. Use one consequence-based scale. Apply your existing impact levels to SI use cases, using the OCC’s seven factors as a guide.
3. Add “incorrect operation” scenarios to threat assessments, incident response playbooks, and tabletop exercises.
4. Document and test the fallback for each consequential use: can trained staff run the process without the agent?
5. Update vendor due diligence and contracts for provider agents, SI incidents, liability, and change notice.
6. Map the five named threats to existing security controls and close the gaps you find.

How BNP, Inc. uses AI

BNP, Inc. is itself a third party to its clients, so we hold ourselves to the same questions. BNP uses AI only as a support tool in delivering consulting services, for example in drafting documentation and analyzing client-provided data. All AI-generated output is reviewed, validated, and approved by qualified BNP personnel, and BNP retains full responsibility for its deliverables. AI is not used to execute transactions, approve decisions, or act on a client’s behalf. BNP does not put non-public personal information or sensitive client data into publicly accessible AI tools, works only in secure, enterprise-grade environments, and configures tools to prevent model training on client-specific information. Clients can request a description of how AI is used in their engagement and the controls that apply.

Sources

1. Office of the Comptroller of the Currency, News Release 2026-97, “OCC Issues Supervisory Framework on Bank Use of Super Intelligence”, November 4, 2026.
2. Office of the Comptroller of the Currency, Bulletin 2026-54, “Super Intelligence: Supervisory Framework”, November 4, 2026.
3. Office of the Comptroller of the Currency, “OCC Supervisory Framework on Bank Use of Super Intelligence” (PDF), November 4, 2026, sections 1–3.
4. Office of the Comptroller of the Currency, Bulletin 2026-13, “Model Risk Management: Revised Guidance”, April 17, 2026.

Statements marked Practice-based reflect BNP, Inc.’s experience supporting banks and credit unions and are not drawn from the sources above.