Audit evidence banks should keep for AI agents outside SR 26-2 scope

What SR 26-2 covers and what it leaves open

The Federal Reserve issued SR 26-2, revised guidance, on April 17, 2026. A public commenter characterizes it as placing generative and agentic AI models outside its scope and leaving their controls to each bank's own practices. A Federal Reserve supervision manual section similarly says generative and agentic AI models are novel and rapidly evolving and, as such, are not within the scope of "this guidance".

That leaves a practical gap. Agents that call tools, retrieve data or take actions may not come with a model validation artifact set, yet a bank still has to show an examiner what each agent was permitted to do and what it did. Whether a particular agent sits inside or outside the guidance depends on the scope wording, so this guide does not presume either outcome. The evidence set below is useful in both cases, and it stays at the level of individual interactions and tool calls.

Existing expectations that still apply

Absence from one guidance letter does not remove existing supervisory expectations. Federal Reserve model risk management guidance says each banking organization is responsible for adopting practices appropriate to its own risks, that effective policies define risk management expectations, and that documentation supports tracking recommendations, responses and exceptions. For agents, that points to written policies and retained records of exceptions and escalations.

Internal audit's role under that guidance is generally to evaluate whether risk management practices are rigorous and effective and whether related policies are implemented accordingly. It generally does not duplicate development or validation. Internal audit can therefore test an agent program only if the bank has its own policy definitions and its own records of enforcement to test against.

For vendor-supplied agents, the interagency third-party guidance adds another lens. It asks whether a third party's controls are subject to effective audit assessments, notes that contracts often establish the bank's right to audit and provide for remediation, and points to the types and frequency of audit reports the bank is entitled to receive, such as SOC reports. Vendor assurances complement, but do not replace, the bank's own record of what happened.

Evidence is not raw logging

Application logs record that something happened. Evidence ties an authenticated agent identity, the tool invoked, hashed arguments, the result and a timestamp to one decision under one policy version. That linkage is what lets a reviewer reconstruct what the agent was allowed to do, not only what it did.

Where the record is created matters. Authorization should be enforced in the execution component, outside the agent's context, so the agent cannot alter or omit the record. Evidence is then generated at enforcement rather than rebuilt later. A boolean flag such as "user_confirmed" does not establish approval. The enforcing component should verify that the approval belongs to the current actor and the exact tool call, remains valid and has not been consumed.

The design should also fail closed. If risk classification, policy lookup, approval validation or audit logging fails, the action should not proceed, so no action occurs without evidence. For tamper evidence, one documented option is a hash chain in which each entry includes the previous entry's hash. It is an optional design, but it gives a reviewer a way to detect altered or missing entries.

Finally, do not rely on vendor-side logs alone. Retention can be short: one commenter described a vendor connector service keeping production execution logs for 21 days. Hold a durable copy in your own environment that can be correlated with your own records.

Setting retention, residency and access controls

No bank-specific rule for AI agent evidence retention, immutability, residency or access control is established, so these are decisions your policy must make and defend. A defensible starting point is to retain evidence for the longest record-keeping obligation that applies to the agent's use case. For AML and sanctions payment use, practitioner guidance cites typically five years for BSA/AML. That figure is specific to that context and should not be applied to every agent.

On residency, store evidence where your data location requirements allow, and record that setting alongside the evidence. On access, separate the people who operate agents from the people who can read or administer the evidence store, and keep read access narrow. Hashing sensitive arguments limits what the evidence store itself exposes.

Before relying on the set, test it. Pick one production interaction and reconstruct it end to end, from policy version through the decision to the approval record. Gaps found in that exercise are far cheaper to fix than gaps found during an examination or audit.