An AI agent's entry in the SS1/23 model inventory should let a reviewer see, in one place, what the agent does, what it can change, what it runs on, who owns it, how it was validated and when that expires. Agents change faster than traditional models, so the entry must update from the agent's configuration, not an annual survey.
What does SS1/23 require of the inventory?
PRA SS1/23 sets model risk management principles for UK banks. Its first principle, on model identification and classification, expects firms to keep a comprehensive inventory of models in use, under development and decommissioned, and to assign each a risk tier. In substance, the inventory should record enough to manage model risk across the firm: each model's purpose and use, its owner and users, its tier, its validation status and findings, its known limitations and any conditions on use, and its dependencies on other models and data.
The inventory is the base for everything else. Governance reports from it, validation plans from it, and supervisors start their reviews with it. For how inventory fits the other principles, see PRA SS1/23 model risk management for agents.
Who does it apply to?
Primarily UK banks and building societies with permission to use internal models for regulatory capital, though other firms often adopt the same practice. For the scope question itself, see whether SS1/23 covers AI agents.
Why do agents strain a traditional inventory?
A traditional model inventory has one row per model, updated when the model is redeveloped. Agents break three of its assumptions.
One agent, many capabilities. An agent that reads statements, drafts letters and updates contact details carries three different risks. A single row with a single tier hides that. The entry needs a capability list, each with its own authority level.
Many parts, each changing on its own schedule. The language model changes when the provider updates it. The brief changes when the business refines it. Sources change when someone edits a policy page. Tools are added. Each change can alter behaviour, and the inventory should show which version of each part was validated.
Agents appear outside the model function. Business teams can build agents with modest technical effort. An inventory filled by asking model developers will miss them. Our glossary entry on what an AI inventory is covers discovery more broadly.
What should each agent's entry contain?
Take an illustrative entry for a collections agent at a UK lender. It lists the agent's purpose (contacting customers in early arrears and drafting payment arrangements), its business owner and technical operator, and three capabilities: read account and arrears history; draft arrangement proposals for a person to send; send standard reminder messages within set templates. The model provider and version are recorded, along with the brief version and the list of sources. The tier is high, because the agent deals with customers who may be in financial difficulty. Validation status shows passed for reading and reminders, conditional for arrangement drafting, with an expiry date. Dependencies list the affordability model whose outputs the agent reads.
The fields, in summary:
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Identification | Unique ID, name, purpose and intended use per agent | Inventory record |
| Ownership | Business owner, operator and accountable senior manager named | Owner fields; responsibilities map |
| Capabilities | Each action listed with the system it touches and its authority level | Capability list in the entry |
| Components | Language model provider and version; brief version; sources; tools | Component fields, versioned |
| Tier | Tier per agent with the highest-risk capability driving it | Tier and rationale |
| Validation status | Date, result, findings, conditions and expiry per capability | Validation fields linked to reports |
| Limitations and conditions | Known weaknesses and restrictions on use | Limitations field |
| Dependencies | Other models, agents and data feeds it relies on or feeds | Dependency links |
| Status | In development, live, restricted or decommissioned | Status history |
A ready-to-use version is in our model risk inventory entry template for an AI agent.
How do you keep the entry current?
Link it to the agent's configuration. When the brief, a source, a tool or the model version changes, the entry should change with it and flag whether re-validation is needed. When validation expires, status should change to restricted until it is renewed. When monitoring triggers a reduction in authority, the capability's level in the entry should fall the same day.
Reconcile periodically as well. Compare the inventory with the list of agents actually running and the credentials issued to them. Any agent with credentials but no entry is a finding.
What will a PRA supervisor or internal audit ask?
- How many agents do you have, and are they all in the inventory?
- For this agent, which model version, brief and sources were validated?
- When does its validation expire, and what happens then?
- How did you find agents built outside the model function?
- What changed in this entry last month, and why?
What does the inventory not do?
It records; it does not control. An entry saying an agent may only draft does not stop it sending unless the limit is enforced in its systems. The inventory also does not replace validation, monitoring or governance; it organises them. For what validation should put into the entry, see PRA SS1/23 model validation for agents. For other binding rules, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, each agent's brief, capabilities, depth, sources and certificate status are held by the platform that enforces them, so an inventory entry can be generated from what is actually running. Certificates lapse after 90 days and a failed Attest run drops the agent to depth 1 the same day, so the entry's status reflects reality without a manual update.
Questions people ask
Should each agent capability have its own inventory entry?
Usually one entry per agent with capabilities listed inside it works best, provided each capability carries its own authority level and validation status. Separate entries make sense when capabilities run as separate agents.
Do decommissioned agents stay in the inventory?
Yes. SS1/23 expects decommissioned models to be recorded, and for agents the records of past actions may be needed to answer complaints or supervisory questions long after retirement.
Who should own the inventory entry for an agent?
The business owner is accountable for its accuracy, with the model risk function owning the inventory as a whole. Automated updates from configuration reduce the burden on both.