One instrument, for the delegated act
A firm that runs a vendor's model on a hyperscaler usually cannot inspect the model, and it will rarely be allowed to. But it can decide, at the moment an act commits, whether that act is defensible on the evidence it rests on. So the model governs the act. The agent's profile, how autonomous it is and how much it can do, goes into the classification, and the decision is taken on the act.
It is written for the second line first: the head of model risk, the CRO, and the chief data officer, with the transformation lead who has to take an agentic programme past all three. And it uses the words of the inventories they already keep. It states what must be demonstrable and names no platform, so it reads the same on a vendor platform, on a hyperscaler, or on what the firm builds. It certifies nothing.
Every element the model calls an instrument carries an accountable owner, a record and its retention, an override path, a breach consequence, and a second-line check. An element that cannot fill all of them is published as guidance. That keeps the instruments to what an examiner can test. The US model risk guidance of April 2026, SR 26-2, leaves agentic AI out of its scope and tells banks to govern it with their own risk management. The model is one way to write that risk management down.
The frameworks a firm answers to, and one model beneath them
A bank or an insurer already answers to a risk framework, a management system, and a law. NIST's AI Risk Management Framework is a risk workflow: govern, map, measure, and manage. ISO/IEC 42001 is a management system, with policy, roles, evidence, review, and improvement, audited like any other. And the EU AI Act sets duties by the use and by the firm's role as provider or deployer, with the high-risk uses listed in Annex III, among them credit scoring of individuals and life and health pricing.
Each keeps its own requirements. The reference model sits beneath all three, so that one inventory, one vocabulary, and one body of evidence serve them, with accountability while the agent runs. Then a control is organised once and shown three times. The model adds two columns to the inventory a firm already keeps: the level of autonomy in force for each agent, and the evidence still missing for it.
The control plane can say no before the act
Networking defined the term first. The control plane instructs the devices how to handle what passes through them; the management plane monitors, configures, and maintains them. In a regulated firm the decision is the regulated act. So a layer that only observes discharges no obligation, however good its dashboards, and a layer in the path that can refuse an act does.
The inventories, the traces, the evaluations, and the cost reports observe: they tell the firm what happened, after it happened. On the map, what can refuse is the mandate at w3 and the check at w4 and p4, joined to the record at w5 and the loop at w6. Architects know the pattern from Kubernetes, where a request arrives authenticated and authorised, and admission control can still refuse it on policy at the moment it would be written.
For the model risk reader the model keeps one translation table: the control plane is the checkpoint; the ladder is the authority limit; a level of evidence is the condition; and the overhang is the list of conditions not yet met, each marked blocking or not.
One question per essential
The model asks one question of each essential of the map, and names the evidence that answers it. Of the agent itself: is this release fit to run, on an approved route? The evidence is a release validated as one unit, evaluated against error limits, tested after every change, and able to be stopped. Of its knowledge: does the information apply to this case? Sources with named owners, and the version in force on the date that matters. Of its mandate: who granted this authority, and how far does it go? One named owner, the scope, the limits, the expiry, and who may withdraw it.
At the act, the check asks whether this exact act is permitted, now, and reads the identity, the release, the basis, the mandate, the act itself, and the current state with its cumulative limits before it permits, blocks, or refers. After the act, the record asks what happened and who was affected, with the decision linked to its receipt and a way to recover. And the loop asks whether the agent created value and may do more, on benefits and harms against the baseline. The loop is what moves the mandate, and it moves it on evidence.
The questions become reusable through the control requirements, the record of each act, the evaluation methods, and the mapping to each platform. Then a project does not start from a blank page.
Declared, authorised, assessed, then permitted, blocked, or referred
The check is where an act is intercepted, and no person can sit in every act, so it runs at machine tempo. The agent declares the exact act, its scope, and its basis. The check authorises: the identity, and the act inside the mandate in force. Then it assesses whether the basis applies and meets the bar for the act's tier, whether the authority is in scope, and whether the route is admissible, and it halts on any one that fails. Below the bar there are two exits, block or refer to a named person. And the decision is recorded before the act runs, with the receipt linked after it.
Between the check and the act sits the permit. It is for one exact act, bound to the mandate version, the release, and the basis the agent declared, and it expires. It is void once the mandate narrows, once the agent's identity is revoked, or once the act changes in amount, counterparty, or basis. Every act carries one operation id, so a retry acts once, and an act whose outcome is unknown is reconciled with the receiving system before anyone retries by hand. Part two shows the same interval on a case.
The capacity held by permits in flight counts against the limit. So acts that each sit inside their mandate cannot together breach it.
Evidence is what the record can show
The model grades evidence from K0 to K3, and states each level as what must be true of the agent's record, from the bottom of the slide up. At K0, acts appear in application logs, with no act attributed to an agent identity and outcomes known by report. Most pilots we have seen are there today. At K1, measured, every act is recorded with the agent's identity, the principal, the time, the mandate version, and the check's decision, append-only, with retention set; the agent is in the inventory with a named owner, and its outcomes are measured against a test set owned outside the team that built it.
At K2, someone who did not run the agent rebuilds a period of its acts from the record alone, in a set time, and reports what could not be recovered. Decisions carry reason codes, provenance is recorded at the source, and the second line samples. The label of this level is still open. At K3, governed, every act carries evidential warrant and a named authority in scope, is graded to a consequence tier, and has a signed manifest bound to its basis, and the check computes admissibility for each act and refuses below the bar with no person in the path.
Some conditions run across every level. The release manifest lists what model risk validates: the model and its routing, the instructions, the tools and their scopes, the sources and their index builds, the policies, and the identity. Model risk classes every change, whoever built it, as material, targeted, or routine, and a change nobody classed is material. Evidence counts only when someone outside the team that built and runs the agent collected it, owns it, or can reperform it, so the agent's own traces are an input to the evidence. And K2 rebuilds the authority, the inputs, the versions, and the decision. A model's output need not be reproduced token by token.
The rule: autonomy may not rise above evidence
In the Hub's proposal, under review, each level of autonomy needs a level of evidence. A.0 is a tool and sits outside the ladder. A.1, one automated task, and A.2, where a person is ready to take control, need K1. A.3, where the agent does most tasks alone and a person decides the critical ones, needs K2, and "critical" has to be a rule written down. A.4, all tasks in stated circumstances, needs K3. And A.5, no oversight, has no cell: no evidence condition allows it. Most firms we have seen can show K1, which licenses A.1 and A.2. So the value above the line is value the models could deliver and the firm may not take, and raising the line is the work of the control plane.
One modifier: where an act cannot be undone, the evidence it needs rises one level. An A.2 agent that can settle a payment runs at K2, or under override. The override is signed by a named executive, scoped to named classes of act, dated, and expiring, and reported to the body that can refuse, which is named before it is needed. Running A.3 on K1 happens, and the model does not bless it. No override reaches a ceiling, the law, a confirmed sanctions match, a release without validation, or a shared identity.
The autonomy levels follow Kasirzadeh and Gabriel's agentic profiles. The evidence levels and the rule between them are the Hub's proposal, under review. Part three shows the same ladder from inside the loop, where the mandate narrows on a rule and widens on a signature.
Authority changes form at each altitude
Authority flows down the map and changes form on the way. At the enterprise it is a ceiling, how far any mandate may go, set by the board on the CRO's proposal, once or twice a year. In the workflow it is the mandate, what this agent may decide, for whom, and up to what amount, held by the business owner and challenged by the CRO, and it changes every day. On the platform it is entitlements and controls, which systems the agent may reach, kept secure and able to be stopped, held by the CTO and the CISO, and they change at every release.
An entitlement lets the agent reach a system. A mandate says what it may do there. And the rights that move authority are approve, challenge, suspend, restore, and grant an exception. A challenge from the second line holds a widening while it is open, and the narrower position holds until it is decided. Part four lays the same rights over the boxes where authority changes, firm by firm.
One row per agent: what is still unmet
The model lists, for each agent, the conditions its level of autonomy requires that are not yet met. Each unmet condition has a name, an owner, an assessor, a date, and a mark for whether it blocks: a condition that no override can cover, such as a shared identity or a release without validation, blocks the level outright. And the list lands in the inventory the firm already keeps, as a column beside the agent's profile, so no new register is proposed for it.
The row on the slide is invented. A payment exceptions agent is operated at A.3, which needs K2, and shows K1. Two conditions are unmet: reconstruction by a party that did not run the agent, owned by the head of payment operations and assessed by internal audit, and reason codes on every decision of the check, owned by the head of the agent platform and assessed by the second line. Neither blocks: both run under a signed override with a date. So its state is overhung. Supported with headroom, supported at the line, overhung while every unmet condition runs under a signed override, and structurally overhung once one of them is a condition no override covers, where output outruns the firm's ability to account for it: those are the states. The count tracks the work, and never compares two agents on its own.
The assessor did not run the agent: the second line, internal audit, or the client's risk function. The owner is an executive. The list is reviewed monthly and tested again at every claim of a higher level.
The questions every project answers
In a project team's hands the model becomes the questions the team answers before its agent acts. Which outcome and path are allowed, who grants and withdraws permission, and how independently the agent may work. Which information applies, who is affected by acting or by waiting, and what can stop it. Who takes a referral, and how quickly. What evidence confirms what happened, and how the team will stop, reconcile, and recover when something goes wrong. And what evidence would allow more independence.
Each answer needs an owner, a place where it is implemented, and evidence that it works. The team revisits the answers when the system changes, and before anyone proposes wider autonomy.
For engineers: one contract per essential
For the engineer who asks what to build, the Build pages give each essential its contract. Independence from any platform is a property of these contracts. Each stack the firm runs is a binding to them, and a product that ships one of the contracts natively becomes a binding too.
Where the model stands
The model is the Hub's outline, under review, with a first version planned for the fourth quarter of 2026, and a new version each year on the evidence that comes back. Still to write are K2's label, the evidence conditions for K1 and K2, written and tested before the first version, and the supervisory annex, quoted exactly and dated, with a jurisdiction column and an applicability test before each duty, and checked by an independent lawyer before publication. A worked register row from a real deployment belongs to the second version.
The evidence will answer questions the model cannot settle by argument. Does evidence at level K predict controllable behaviour at level A, cell by cell, on real deployments? That one decides whether the rule holds, and it goes first. When does a change to tools, instructions, or routing make a re-tooled agent a new agent? What record lets a party who was not there rebuild the acts, and what fails it? And does the check keep pace with an agent's tempo in payments and trading?
A workshop marks one workflow, one legal entity, and one environment, alone first and together after, and keeps both rounds. So the research can tell what a room believed from what it established, and the marks of many rooms become evidence for the model.