Governing a model-risk agent

The model is in the guidance. The worker is not.

In April 2026 the Federal Reserve, OCC, and FDIC replaced SR 11-7 with SR 26-2 / OCC Bulletin 2026-13. It is principles-based guidance, not an enforceable standard, but it still describes what sound practice looks like: effective challenge — critical analysis by people with the expertise, independence, and standing to force change across the model lifecycle. Intended use, materiality, limitations, and ongoing monitoring remain the work.

It also draws a line. Generative and agentic AI are described as novel and rapidly evolving, and are not in scope. Banks are told to let their existing risk-management and governance practices determine the controls for those tools. That is a boundary, not an exemption. The quantitative model under test is still covered by SR 26-2. The agent drafting the package is not.

OSFI Guideline E-23 goes further. Effective 1 May 2027, it applies to all models at federally regulated institutions, including AI/ML, and names level of autonomy as a risk-rating factor. It says model review should be independent from model development, and it calls for alternative controls, “especially for ‘black box approaches’ or autonomous models.” Read plainly, an agent that drafts validation work is itself a candidate for the model inventory — and its autonomy pushes its rating up, not down.

Effective challenge has to be a control, not a prompt

SR 26-2 is explicit that the quality of validation “depends on the rigor and effectiveness of the review rather than on organizational structure.” Independence on an org chart is not enough; it has to hold in how the work actually runs. Telling an LLM not to approve its own work is a behavioral instruction. Effective challenge needs a different principal — someone with expertise, independence, and standing — and in software that means the component never receives the authority in the first place.

• A model-owner agent may assemble documentation and propose a package. It cannot approve the package, alter validation results, or write the production flag.
• A validation agent may request approved tests and draft findings after an engagement is opened by a validation manager. It cannot modify the tested artifact, mint a passing metric, or grant production use.
• A human principal retains suitability, finding severity, exceptions, and approval. A click-through on a generated summary is not that decision.

OpenBITS is the independent control boundary between those roles. The agent may interpret the request, retrieve scoped context, draft, and request tools. Workload identity, bank rules, exact approval binding, the Validation Runner — pinned dependencies, bounded resources, no standing production credential — and the signed receipt sit outside the model. A prompt injection in a model document cannot grant new access, and a plausible paragraph cannot populate a protected result field. Content does not become permission. Narrative does not become a number.

A concrete case: the validation agent drafts a finding that the model’s AUC clears the approval threshold. The protected metric field does not accept text. It accepts a value only from a signed runner receipt that binds the model, data snapshot, test specification, environment, code, and output. No matching receipt exists, so the claim is marked unsupported and the package cannot advance to approval. The draft is still useful. It is just not evidence.

A newly proposed test works the same way: it is a new request, not a shortcut. It has to be approved and bound — to the exact artifact, data, test specification, libraries, environment, thresholds, destination, and reviewer — before the runner executes it. Content digests identify those files; filenames do not. The path is always: request → approval → bound artifacts → controlled execution → signed receipt → verifiable evidence.

None of this changes when the worker comes from outside. SR 26-2 expects banks that use external resources to maintain proper oversight and integrate that work into their own model risk management. A consulting firm, a vendor, or the bank can bring the agent. The boundary, the policy, the inventory, and the decision rights stay with the institution.

Controls scale with materiality

Both SR 26-2 and E-23 are risk-based: scrutiny follows materiality. The boundary around the agent should work the same way. A documentation agent with read-only access to one model’s files needs governed identity, scoped retrieval, and a record. A material finding, an exception, or a change to production use needs action-bound human approval and a signed execution receipt. Where the host or operator is itself part of the threat model, execution can move into an attested environment. The goal is not maximum control everywhere. It is control that matches the consequence.

A complete log is not effective challenge

Least privilege, named owners, short-lived credentials, an activity log, and an emergency stop are necessary. They answer a security question. Model risk asks something else: was the challenge independent, and can a reviewer reconstruct what actually ran?

An agent can have legitimate access to the model artifact, the development memo, and the approved test family, record every query, and still write a fluent, wrong opinion. The log proves the work was authorized. It does not prove a metric ran, a required test was not skipped, or that the model is suitable. Another LLM reading the first LLM’s memo is not independent validation. It is a second narrative.

What the control layer can verify, without depending on the model’s own explanation, is whether each protected result traces to an execution that actually ran, under an authorization that actually existed — and which exceptions remain open. Chain of thought is not that record. The agent’s memory is not that record. The Evidence Pack is.

Assurance that can be tested

Guidance describes the outcome. Acceptance tests show whether the boundary holds. Put a known miss in the path and require the system to catch it — the discipline validation already applies to models, applied to the agent.

• Integrity. Swap the registered artifact, test specification, or pinned library, and the digest mismatch is caught before execution. Draft a metric with no matching receipt, and it stays unsupported. Omit or fail a test in the expected set, and reconciliation against execution history keeps the gap visible.
• Authority. An owner editing a validation finding, or a validator flipping production use, is blocked and recorded. Retrieval outside the opened engagement is denied, and the attempt stays in the pack.
• Resilience. Interrupt the runner or lose authorization mid-job, and reads, approvals, execution, and publication fail closed. An uncertain output stays non-authoritative until reconciled.

Each attack is paired with the authorized version of the same task, which must still succeed. A system that only blocks does not pass. Effective challenge still needs people who can see a subtle miss; seeded defects do not replace the reviewer. They make a miss expensive to hide.

What the engagement should emit

The value is the record, not the draft memo:

// Bound to one validation engagement — not a fitness decision
{
  "workflow": "MODEL_VALIDATION",
  "proposed_by": "agent:mrm-validator",
  "owner_agent": "agent:model-owner",
  "request": "run_registered_suite",
  "authorized_context": [
    { "type": "model_artifact", "commitment": "0x9f2c…" },
    { "type": "data_snapshot", "commitment": "0x41ab…" },
    { "type": "test_specification", "commitment": "0x77d1…" },
    { "type": "pinned_libraries", "commitment": "0x12aa…" }
  ],
  "policy_version": "mrm_engagement_v3",
  "runner_receipt": "0x5c88…",
  "protected_metrics": "receipt-backed",
  "expected_tests_reconciled": "complete",
  "exceptions": [],
  "human_approvals": [
    { "role": "ValidationManager", "sig": "0x…" }
  ],
  "output_commitment": "0xab12…"
}

Suitability, finding severity, and production use stay with the named reviewer. The first workflow is the one model risk already knows: one medium- or high-materiality model, ownership separated from validation, tests bound to the approved artifact, and an auditor who can reconstruct the package without the agent’s private memory.

OpenBITS does not require the institution to standardize on one agent or model provider, and it is not a claim that use of the platform is compliance with SR 26-2, OCC Bulletin 2026-13, or E-23. Agent intelligence will change. The institutional control boundary should not have to.