SR 26-2 vs OWASP Agentic Top 10: Mapping Model Risk to Bank AI Agent Threats

Two frameworks with different jobs

SR 26-2 is published as a Federal Reserve Supervision and Regulation Letter, dated April 17, 2026. It is described as revised guidance that highlights sound principles for effective model risk management. It also recognizes that practices appropriately vary among banking organizations based on their risk profiles and model usage. For a risk leader, that second point matters: any crosswalk should show how one institution scopes agents, not imply a uniform expectation for every bank.

The OWASP Top 10 for Agentic Applications 2026 was announced on December 9, 2025. OWASP describes it as a globally peer-reviewed framework for the most critical security risks facing autonomous and agentic AI systems. It is a security framework for builders, defenders, and decision-makers. It is not regulatory guidance, so the two documents differ in authority as well as scope.

The difference in subject follows from that. Model risk management asks whether a model is sound, validated, governed, and monitored. OWASP asks what can go wrong when a model-driven system can plan, persist, and delegate across tools and systems. OWASP frames this as a shift from preventing bad outputs to preventing cascading failures across autonomous systems. Both questions apply to a bank agent, and neither answers the other.

Where validation and monitoring stop short

Model risk management practice generally centers on how a model is developed, validated before use, governed, and monitored over time. Those controls assume the model's output is the object of risk. For an agent, the output can be an action: a call to an API, a query against a data store, or a message to another agent.

Two gaps follow. First, validation is typically periodic and tests a model against expected conditions, while agent threats depend on inputs and tool responses that arrive at runtime. OWASP's own test scenarios show this. One scenario, tagged ASI01:2026, describes an agent that misreads user intent through weak context isolation and acts outside its expected task scope. Another, tagged ASI02:2026, describes an agent that treats external tool output as authoritative and executes instructions embedded in it. Neither is a model defect that validation would find in advance.

Second, ongoing monitoring that reviews outcomes after the fact can show that something happened, but it does not stop it. For actions that move data or change systems, a risk team will want to know whether a control acted before the call completed. That is the difference between reviewing a record and enforcing a rule.

Closing the gap in the execution path

OWASP says defenses must address the full attack surface: the agent's inputs, its planning and reasoning, its tool integrations, and its communication with other agents. A practical way to organize controls is by the points where those threats arise: tool calls, tool outputs, inter-agent messages, and identity or privilege use.

Enforcing policy in the execution path means a decision is made on each interaction or tool call before it proceeds. The outcomes are allow, redact, block, or escalate for human approval. Tool outputs re-enter the agent's context, so inspecting content before the agent acts on it is a candidate control for the scenario where external output is treated as authoritative. Rate limits add a further control for runaway or repeated calls.

Trussed enforces policy in this way across models, agents, tools, and MCP servers, at the level of individual interactions and tool calls. Each enforcement decision produces audit-ready evidence as a byproduct, so the record exists because the control ran, not because someone reconstructed events later. Trussed does not trace entire agentic workflows end to end, so teams that need that view should plan for it separately.

Scoping decisions and tradeoffs for risk teams

Start by documenting which agents your institution treats as in scope for model risk management and why. Because SR 26-2 ties practice to risk profile and model usage, an agent that drafts internal summaries and one that can initiate changes in a customer system warrant different depth. Write down that reasoning. It is the first thing a reviewer will look for.

Next, assign each OWASP category to an owner and a control type: model-centric, runtime, or both. Where the answer is runtime, name the enforcement point and the evidence it generates. Where the answer is model-centric only, confirm that the control reaches agent behavior and not just the underlying model.

There are tradeoffs. Blocking and escalation add friction, and human approval does not scale to every call, so reserve it for actions with material consequence. Retaining full inputs and outputs improves reviewability but raises data handling questions, so retention and residency settings should be decided with privacy and legal teams. Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency. Its evidence generation is mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Its customers are in insurance, pharma, healthcare, and education, with insurance, a regulated financial sector, where it is deepest. It has no bank customers, so banks should test fit against their own model risk framework.

Finally, confirm current category text and guidance wording before you finalize a crosswalk. Both documents have been updated since publication, and the position is stated here as of November 2026.