Agent inventory schema
The model-risk inventory record, rewritten for a system that acts rather than one that scores.
Why it exists
SR 11-7 was written in 2011 for models that score and predict, and the inventory field set follows from that: a model has inputs, a methodology, an owner and a validation date. An agent has none of those cleanly. It chains tools, prompts and sub-models at runtime, its behaviour changes the day a provider ships a new version with no code change on your side, and the thing that creates exposure is not the score but the action taken on it. Most MRM inventories cannot represent that, so agents get recorded as one row called 'the assistant' and the inventory stops being a control. These are the fields that make the row governable, and what each one is actually for.
What it contains
Nineteen fields, each with the failure it exists to prevent
Why the equivalent classic MRM field breaks when the system acts rather than predicts
The evidence that makes each field true rather than merely populated
Risk tiering driven by action class and reversibility, not by model size or spend
The revalidation trigger matrix — including the provider-side changes that fire no internal event
No email required, and nothing is recorded when you download. Use it, adapt it, argue with it — attribution is welcome, not a condition.
Inventory fields
| Field | What it records | Why the classic MRM field fails here | Evidence that makes it true |
|---|---|---|---|
| Agent identifier | Stable ID, distinct from the application and the model. | Model IDs get reused across agents; application IDs cover many agents. | The same ID appears on the action records. |
| Accountable human | A named person, not a team or a product. | MRM names a model owner; nobody owns the agent's authority. | A signed acceptance naming the individual and the date. |
| Purpose | What it is permitted to do, in business terms. | Model purpose describes prediction; agents act across purposes. | Purpose statement that the enforcement layer can actually test against. |
| Action classes | Every class it can reach, per the action-class taxonomy. | No equivalent field exists in classic MRM. This is the field the exposure follows. | Capability list reconciled against the tools it can call. |
| Authority grant reference | The grant that authorised each action class, and who issued it. | MRM has no concept of delegated authority. | A machine-readable grant, scoped and time-boxed. |
| Scope limits | Resource, value, rate, data-classification and jurisdiction bounds. | Model limits are about input ranges, not about how much the system may spend. | Limits enforced at the decision point, evidenced by a blocked action. |
| Expiry and review | When authority lapses and what re-approval requires. | Models are revalidated annually; grants routinely never expire. | Validity window with a recorded re-approval event. |
| Tools and integrations | Every tool, API and system of record it can invoke. | MRM records data inputs, not action surfaces. | Reconciled against runtime, not against the design document. |
| Models and versions | Every model, with an immutable version — never a moving alias. | 'GPT-class model' is not a version. A provider alias changes underneath you. | Pinned identifiers appearing on individual action records. |
| Prompt and configuration version | The prompt, system message, tool schema and settings in force. | No MRM analogue. In agents this is where most behaviour lives. | Version identifier resolvable to the exact text at a past date. |
| Data domains | Classifications it can reach, including anything reachable transitively. | Model input schemas are fixed; agent retrieval is open-ended. | Access evidence at the volume the agent actually generates. |
| Jurisdictions | Where the data subjects are and where inference physically runs. | Rarely recorded at all, and provider routing crosses borders invisibly. | A traced request path, not a contractual assurance. |
| Enforcement point | Where policy can refuse the action, between intent and system of record. | Classic controls run at authentication and never again. | An allow and a deny test, both captured. |
| Evidence store and retention | Where action evidence lands and how long it survives. | Application log retention is assumed sufficient and almost never is. | Retention schedule mapped per evidence class to the binding regime. |
| Validation status | What was validated, when, by whom, and its limitations. | Validating the model is not validating the agent's authority. | An independent report covering authority, tools and containment. |
| Change triggers | What forces revalidation. | Provider updates fire no internal event, so nothing triggers. | A trigger matrix with evidence it has fired at least once. |
| Monitoring thresholds | Metrics tied to action risk, not to generic output quality. | Model drift is slow; agent behaviour changes overnight. | Threshold definitions with recorded alert dispositions. |
| Containment path | How this agent is stopped mid-incident. | The MRM answer is decommissioning, which takes a release. | A tested kill-path exercise with a recorded time-to-stop. |
| Last reconstruction test | Date an independent party rebuilt why one action was permitted. | No MRM analogue, and it is the field that predicts examination outcome. | A completed sample with reviewer sign-off. |
Risk tiering
Tier on what the agent can do and how reversible it is — not on model size, spend, or how advanced it sounds. Reversibility is the axis most schemes omit and the one that matters during an incident.
| Tier | Trigger | What the tier should compel |
|---|---|---|
| Tier 1 | Reaches Transact, Configure or Deny/terminate without a human in the path. | Independent validation, enforced limits, tested containment, quarterly reconstruction sampling. |
| Tier 2 | Reaches Commit, Mutate record or Communicate externally. | Validation of authority and evidence, monitored thresholds, annual reconstruction test. |
| Tier 3 | Assert or Recommend only, with evidenced human review. | Scoped entitlements, oversight evidence, change-trigger monitoring. |
| Tier 4 | Retrieve only, inside one classification, no external output. | Entitlement scoping and access evidence. Re-tier the moment a tool is added. |
Revalidation triggers
The first three fire outside your change control. If nothing in your process detects them, the inventory is stale by default rather than by exception.
| Trigger | Why it matters |
|---|---|
| Provider ships a new model version or retires one | Behaviour changes with no code change and often no notice you have subscribed to. |
| A moving alias resolves to something new | You did not change the version; the version changed under the alias. |
| A tool or downstream API changes its contract | The agent's reachable action set changes without any deployment on your side. |
| A prompt, system message or tool schema is edited | In agents this is a behavioural change of the same order as a retrain. |
| A new tool or integration is added | Can move the agent two action classes and a whole risk tier. |
| Scope, limit or entitlement is widened | The grant no longer matches what was validated. |
| Volume crosses a band | Controls calibrated for hundreds of actions rarely hold at hundreds of thousands. |
| A regime the agent touches is amended | The evidence you owe changes even though the system did not. |
How to use it
- Populate one agent end to end before rolling the schema out. The first row surfaces most of the structural problems.
- Fill the evidence column with links, not descriptions. A field describing evidence you cannot produce is a gap recorded as a control.
- Reconcile tools and models against runtime rather than against the design document — the two diverge quickly.
- Tier on action class and reversibility, then let the tier set the validation and monitoring obligations.
- Wire the trigger matrix to something that actually fires. A trigger nobody receives is not a control.
Built from public standards and general practice. Regulatory instruments move — check anything cited here against its primary source on the day you rely on it. Related: the other artifacts · the diagnostic.
Want this applied to your architecture?
The artifacts are general by design. Applying one to a specific estate is what the governance review does.