Every bank model risk team knows SR 11-7: inventory, validation, effective challenge, ongoing monitoring. It was built for a world where a model outputs a number and a human decides what to do about it.

Agents break its assumptions quietly — not by contradicting the guidance, but by making its units of account ambiguous.

1. Inventory: what is the thing?

Is an agent a model, an application, or forty models in a trench coat? Most MRM inventories cannot represent a system that composes tools, prompts and sub-models at runtime. So agents end up half-listed — the underlying LLM registered as a model, the orchestration logged as an application, and the actual decision surface recorded nowhere.

The practical fix is to inventory at the level of the action class, not the artifact. "Agent may adjust credit limits up to X" is a governable unit. "GPT-class model, vendor-hosted" is not.

2. Validation: you validated the model, not the authority

Model validation asks whether the model performs as intended. For an agent, that is necessary and badly insufficient. A perfectly-scored model wrapped in an agent that can act outside its grant is a governance failure with excellent metrics.

Validation scope has to extend to the authority model, the tool surface, and failure containment: what can this agent reach, what may it do there, and what happens when it is wrong.

3. Effective challenge needs something to challenge

Effective challenge assumes a reviewer can reconstruct the decision and question it. With agents, the decision was shaped by retrieved context, tool responses and a prompt chain that may no longer exist. If that context is gone, challenge degrades into reviewing the design document rather than the behaviour.

This is the single most common gap I see in banks: the logging captures what the agent did, and almost never enough to establish why it was permitted at the moment it ran.

4. Monitoring: the silent version change

Model performance drifts slowly, and monitoring frameworks are built for that cadence. Agent behaviour can change materially the day a provider ships a new model version — no code change on your side, no deployment, often no trigger in your revalidation policy.

Provider version pinning, plus an explicit revalidation trigger on version change, is the cheapest control available here and it is very frequently absent.

None of this waits for new rules

There is no agent-specific supervisory guidance to wait for, and there does not need to be. Examiners apply existing guidance to whatever is in production. Agents are in production.

The banks that will be comfortable in eighteen months are treating agents as first-class citizens of model risk now: authority recorded at grant, actions attested at execution, revalidation tied to version change. It is not more work than the alternative. It is the same work, done before someone asks.