Agent Memory as a Model Input: Model Risk Management Under the Revised Guidance

What changed in the guidance, and why memory is part of the discussion

Model risk teams have worked for years from SR 11-7 and OCC Bulletin 2011-12. The OCC issued revised model risk management guidance as Bulletin 2026-13 on April 17, 2026, and the Federal Reserve issued corresponding guidance as SR 26-2. The revised text covers model development and use, validation and monitoring, governance and controls, and vendor and third-party products. The OCC highlights describe generative AI and agentic AI models as novel and rapidly evolving. Operative dates should be confirmed against the full text as of November 2026.

The concepts that matter for memory carry forward. SR 26-2 lists the quality of inputs among the fundamental factors in a model's inherent risk. Validation assesses reliability and limitations based on assumptions, methods, data and relevant theories. Ongoing monitoring evaluates whether a model performs as expected given changes in products, exposures, activities, clients and data. The earlier SR 11-7 attachment said all model components, including input, processing and reporting, should be subject to validation, and an interagency statement named effective challenge by objective, informed parties as a central principle.

Two scoping points need a documented decision. The revised definition of a model centers on processing input data into quantitative estimates and excludes deterministic rule-based processes. Whether a given agent is a model, and whether its memory is an input component, is a per-use-case determination. The guidance does not prescribe memory-specific requirements, so treating memory as an input is an interpretation that a bank should record and defend.

Memory types and where each enters the model's context

Agents commonly rely on short-term context windows and on long-term memory stores such as summaries. Persistent memory carries across sessions. Whatever is written into it is read back into the agent's context on later turns, which is the technical basis for calling it an input. A write in one session can influence behavior in another, including after a context reset, because the memory survives even when the session does not.

It helps to separate the types by how they enter context. Conversation history and session state are replayed into the prompt. Stored preferences and summaries are written by the agent or application and retrieved later. Retrieved context from external stores is pulled in per task. Tool outputs may be kept and fed back into later reasoning. Each path has a different owner, a different write mechanism and a different level of trust.

The security literature is consistent on one point: memory and conversation history should be treated as untrusted data until validated. Anything written to memory becomes a privileged input on the next turn, and planted text can override instructions, exfiltrate data or hijack tool calls. A NIST-hosted presentation also cites a case where attacker-influenced behavior appeared weeks after the initial poisoning, and notes that adaptation is shifting from fine-tuning into memory, which moves fine-tuning-style risk from controlled training pipelines into runtime.

Validation and ongoing monitoring questions memory raises

Validation should treat memory like any other input component: define it, test its quality and document its limits. The questions below translate established concepts into memory terms. They are prompts for validators, not a regulatory checklist.

• Input definition and ownership: Which stores feed each agent, who owns them, and are they recorded in the model inventory?
• Data quality and provenance: Can the bank tell who or what wrote an entry, and distinguish user-supplied history from system-verified history?
• Contamination and integrity: Are entries hashed or signed at write time and verified before retrieval?
• Staleness: Do entries expire or get re-verified, and what happens when an outdated entry drives an action?
• Sensitive data retention: Is regulated or personal data redacted before persistence, and does retention follow policy?
• Influence on tool calls: Can validators show whether a retrieved entry preceded a tool call, and whether that call was authorized?

Memory events to control and evidence

Monitoring cannot rely on inspecting memory contents occasionally, because contents change at runtime. The more defensible approach is to control and record the events that change or use them: writes, retrievals, redactions, blocked entries, escalations to human approval, and tool calls that follow a retrieval. Retrieval should also be scoped so an agent does not pull historical context beyond what the current task needs.

Evidence has to support effective challenge. Signals alone do not establish whether an action was authorized, what context influenced it, which resource was accessed or whether the records are complete. A practical record for each memory event would include the agent and session identifier, the memory store, the operation type, the policy decision (allow, redact, block or escalate), the integrity check result, a provenance label, the tool call that followed and a timestamp. These fields are a starting design for validation and monitoring teams to refine.

Detector accuracy deserves its own testing. Rules that screen memory operations will produce false positives and false negatives, and validators should measure both before relying on them as a control.

Evaluating a runtime enforcement layer

Memory controls that depend on review after the fact leave a gap: a poisoned or sensitive entry has already influenced an output or action by the time it is found. A runtime enforcement layer addresses this by deciding in the execution path. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. The available decisions are allow, redact, block, rate limit and escalate for human approval. Enforcement generates continuous, audit-ready evidence mapped to frameworks including NIST, and it can be deployed self-managed in the customer cloud with configurable retention and data residency.

To evaluate any such layer for memory, ask three things. Does it see memory operations, meaning writes and retrievals that pass through an interaction or tool call? Can it apply policy before content reaches the model or a tool? Does it record each decision in a form validators can query? Scope matters too. Trussed's evidence covers enforcement decisions on interactions and tool calls. It does not provide model or dataset lineage or end-to-end tracing of agentic workflows, so banks should plan how identifiers will link memory events to the broader process.

Trussed has run continuously in production in a regulated enterprise for more than 18 months, and its deepest experience is in insurance. That is relevant to examiner scrutiny of evidence quality, but it is not a claim about bank deployments, and each bank still needs its own scope determination and validation.

• Inventory memory stores and context paths per agent
• Document the model and input determination per use case
• Define which memory events are enforced and recorded
• Test detector error rates before relying on them
• Confirm validators can query evidence independently