Model Risk Evidence for LangGraph Agents Under the 2026 Interagency Guidance

What changed: the current guidance is not SR 11-7

Many internal standards still cite SR 11-7 and OCC 2011-12. The OCC, Federal Reserve Board and FDIC have since issued updated interagency model risk management guidance. OCC Bulletin 2026-13 is dated April 17, 2026, and the Federal Reserve issued the revised guidance as SR 26-2. It clarifies principles, sets out a risk-based approach, and rescinds prior model risk management guidance and other issuances. The Federal Reserve describes the update as based on supervisory experience and industry feedback since SR 11-7.

The guidance covers model development and use, validation and monitoring, governance and controls, and vendor and third-party products. It states that practices suitable for one banking organization may not suit another, and it is expected to be most useful for models supporting significant business lines, operations, services and functions. The OCC bulletin also describes generative and agentic AI models as novel and rapidly evolving. Evidence expectations for an agent should therefore be scaled to its materiality and purpose, and a bank should confirm with counsel how its own policies handle the move away from SR 11-7.

The guidance defines model risk as the potential for adverse financial consequences from decisions made based on model output. For an agent, output includes actions. A tool call that moves data or changes a record is part of the risk, so the evidence has to cover actions as well as text.

Why this evidence cannot be rebuilt from application logs later

Application logs show that a tool was called and what came back. They usually do not show which policy version was evaluated, what the decision was, what was redacted before the model saw it, or why an action was stopped. A blocked attempt may leave no trace at all. If the policy decision was never captured when it was made, it cannot be inferred afterward.

OWASP frames the evidence questions this way: why an action occurred, which identity and permissions authorized it, what information influenced it, and whether the evidence can be trusted. It also separates assertions generated by a component from independently verifiable evidence, and describes its own evidence work as still in development. NIST's design tenets for agent identity add that individual tool invocations should undergo continuous runtime verification, that risk thresholds should trigger human review, and that evidence should be unbroken, tamper-evident and append-only. Neither is binding regulation, but together they give a risk function a reasonable standard for what durable evidence looks like.

How runtime evidence supports model risk expectations, and where it stops

The revised guidance defines effective challenge as critical analysis by objective experts who evaluate model risk and effect appropriate changes across the lifecycle. It describes validation as evaluating whether a model performs as expected, including reliability and limitations, and ongoing monitoring as evaluating performance as products, exposures, activities and clients change. Runtime records give these activities concrete material: how often an agent was blocked, which actions needed approval, where redaction was applied, and whether behavior drifted from what validators reviewed. Reviewers can challenge observed behavior rather than design intent.

The boundaries are equally important. Runtime enforcement evidence covers individual interactions and tool calls. It does not validate the model or the agent design. It does not establish model lineage, dataset provenance or the history of a model version. It does not trace a multi-step workflow end to end or tie decisions together across tasks and agents. Those need separate validation work, lineage records and workflow-level tracing. Third-party frameworks and models also bring vendor documentation, including documentation of adjustments to customized models, into scope for validation.

A sound approach treats runtime evidence as one input to the validation file. Validation defines intended behavior and limits, enforcement applies them at execution, and the resulting records feed monitoring and challenge.