How to Retire an AI Agent from the Model Inventory and Preserve Its Evidence

What changed: SR 11-7 is no longer the current reference

Many retirement procedures still cite SR 11-7. The Federal Reserve, OCC and FDIC have issued Revised Guidance on Model Risk Management (Federal Reserve SR 26-2, OCC Bulletin 2026-13, dated April 17, 2026), which supersedes and replaces SR 11-7 and SR 21-8. SR 11-7 is now historical context only.

The revised guidance takes a risk-based approach tailored to a bank's model risk profile, size and complexity, and it says practices suited to one bank may be unsuitable for another. It describes maintaining a comprehensive set of model information as common industry practice, and says an effective inventory holds enough information to understand model risks individually and in aggregate. Adequate documentation supports effective model risk management.

On agents, the guidance calls generative and agentic AI models novel and rapidly evolving, and states that its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. Your policy should therefore state explicitly how retired agents are treated in the inventory, rather than assuming the answer. A practical position is to apply the same inventory and documentation discipline to agents as to other models, scaled to risk. The depth of the evidence package should follow the agent's risk profile and the business significance of what it supported.

Revoking access and showing no residual access remains

Revocation covers every path the agent used to act: service credentials, API keys, delegated user tokens, tool permissions, MCP server connections and data access grants. Build the list from the access configuration captured in step 4, not from memory. Agents that used long-lived static secrets are the hardest to close out. NIST's agent-identity design tenets favor ephemeral access acquired when a task starts, which lets security systems contain or revoke authority. Where you can move an agent to that model before retirement, do so.

Revocation should be evidenced independently of the agent's cooperation. For each credential and tool permission, keep a record that authority was revoked at a given time, and a record that a later request using it was refused. That refused request is the check an examiner or internal audit can read: it shows the access is closed, not merely that a ticket was marked done.

Also confirm that retrieving the evidence never depends on the retired agent. NIST's guidance says historical evidence should remain verifiable after credential rotation, expiry or retirement without the agent staying online, so a later reviewer can establish which agent acted and who accepted accountability. If retrieval needs the agent's runtime or credentials, the retirement is incomplete.

Retention periods, residency and disposal schedules

Retirement most often fails through disposal. A generic schedule treats the agent's logs and configuration as ordinary system data and deletes them on a timer. Assign the evidence package an explicit retention owner, and name who has authority to override a generic disposal schedule. Your compliance and legal functions should set the retention period, in line with the bank's record-keeping obligations and the risk tier of the agent. Record the period in the inventory entry so it travels with the record.

Data residency belongs in the same decision. Decide where the package is stored, in which jurisdiction, and who can read it. Keep the store outside the agent's own write path. NIST's design tenets note that an agent able to modify its own logs could delete or alter the record of its actions, and they call for an append-only, tamper-evident body of evidence held independently of the agent.

The inventory entry is the index to all of this. It should record purpose, use, restrictions and human oversight roles, and point to the package location, retention period and custodian. An examiner should be able to start at the inventory and reach the evidence without asking the team that built the agent.

Where runtime enforcement produces retainable evidence

The package is only as good as the records captured while the agent was running. Reconstructing them afterward from application logs is slow and incomplete. Policy enforced in the execution path produces them as a by-product: each model interaction and tool call is allowed, redacted, blocked, rate limited or escalated for human approval, and each decision is recorded at the moment it is made.

Trussed enforces policy at runtime in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence from that enforcement. The evidence covers individual interactions and tool calls, so it can show what an agent was allowed to do and what it did. It is not a record of model lineage or an end-to-end trace of an agentic workflow, and a retirement procedure should not assume it is. Trussed can be self-managed in the customer cloud with configurable retention and data residency, which supports keeping the package in a location the bank controls. Insurance is the regulated financial sector where Trussed is deepest.