Policy-as-Code Validation for AI Agents: Dividing Responsibility Under the 2026 Model Risk Guidance

What changed in model risk guidance

On April 17, 2026, the OCC, the Federal Reserve Board, and the FDIC issued revised interagency model risk management guidance (OCC Bulletin 2026-13; Federal Reserve SR 26-2). It clarifies principles, sets out a risk-based approach, and rescinds prior model risk management guidance. As of November 2026, risk leaders should treat the revised guidance, not SR 11-7 or OCC 2011-12, as the current reference.

The revised guidance keeps the concepts that matter most here. It describes effective challenge performed by individuals with appropriate expertise. It describes validation as evaluating whether models perform as expected, including their reliability and limitations. It says sound governance delineates who is responsible for key activities from development through validation and ongoing monitoring, and it points to the incentives that differ between reporting lines such as development and validation groups. It also says appropriate practice at one bank may be inappropriate at another, depending on risk profile and model purpose.

That last point matters for scope. Whether a given rule set that restricts an AI agent is treated as a model is a decision each bank should document in its inventory and scoping approach. Either way, the principles of independence, effective challenge, change control, and monitoring give a workable template for the control.

Why policy-as-code falls between validation regimes

Policy-as-code is a set of rules that allow, redact, block, rate limit, or escalate an agent's interactions and tool calls. It is not the agent's model, and it is not a conventional access control. That is why ownership tends to be unclear.

Model validation teams are practiced at assessing models and may not have a defined remit over enforcement rules. Security teams own access controls, but confirming that a rule matches intended agent behavior is a different question from confirming who can reach a system. Engineering writes and deploys the rules and understands them best, which is exactly why it cannot be the only party to test them. Prior SR 11-7 text allowed developers to perform some validation work, but required critical review by an independent party. That principle is a sensible basis for policy artifacts as well.

The practical consequence is that rules can go untested, changes can go unreviewed, and the bank may struggle to show an examiner that restrictions on an agent were correct, approved, and actually enforced. Separating three activities makes each gap visible: authoring, independent validation, and ongoing operation.

A workable division of responsibility

No source assigns policy-as-code to a single function, so the allocation below is a design proposal. It follows three-lines-of-defense reasoning: build and operate in the first line, challenge independently in the second, and assure the whole arrangement through internal audit. Internal audit commentary on the NIST AI RMF takes a similar view, calling for second-line controls that review, test, and monitor policies, and cautioning against AI governance siloed from enterprise risk management.

• Engineering: Authors rules, runs unit and scenario tests, manages version control, deploys approved changes, and operates the enforcement layer. Does not approve its own changes.
• Model risk or another independent second-line function: Performs effective challenge: tests rule correctness against the approved intent, reviews test design, approves material changes, and reviews outcomes analyses of intended versus enforced behavior.
• Information security: Assesses the enforcement layer itself: who can change policy, separation of authoring and deployment roles, source code review, red teaming, and vulnerability assessment.
• Business owner of the agent: States the intended behavior and the restrictions the policy must express, and accepts residual risk and approved exceptions.
• Internal audit: Tests whether the arrangement operates as designed, using evidence it can obtain without relying on the authoring team.

Validation activities specific to policy-as-code

Rule correctness testing checks that each rule produces the intended decision on representative and adversarial inputs, including edge cases and rule conflicts. Developer testing is a useful input. Independent testing, with cases the authors did not write, is the part that provides challenge.

Change management covers version control, a documented approval step, and restricted rights to alter deployed policy. Prior guidance expected code to be correct and alterable only by approved parties, and the same logic extends naturally to policy artifacts. The approver should not be the author.

Drift detection compares the policy that was approved with the policy actually being enforced. It also compares intended behavior with observed outcomes, which parallels the outcomes analysis and ongoing monitoring that the revised guidance emphasizes.

Exception handling needs its own treatment. Escalations to human approval, temporary overrides, and policy waivers should have named approvers, expiry dates, and records. Finally, security testing of the enforcement layer belongs in the release process. The OWASP checklist recommends technical enforcement of data classification and usage limits, evaluation of input validation and output filtering, and red teaming and source code review before production release.

Evaluating whether a runtime enforcement approach supports this division

Enforcement that sits in the execution path applies restrictions to each interaction and tool call as it happens, rather than documenting intent and reviewing behavior afterward. That position is what makes per-call evidence possible. When evaluating any approach, ask five questions. Does enforcement operate in the execution path? Can it produce policy version, decision, action taken, and timestamp for each call? Can authoring, approval, and deployment be separated by role? Can validators test rules and compare intended with enforced policy, including drift and exceptions? Can evidence be exported to model risk, security, and internal audit without engineering intermediation?

The separation between policy validation and policy enforcement is also a familiar pattern in NIST OSCAL material, which treats policy validators and system operators as distinct roles. Keeping the enforcement layer separable from the authors of the rules lets validators examine both the policy and the evidence on their own terms.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, applying allow, redact, block, rate limit, or escalate decisions to individual interactions and tool calls, and it produces audit-ready evidence from that enforcement. Its scope is the individual interaction and tool call, not business transaction or workflow-level governance. Whatever platform a bank selects, the criteria above should drive the choice.