Per-agent assessment is a good model that stops working somewhere between thirty and a hundred agents — not because the assessors get slower, but because the unit of assessment is wrong. What replaces it is a class scheme with real inheritance: the common part assessed once at the place it is enforced, and a short, checkable residue each agent answers for itself.
The rule the whole scheme rests on. A class control is inherited only where the agent could not have been created without it, or where a platform-level check would find its absence without the owner’s cooperation. Everything else is owed per agent. Without that rule, class-and-inheritance is a way of asserting three hundred controls you have tested once.
Plain-English explainer · ISO/IEC 42001:2023 · OWASP Top 10 for LLM Applications, 2026 edition · Last reviewed September 2026
Most of what an agent assessment establishes is not specific to the agent. It is specific to the shape of the agent — what its credentials can reach, what verbs it holds, whether anyone is present when it acts, and what stops a wrong action propagating. Two support-triage agents built by two teams against the same connector set behind the same review gate need nearly identical controls, and assessing them separately produces two documents that differ in the header. So factor the assessment. The common part becomes a class, assessed once and thoroughly, by the people best placed to assess it. The specific part becomes a short declaration the agent’s owner produces and a reviewer can check in twenty minutes. The agent inherits the class and answers for its residue. That is the whole idea, and everything difficult about it lives in one question: which of the class controls are genuinely inherited, and which are merely written down.
This page covers the failure modes of the model being replaced, the five discriminators worth classifying on and the five that look like discriminators and are not, the table that turns those five into a class, a four-class scheme with a refusal tier, the inheritance contract, the per-agent residue with one record filled in, promotion and demotion, the four shapes drift takes, who owns each act and inside how many working days, and how to sample a population rather than a list. It assumes you already have a register of AI systems and agents and a working answer to when a tool becomes an agent. Without those two, classes have nothing to classify.
Key Takeaways
- Per-agent assessment fails by arithmetic, not by quality. The cost is fixed per agent and the population grows faster than the cycle completes, so the model degrades into a queue people route around, a form nobody reads, or an undefined low-risk exemption that absorbs everything.
- Classify on five discriminators — reachable data sensitivity, verbs held, blast radius, autonomy, and human reachability — each with an enumerated value set, and each value setting a class floor. The class is the highest floor, plus a short list of combinations that override the lattice. Never a weighted score: a score lets four mild attributes average away a payment capability and invites owners to argue the weights instead of the facts.
- A control is inherited only if the agent could not have been created without it, or a platform check would detect its absence without the owner helping. Anything else is owed per agent — the single rule separating a defensible scheme from three hundred controls tested once.
- The residue each agent still owes is short and mostly unautomatable: intended use a reviewer could fail, what an unacceptable output looks like, the named containment boundary with a measured reversal time, ownership, and the class basis. The reachable set and the verbs are generated rather than typed — a typed field is a claim, an exported one is evidence.
- Promotion takes effect on the date of the change, not the date of the paperwork, and the gap between them is reported rather than hidden. Demotion is never automatic, needs a positive test that no second path to the verb survives, and does not rewrite the class for the part of the period already elapsed.
- Assurance splits into four questions over four populations: the class control tested at the enforcement point, classification sampled and stratified so Class A is examined for misclassification rather than for controls, completeness reconciled and never sampled, and drift measured by tracing detected changes to re-reviews.
It fails by arithmetic, not by quality
A real assessment — scope enumeration, a conversation with the builder, a written intended use, a reviewer who is not the author — costs somewhere between half a day and three days of two people. That cost does not fall with repetition, because the expensive part is establishing facts about one specific configuration. It is entirely affordable at thirty agents and entirely unaffordable at four hundred, and nothing about the assessors changes in between.
What makes this worth describing carefully is that the model rarely fails visibly. It degrades into one of five states, each of which looks like a functioning process from the inside. Read the middle column for the mechanism and the right-hand column for the signal that tells you which state you are already in.
| The queue lengthens until people route around it | A genuine assessment — scope enumeration, an interview with the builder, a written intended use, a reviewer who is not the author — is half a day to three days of two people, and that cost does not fall with practice. Multiply it by a population any product team can add to from a low-code console, and the wait becomes longer than the thing being waited for. | Agents found running that were never submitted. The gap between the registry count and an independent enumeration widens every month, tracking the queue length rather than headcount. |
| The assessment shrinks until it is a form | Under queue pressure the honest response is to cut the assessment down. What gets cut first is always the same thing — the part that required somebody to go and look. What survives is the part the builder can fill in themselves, which is the part that was never evidence. | Every assessment reaches the same conclusion. Free-text fields converge on the same nine words because a template circulated. No assessment in the period recommended a change to the thing it assessed. |
| Low risk becomes an unbounded exception | Somebody sensibly proposes that trivial agents skip the process. Nobody writes down what trivial means, because writing it down is the hard part and the queue is the urgent one. The undefined exemption then absorbs the population, since every builder believes their own agent is the easy case and none of them is lying. | A register in which most entries carry no assessment and no recorded basis for not having one. Asked why an agent was exempt, the answer is a person rather than a rule. |
| The cycle is slower than the population turns over | An annual cycle over a population whose median agent is four months old is assessing a set that no longer exists. By the time the last agent is reached, many of the first have changed tools, scopes or triggers. | Assessment dates cluster, agent creation dates do not, and the two distributions barely overlap. Re-review is triggered by the calendar and never by an event. |
| Nobody can state anything true about the population | All four above end here. The governance function can describe individual agents in detail and say nothing defensible about the set — how many can write to a system of record, how many act unattended, how many reach regulated data, how many changed class this quarter. | The question that exposes it is not about an agent. It is: how many of your agents can move money, and how do you know that number is right? A per-agent model answers the first half and has no mechanism for the second. |
The unit is wrong, not the assessment
None of this makes assessment worthless. It makes the unit wrong. Assessment applied to a class produces a statement about every agent in it, testable in one place with a change log behind it. Assessment applied to an agent produces a statement that was true on the day it was written, and agents change without anybody deploying anything.
One honest disclosure before the scheme. No standard prescribes these classes, these discriminators or this number of tiers. ISO/IEC 42001:2023 requires an organisation to define its AI policy, assign roles and responsibilities, and control how AI systems are used — it does not hand you a classification scheme, and neither does any other framework in this space. The scheme below is ours. What a certification body or a service auditor tests is the control you state, which is why the design goal is a scheme proportionate enough that you will keep performing it.
Separate this from the other classification exercise you may already be doing. The capability tiers in when a tool becomes an agent answer whether something is an agent at all and what it holds. Classes answer what it inherits. They correlate, but collapsing the two axes costs you the ability to say that a low-tier deployment sits in a high class because of what it can reach.
Five attributes that actually separate risk
An attribute earns a place in a classification rule by passing three tests. It must be observable without asking the builder, because an attribute you can only establish by interview reintroduces the cost you were trying to remove. It must change the control set, because an attribute whose two values produce the same controls is decoration. And it must be stable enough to survive a sprint, because a rule driven by something that changes weekly produces classes nobody believes.
These five pass. Each carries its allowed values on the line beneath the question, and those values are the vocabulary the class table uses, that a recorded basis is written in, and that a drift detector compares against. A discriminator with no enumerated value set cannot be a register column and cannot be re-performed by a reviewer. Read the last block in each card too: every discriminator exists partly to displace a more intuitive attribute that does not survive a real population.
Data sensitivity reachable
What is the highest classification of data this agent’s credentials can reach — not the data it was designed to use, and not the data it usually touches?
public · internal · confidential · regulated-or-special-category
Reachability survives a change of prompt, of task and of owner. A design intention does not. The gap between designed-for and reachable is where nearly every surprise in this area lives, and it is measurable rather than debatable.
An agent built to answer questions from published help-centre articles is given a wiki token scoped to the whole space, because that was the platform default. The space also holds incident retrospectives and two draft regulatory submissions. The agent has never been asked about either. Its class is set by them anyway.
The data it was designed for, which is a statement of intent and cannot be tested against anything.
Capability to act
What verbs does it hold? Read only, write to a sandbox, write to a system of record, communicate externally, or move money and take irreversible steps?
read · write-sandbox · write-to-system-of-record · communicate-externally · transact-irreversible
Verbs are read off a tool manifest rather than described, which makes this the most objective of the five. It is the highest verb held, never the verb ordinarily used — an agent sending one external email a quarter holds the send capability continuously.
Two agents summarise support tickets identically. One posts the summary back into the ticket as an internal note. The other emails it to the customer. Same model, same prompt, same data, and the second one can make a factual assertion to a third party in your name.
How risky the team thinks it is, which correlates with how recently the team last had an incident rather than with anything about the agent.
Blast radius
If one action were wrong, how far would it propagate before something stopped it, and how long would reversal take?
contained-by-named-boundary (with a measured reversal time) · bounded-by-rate-or-volume-ceiling · unbounded
Most often collapsed into the previous one, and genuinely separate: a write to a staging table and a write to the live pricing table are the same verb at wildly different radii. The field that makes it usable is the containment boundary — the named mechanism that stops propagation. If you cannot name one, the radius is everything the verb can reach.
An agent updates one record per run, which sounds contained until the run is a scheduled sweep over eleven thousand records. Radius is a property of the loop as much as of the action inside it.
Volume of use, which is dealt with below — the once-a-quarter irreversible action outranks a million safe ones.
Autonomy
Who chooses the next step, and on what cadence — a person turn by turn, a person starting a multi-step run, a schedule, an event, or a continuously running loop?
turn-by-turn · human-initiated-multi-step · scheduled · event-triggered · continuous
Autonomy decides whether anyone is present at the moment of action, and it moves independently of everything else: an agent can gain autonomy without gaining a single new permission.
The most under-recognised class change in this subject is a cron entry. An agent run on demand, moved to a nightly schedule, has identical verbs, scopes and reach — and nobody is now watching it run, which changes what every other control has to do.
Whether it is called an agent. The label tracks the vendor’s marketing category and nothing about the deployment.
Human reachability
Within the window that matters for this action, is there a named person, on a rota, with both the authority and a working mechanism to stop it?
reachable-and-authorised-within-window · reachable-but-not-authorised · not-reachable-within-window
Human in the loop is a design claim. Reachability is an operational fact with four testable parts — named, rota’d, authorised, mechanised — and it fails on the last two far more often than the first. It also decays without anybody changing anything, which is why it is the discriminator most worth re-testing rather than re-reading.
An agent acts at 03:10 with a four-hour window before its output reaches a customer. There is an on-call rota, but it is the platform Sev-1 rota, whose runbook has no entry for this agent and whose members have no permission to disable it. Reachability is nil, and the paperwork says human oversight.
The existence of an approval step, which is an artefact. Whether that step reaches a human who can act inside the window is the question.
Take the maximum, never the average
The class is the highest of the five, not a blend. Every organisation that has built a risk matrix will want to weight and sum these, because a number feels more rigorous than a rule — and the number is the failure. Weighting lets an agent scoring mildly on four discriminators average away a payment credential on the fifth, and it moves the argument from the facts to the weights.
A maximum rule has exactly one attack: misstating an input. That is a better failure to have, because inputs are generated from the platform and a misstatement is detectable by comparing the recorded basis against the current export — which is precisely the test the evidence sample performs anyway.
Five attributes that look like discriminators
Each of these appears in real schemes, usually because it was the attribute already available in a spreadsheet. Availability is not discrimination. The first two belong elsewhere in the governance model and do useful work there. The third and fourth are real facts about a deployment that simply do not set its class. The fifth should be removed from every risk rule it has ever found its way into.
The model or the vendor
It is the first attribute everyone has, which is why it ends up in the classification rule. It governs almost nothing that matters here. Two agents on the same frontier model, one reading a public FAQ and one holding a payments credential, differ in every respect a control cares about. Vendor belongs in supplier due diligence and in the model-change trigger, but it does not belong in the class rule.
Customer-facing, as a single bit
Too coarse to carry the weight put on it. A read-only FAQ assistant and a refund-issuing agent are both customer-facing and share nothing else. Decompose it: does it communicate externally, does it make a factual assertion in your name, and does it affect an individual’s access to a service, a price, or an opportunity? Those three are discriminating, but the bit is not.
The platform it runs on
Hosting is an inheritance question, not a risk attribute, and the two get confused because the platform is the first column in every export. What a platform can enforce decides what a class is able to carry, but it does not decide how much governance an agent needs. The same platform routinely hosts both the lowest and the highest class — one agent reads a public FAQ turn by turn, another sweeps eleven thousand records against a system of record at two in the morning. Classify the deployment. Inherit from the platform.
Volume of use
The intuition that a busy agent is a risky agent is backwards. High-volume low-consequence work is the cheapest thing in the population to govern: the failures are frequent enough to be noticed, cheap enough to absorb, and visible in ordinary operational metrics. The once-a-quarter irreversible action is the expensive one — rare enough that nobody has a feel for it, consequential enough that the first failure is the finding, and invisible in every usage dashboard. It is the blast-radius discriminator stated from the other side: what matters is the consequence of one wrong action, not how many right ones preceded it.
A weighted risk score
The most attractive wrong answer, because it looks rigorous and produces a tidy number. Weighting lets a low score on four attributes average away a payment capability on the fifth, and it invites owners to argue the weights instead of the facts. A maximum cannot be gamed except by misstating an input, which is a far more detectable failure.
Vendor and model belong in supplier due diligence and in the model-change trigger, where they carry real weight. The platform belongs in the inheritance contract below, because what a platform can enforce decides what a class is able to carry. Volume belongs in capacity planning and in the operational metrics the owning team already watches every day. Every one of the five is a fact worth holding somewhere. None of them belongs in the rule that decides how much governance an agent receives.
Four classes, and the ability to say no
Four is not a magic number, but it is the smallest number that does the work. Three collapses the distinction between attended and unattended, which is the distinction that changes the most controls. Five or more produces boundaries nobody can remember and arguments nobody can settle. The fifth row is not a class at all — it is the vocabulary for refusal, and a scheme without one has no way of meaning anything by an approval.
Read the fourth column as carefully as the second — it is where the scheme is paid for. Then read the table immediately after this one, which is the part that turns five discriminator values into one of these five rows.
| Class | What qualifies | What the class carries | What it costs the owner | Expected share |
|---|---|---|---|---|
| Class A — Contained | Read-only over data classified no higher than internal. Human-initiated, one exchange at a time. Output is consumed by the person who asked for it and goes nowhere else automatically. | A registry entry with a named owner and deputy, a checkable intended use, the platform egress and identity baseline, and logging sufficient to establish that it ran. | Registration and an annual owner confirmation. Deliberately close to free, because an affordable bottom class is what makes an expensive top class politically possible. | The largest class by a wide margin — expect somewhere between three-fifths and seven-tenths of the population. Materially under half means the discriminators are being read off design intent rather than off reachability, and agents are being over-classified. Materially over eighty-five per cent means the verbs and the trigger configuration are being described by owners rather than exported. |
| Class B — Attended | Holds a write verb or an external destination, but every consequential action passes a named human who sees what is proposed before it takes effect. Confidential data may be in the reachable set. | Everything in Class A, plus: a scoped non-human identity rather than a person’s token, an enumerated tool manifest held as data, prompt and tool-call logging that reaches the assessment window, a documented approval step with a named approver role, and measured approval latency and rejection rate. | An annual review by someone other than the owner, re-review on any change event, and a quarterly report on whether the approval step is still behaving like a control. | The class that carries the most disagreement, because a mediation claim is doing the work of holding the agent below Class C — and that claim has to keep being true. |
| Class C — Unattended | Acts without a person present at the moment of action — scheduled, event-triggered or continuously running — inside a named containment boundary, with reversal possible within a stated window. | Everything in Class B, plus: a dedicated non-human identity with a maximum credential lifetime issued from a central store, a scope ceiling enforced at the platform, a named containment boundary with a measured reversal time, a documented stop mechanism with a tested owner and a rota, rate and volume ceilings, and tool-call logging with a defined retention period. | Semi-annual review, immediate re-review on any change event, and an annual test of the stop mechanism that produces a record of what was stopped and how long it took. | Around a tenth of the population, and small enough that every member can be named in a meeting. Much larger than that and the containment boundaries are notional — C is absorbing agents whose consequences are irreversible and which belong in D. |
| Class D — Consequential | Unattended and any one of: irreversible within the window that matters, externally visible as a factual assertion or a transaction, reaching regulated or special-category data, or affecting an individual’s access to a service, a price, or an opportunity. | Everything in Class C, plus: an impact assessment rather than a risk assessment, second-line review dated before go-live, a named accountable executive, a human checkpoint on the irreversible verb that shows the reviewer something they can genuinely check, and complete rather than sampled testing of its controls. | Reassessment on any change, quarterly review, and a standing place on a governance agenda where its incidents and near-misses are read rather than counted. | Low single figures, usually as a count rather than a percentage. The expensive work concentrates here and can only do so if Class A is genuinely cheap. If D grows faster than the population, the refusal tier is not being used and D has become the place things go instead of being declined. |
| Class X — Not permitted | A fully automated decision producing a legal or similarly significant effect on an individual. Unreviewed model output reaching a customer as a factual assertion. A standing credential that can move money without a per-transaction human release. An agent that can modify the controls governing agents. | Either the deployment does not proceed, or it proceeds under a written exception naming the approving executive, the compensating control, and an expiry date. An exception without an expiry is a policy change made by accident. | A quarterly review of the exception register that closes or renews every entry, and a report to whoever owns risk of what is open and for how long. | Most schemes omit this tier and then find they have no vocabulary for refusing. An assessor will ask to see a refusal. |
Notice where the steps are steepest. Between A and B the agent acquires a verb, and the controls become about approval, identity and change. Between B and C the human leaves the moment of action, and the controls become about enforcement, containment and investigability — which is where the real cost sits, and why an agent moved onto a schedule is not a small change. Between C and D the consequence becomes irreversible or externally visible, and independent review stops being optional.
The refusal tier is the row most schemes omit and the row an assessor is most interested in. Unreviewed model output reaching a customer as a factual assertion sits in it because the organisation, not the model, makes that assertion. A standing credential that can move money without per-transaction release sits in it because the failure is unbounded by construction — the reasoning is worked through in spending and transaction limits. An agent that can modify the controls governing agents sits in it because it can quietly remove the evidence that it did.
From five values to one class
A maximum across five attributes only means something if the five share a scale, and the scale is the class itself. Every value a discriminator can take sets a floor — the lowest class an agent holding that value is permitted to sit in. Find your agent’s value in a row, and the column it sits in is that discriminator’s floor. The class is the highest floor the five produce between them. A dash means no value of that discriminator lands in that column.
| Discriminator | Sets a floor of A | A floor of B | A floor of C | A floor of D |
|---|---|---|---|---|
| D1 Data sensitivity reachable | public · internal | confidential | regulated-or-special-category | — |
| D2 Capability to act | read · write-sandbox | write-to-system-of-record · communicate-externally | — | transact-irreversible |
| D3 Blast radius | contained-by-named-boundary | bounded-by-rate-or-volume-ceiling | — | unbounded |
| D4 Autonomy | turn-by-turn | human-initiated-multi-step | scheduled · event-triggered · continuous | — |
| D5 Human reachability | reachable-and-authorised-within-window | — | reachable-but-not-authorised | not-reachable-within-window |
Worked. A reconciliation agent reads a finance warehouse holding confidential data, writes corrections back into the ledger, runs nightly at 02:00, is bounded by a nightly exception report a named accountant drains, and can be stopped by that accountant inside the window. D1 confidential sets B, D2 write-to-system-of-record sets B, D3 contained-by-named-boundary sets A, D4 scheduled sets C, D5 reachable-and-authorised-within-window sets A. Highest floor is C, so the agent is Class C — set by one discriminator against four that would have left it lower. That is the maximum rule doing the only job it exists to do.
Then four combinations override the lattice, because a maximum over independent attributes cannot see an interaction. Apply them after the floors rather than instead of them, and record which one fired — an override is the part of a classification most likely to be argued with later.
| Regulated or special-category data is reachable and the agent acts unattended | Class D | Taken separately these two set floors of C. Together they describe an agent that can touch the most consequential data in the estate with nobody present, and the combination is worse than either — which is the one place a maximum rule under-reads and has to be corrected explicitly rather than by weighting. |
| A fully automated decision produces a legal or similarly significant effect on an individual | Class X | The discriminators cannot reach this, because it is a property of what the output decides rather than of what the agent holds. It is also the case most likely to be a legal determination rather than a control one, and the two are decided by different people on different evidence. |
| A standing credential can move money with no per-transaction human release | Class X | The failure is unbounded by construction. There is no containment boundary to name, so D3 has no value that describes it honestly and the lattice has to be short-circuited. |
| The agent can modify the controls that govern agents | Class X | It can remove the evidence that it acted, which makes every other control in the scheme conditional on this one agent behaving. No class baseline survives that. |
Which class controls are actually inherited
This is the load-bearing section, and the one that decides whether the whole scheme is defensible or decorative. The temptation is to write a rich class baseline and treat every line of it as covering every agent in the class. That is only true for the lines the platform enforces. A class that says credentials expire in ninety days, where that is a sentence in a document rather than a setting in the credential store, gives every agent in the class an aspiration rather than a control.
So state the contract in three parts, and be honest about which part each control falls into. The structure will be familiar to anyone who has read a service auditor’s report: it is the same division as complementary user entity controls, applied inside your own organisation, and it fails in exactly the same way when both sides assume the other one handled it.
| Inheritance | The test | Typical controls | What evidences it | Where it goes wrong |
|---|---|---|---|---|
| Fully inherited | The agent could not have been created without it, or it operates on the agent whether or not the owner knows it exists. | Network egress restricted to an allow-list at the runtime. Credentials issued only from the central store, with a maximum lifetime the store enforces. Tool calls written to an append-only log the agent cannot reach. Registration enforced at credential issue. | One configuration test at the enforcement point, plus its change log covering the period. The population of agents is irrelevant to the test, which is the entire saving. | Check for the bypass rather than the setting. An egress allow-list an administrator can waive per workload is inherited only where nobody waived it, and the waiver list is then part of the evidence. |
| Inherited with an owner responsibility | The platform makes the control available and makes the safe choice easy, but the owner can still configure it wrongly. | Scoped tokens are offered, and the owner picks the scope. Rate ceilings are configurable with a sane default that can be raised. Approval steps are supported and can be set to optional. Retention is set per agent within a platform-wide maximum. | The platform capability tested once, plus a per-agent check of the chosen value — cheap only if that value is exported rather than described. This row decides whether your registry is a control or a filing cabinet. | Exactly the structure of complementary user entity controls in a service auditor’s report, and it fails for the same reason: the provider tests the capability, the consumer never tests the configuration, and both believe the other did. |
| Not inherited | Nothing at the platform can produce it, because it is a statement about purpose, judgement or accountability. | The intended use and the declared out-of-scope uses. What an unacceptable output looks like for this agent. Who owns it and who deputises. The named containment boundary and the measured reversal time. Whether the rota actually holds the permission to stop it. | Per agent, always, with no sampling relief at Class D. These fields make an entry worth having, and they are the first casualty of a scheme that oversells inheritance. | The temptation is to write a class-level intended use — “Class B agents support internal operations” — and call it inherited. It is not checkable against a transcript, so it is not an intended use. |
The rule, stated so it can be applied on a Tuesday
A control is inherited if, and only if, one of two things is true. Either the agent could not have been created without it — registration enforced at credential issue, egress restricted at the runtime, logging written to a store the agent cannot reach. Or a platform-level check would detect its absence without the owner’s cooperation — a scheduled scan that finds an agent running outside the gateway, an identity report that finds a credential with no expiry. Everything else is owed per agent, and pretending otherwise is the failure mode this whole design exists to avoid.
Apply the rule honestly and the first version of a class baseline usually spreads across all three rows rather than sitting in the top one, with the uncomfortable share in the bottom row. The correct response is not to soften the rule but to move controls up the table by building enforcement — which is the work that turns a classification exercise into a governance capability, and the reason the platform team belongs in the room when the classes are designed.
One caution on the top row: test for the bypass, not for the setting. Break-glass paths, emergency credentials and any configuration overridable at deploy time turn the waiver list into part of the evidence and a population of its own. Where connector permissions are set per workspace rather than per tenancy, the tenancy-level setting is not the control you think you tested.
What each agent still answers for itself
Nine fields. That number is the promise the scheme makes to the people who build agents, and keeping it is what stops the residue growing back into an assessment. Every field that would be interesting but that nobody will maintain reduces confidence in the fields somebody does, so the discipline is to add nothing here without removing something.
Read the middle column first. Two of these nine must be generated from the platform rather than typed by an owner, and that distinction does more for the credibility of a register than any amount of process wrapped around it — principally because a generated field can be diffed, which is what makes drift detection possible at all.
| Registry identifier, name, owner and deputy | Typed once, then stable | A stable identifier that survives renaming, plus the name people use in conversation. Two named individuals, never a team or a distribution list. The deputy exists so the entry survives a resignation — the event that orphans more agents than any other. |
| Intended use, and declared out-of-scope uses | Written by the owner | A paragraph a non-specialist can hold against a real transcript and answer yes or no to, plus a short list of uses explicitly not approved. The test of a good one is that somebody could fail it. “Productivity” cannot be failed, which is why scope creep is undetectable wherever it appears. |
| What an unacceptable output looks like | Written by the owner | One or two concrete examples, in the owner’s own words. An owner who cannot produce one does not understand the agent well enough to own it, and finding that out at registration is far cheaper than during an incident. |
| The reachable set | Generated from the platform | Every system, dataset and space the agent’s identity can reach, with the classification of each, computed from effective permissions rather than from the grant requested. A typed version of this field is a claim. An exported version is evidence, and moving it from typed to generated is the highest-leverage change most registries can make. |
| The verbs held | Generated from the tool manifest | The tools and the operations each exposes, as the runtime sees them. Held, not used. A manifest diff against the last registry snapshot is also the primary drift signal, which is only possible because this field is data rather than prose. |
| Containment boundary and measured reversal time | Named by the owner, time measured | The named mechanism that stops a wrong action propagating, and how long reversal actually took the last time it was tested — measured, not estimated. A queue a named human drains, a deploy gate, a nightly reconciliation with a defined exception path: those are boundaries. |
| Human reachability | Named by the owner, tested on a cadence | The rota, the mechanism, the authority and the window. Record which rota, so that the claim can be checked against that rota’s runbook rather than against the word oversight. |
| Class, basis and date | Decided, then recorded | The class, the two or three discriminator values that set it, and the date. The basis is what an assessor samples: one naming values that no longer match the generated fields has found either drift or a bad decision. |
| Deviations from the class baseline | Approved, with an expiry | Anything the agent does not inherit, why, who approved it, and when it lapses. A class with no deviation register is either perfect or unexamined, and the second is far more common. |
Two fields repay defending against dilution. The third sorts owners with unusual reliability: an owner who can name a specific bad output understands the agent well enough to own it, and an owner who cannot get past “something wrong or offensive” has an agent somebody else built. And the sixth, because “we would roll it back” is a hope with a verb in it rather than a boundary. Where the mechanism is a stop rather than a gate, the design questions are worked through in kill switches and circuit breakers, and the record that makes a wrong action investigable afterwards is the subject of monitoring agents that work unattended.
How the two measured facts are actually measured
A measured reversal time and a tested stop mechanism are the two facts that separate Class C from a document about Class C, and both are routinely recorded without anybody being told how to produce them. Neither is long. Both are easy to perform in a way that yields a comfortable number and establishes nothing.
Measuring the reversal time
Inject a known-wrong action at the containment boundary — in shadow mode, or in an environment sharing the boundary’s actual mechanism rather than a copy of it. Start the clock at the action, not the alert. Stop it when reversal is complete and observable: the record corrected, the message withdrawn, the transaction reversed. Run it with the people who would really do it.
The date, the action injected, the environment, wall-clock elapsed split into detection and reversal, who performed it, and anything that did not work. Re-measure on the class cadence — semi-annually at C, quarterly at D — because the number decays as the systems around it change.
Timing the rollback command and excluding detection. That understates the real figure by the detector interval, which is usually the larger half, and it is the half that changes when somebody mutes an alert.
Testing the stop mechanism
Test it against the rota, not the switch. Page whoever is genuinely on call, out of hours, without saying in advance which agent it is. Require them to find the runbook entry, exercise the permission themselves, and confirm the agent has stopped acting — not that a control was clicked. A stop exercised by its designer during the working day tests the mechanism, not the control.
What was stopped, who stopped it, elapsed time from page to confirmed stop, which runbook entry they used, and — the field that earns the whole exercise — any permission they turned out not to hold.
Confirming that the switch exists. Every switch exists. The reachability example above fails on neither the switch nor the rota: it fails because the runbook has no entry for that agent and the people on the rota cannot disable it, and only a test run against the rota finds that.
One classification, filled in
Field definitions are easy to agree and hard to apply, so here is the residue populated for one agent — the Class A assistant from the worked year further down this page, which gained a connector on 4 June and was promoted to Class C effective that date. Nine residue fields plus the two artefacts an assessor asks for beside them. It is illustrative, not a client. Read it for the shape of an answer: every generated field carries its date and the identity it was exported through, and the basis is written in the discriminator vocabulary so that a reviewer can re-perform it.
| Registry identifier, name, owner and deputy | AGT-0112 · “Policy answers assistant”. Console alias policy-answers. Owner: Head of People Operations. Deputy: Internal Communications Lead. Both named at registration on 3 February 2026. The deputy field is why the entry survived the original builder moving teams in April. |
| Intended use, and declared out-of-scope uses | Answers employee questions about published internal policy from the policy space in the wiki, quoting the clause it used. Two out-of-scope uses declared, written so a real transcript can fail them. (1) It does not answer questions about an individual employee — pay, performance, leave balance, employment status. (2) Nothing it says is an approval. |
| What an unacceptable output looks like | “Telling somebody their notice period is four weeks when their contract says three months.” “Answering a question about a named colleague at all.” Written by the owner at registration. The second is why the 18 June review escalated instead of shrugging — it had become reachable ten days earlier. |
| The reachable set | Generated. Exported from effective permissions on 18 June 2026, not from the grants requested. Wiki: the policy space (internal) and — since 4 June — the people space, which holds probation reviews and two grievance records. HR system: read on the employee directory. Highest classification reachable: regulated-or-special-category. The same export at registration on 3 February returned internal and nothing above it. |
| The verbs held | Generated. Tool manifest as the runtime sees it on 18 June: wiki.search (read), wiki.get_page (read), hr.directory_lookup (read). No write verb, no external destination. Manifest diff against the 3 February snapshot shows exactly one addition — hr.directory_lookup, first present in the snapshot taken on 4 June. |
| Containment boundary and measured reversal time | Boundary: the agent answers in the thread it was asked in and writes nowhere else, so a wrong answer propagates as far as the person who read it. Reversal is a correction posted into the same thread. Measured on 22 June against an injected known-wrong answer: 41 minutes wall-clock, 37 of them detection. The estimate beforehand was “a few minutes”. |
| Human reachability | reachable-and-authorised-within-window. The People Operations rota, 09:00–18:00 IST Monday to Friday, which is the window that matters because the agent is invoked turn by turn. Runbook entry POL-07 names the disable step. Owner and deputy both hold the platform permission, verified 22 June. Recorded as the rota’s name rather than “the on-call team”, so it can be checked against that rota’s runbook. |
| Class, basis and date | Class C. Basis, written in the discriminator vocabulary so a reviewer can re-perform it from the two exports: D1 = regulated-or-special-category (people space: probation and grievance records) → floor C. D2 = read → A. D3 = contained-by-named-boundary → A. D4 = turn-by-turn → A. D5 = reachable-and-authorised-within-window → A. Class = highest floor = C. No lattice override fires — the agent is not unattended, so the regulated-and-unattended override does not apply and it is C rather than D. |
| Effective date, and detection date | Change made 4 June 2026. Detected 18 June by the scheduled manifest diff. Class effective 4 June, recorded 18 June — fourteen days, written down as fourteen days. The class history reads Class A from 3 February to 3 June and Class C from 4 June onward, and the fortnight governed as A while it was not A is named in the exception narrative rather than dated away. |
| The exports the decision was made from | Two files stored with the record rather than referenced from it: effective-permissions-AGT-0112-2026-06-18 and tool-manifest-AGT-0112-2026-06-18, each carrying its export timestamp and the identity it was taken through. The 3 February pair is retained beside them, because the basis for the promotion is the difference between the dates. |
| Deviations from the class baseline | One open. Class C requires a dedicated non-human identity from the central store with a maximum credential lifetime, but this agent still reaches the HR directory through a shared People Operations service account predating the store. Compensating control: the account is read-only and this agent’s use of it is separable in the gateway log. Approved 19 June 2026 by the Director of People Operations, who is neither requester nor owner. Expires 30 September 2026. Renewals: none. |
Three things in that record do the work. The basis names values, not adjectives, so a reviewer holding the current export can re-perform the decision and disagree with it specifically. Four of the five discriminators still read Class A — the promotion came from one attribute moving, which is what a maximum rule looks like when it fires. And the reversal time is a measured forty-one minutes against an estimated few, which is the whole argument for measuring it.
Eight triggers, and the date they take effect
A class assigned at registration and never revisited is a snapshot of an agent that no longer exists. These eight events move an agent up, and the useful property of all of them is that they are detectable by machine — which matters because seven of the eight are things nobody involved experiences as a governance event. Adding a connector feels like fixing a complaint. Adding a cron entry feels like tidying up.
| Trigger | How it is detected | Why it is missed |
|---|---|---|
| A tool is added to the manifest | Manifest diff against the last registry snapshot, run on a schedule and on deploy. | No single addition usually changes the class. The seventh does, and nobody was counting. |
| A scope is widened on an existing credential | Diff of effective permissions for the agent’s identity, not of the grant it was issued. | A role inherited through a group is invisible in the grant record and fully present at runtime. Grants under-report, but effective permissions do not. |
| A schedule or an event trigger is introduced | Trigger configuration compared against the registered autonomy value. | The cheapest class change in existence and the least noticed. Verbs unchanged, scopes unchanged, nobody present. |
| The approval step is removed or made optional | Configuration diff, plus the latency and rejection-rate measures that catch a step which is still present and no longer functioning. | Where an agent’s class rests on mediation, this is the change that silently promotes it to unattended. |
| A destination changes from internal to external | Destination allow-list diff, and a review of any new connector whose target is outside the tenancy. | One field on one connector turns an internal note into a statement to a customer in your name. |
| The agent gains the ability to call another agent | Manifest diff, where the added tool is itself an agent endpoint. | The transitive rule: the caller takes the callee’s class unless the interface it calls through is demonstrably narrower than the callee’s full surface, evidenced rather than asserted. |
| Data the agent already reaches is reclassified | Classification-change feed from the source systems, mapped to the agents whose reachable set includes them. | The agent did not change at all. It is the promotion trigger missed most universally, and it is only detectable if the reachable set is held as data. |
| The audience is widened | Sharing-scope export from the agent platform. | Publishing to a channel, a team or a customer-facing surface changes who bears a wrong answer, which is a class attribute even when nothing technical moved. |
Promotion takes effect on the change, not on the paperwork
This is the single most consequential piece of discipline in the scheme, and it is unpopular the first time it is applied. When a manifest diff on the eighteenth of the month reveals a connector added on the fourth, the agent is Class C from the fourth. Not from the eighteenth, and certainly not from whenever the re-review is signed. The fourteen days in between were governed as Class A and were not Class A, and the record should say so.
Dating promotions from approval instead makes the gap vanish from the paperwork while leaving it intact in the world, and produces a register in which no agent has ever been out of class — a claim no assessor believes, which casts doubt on everything beside it. Two consequences follow. Detector frequency becomes a control parameter with a cost and a benefit rather than an implementation detail: a weekly manifest diff bounds the worst case at seven days, a daily one at one. And the controls that operate regardless of class — logging, egress restriction, credential lifetime — are what actually covers the gap, which is a further argument for pushing controls up the inheritance table.
The re-review that follows decides one of two legitimate outcomes: the new class stands, or the capability is removed and the agent comes back down through a demotion. What is not legitimate is concluding the promotion was unnecessary without either happening, which is how a detector gets quietly disabled three months later. Where the change is a new tool rather than a new scope, the approval question is worked through in tool approval and capability change.
Where class schemes quietly rot
Promotion is the part everyone designs. Demotion is the part that decides whether the scheme is still true in year three. The asymmetry is real and worth stating plainly: promotion responds to a capability that is already present, so it can fire on detection. Demotion responds to a capability that is absent, and absence is a much weaker fact — it can be temporary, it can be partial, and it can be arranged.
| Demotion is never automatic | Promotion fires on a detected change, because the risk is already present. Demotion cannot: the absence of a capability is not evidence it was removed deliberately or will stay removed. A scope that came off in a refactor can go back on in the next one. Every demotion is a decision with an author. |
| Demotion requires a positive test, not an absence of evidence | The claim is not “we removed the write scope”. It is an effective-permissions export taken after the change showing the verb gone, plus a check that no second path to the same verb survives. This is where demotions fail in practice: the scope came off the OAuth application and the agent still holds a service account in the same system, so the capability never left. |
| A cooling period at the old cadence | A demoted agent keeps its previous review cadence for one full cycle. It is cheap, it costs nothing when the demotion was genuine, and it is the only thing that reliably catches the pattern of a capability removed shortly before an assessment window and restored shortly after. |
| Demotion does not rewrite the period | An agent that was Class C for seven months of a twelve-month period is tested as Class C for those seven months. A register storing only current state cannot answer a question about a period, and a period is the only thing a service auditor examines. |
| Record the reason, not just the class | A demotion with no recorded reason is indistinguishable from a reclassification made to reduce workload, and it will be read as the second. Name what was removed, who verified it, and what would send the agent back up. |
Hold class history with effective dates from the first day. Retrofitting it is close to impossible, and it is also the raw material for the one metric that says whether any of this is working.
Four shapes, and only one that anyone notices
Drift is not misconduct. It is the ordinary accumulation of capability by an agent working well enough that people keep asking it to do more. It takes four shapes with four detectors, and none of the four can be caught by asking the owner: in two the owner is unaware anything happened, in one the owner did it and does not experience it as a change, and in the fourth every artefact the owner could show you looks healthy.
Tool accretion
Someone adds one connector to close one complaint. Each addition is individually defensible and none of them is submitted as a change, because nobody experiences adding a connector as a change to a risk profile.
A scheduled machine-to-machine diff of the live tool manifest against the registry snapshot. Any diff is a trigger, and the review decides whether it is a class change. Human attestation does not catch this — the person attesting is the person who added the tool and does not think of it as an addition.
Running the diff only at review time. The interval between the change and the next annual review is the exposure, and if capability changes arrive evenly across the year, the median exposure on an annual cadence is six months.
Scope widening underneath the agent
Nothing about the agent changes. The identity it uses is added to a group, or a role it holds is granted a broader permission set, because somebody else needed that for an unrelated reason. The agent’s reachable set doubles and no record anywhere mentions the agent.
A dated effective-permissions export per non-human identity, taken from the identity provider rather than from the agent platform, retained for the whole assessment period and diffed against the previous export. Retain the diff itself as well as the two exports, because the diff is the evidence that the detector ran. Monthly is enough for most of the population and weekly for Class C and D. Any widening is a promotion trigger regardless of who caused it or why. The cheap version needs no new process at all: add the registry’s non-human identities to the access-review population that already exists for human accounts, and let the same people review them on the same cycle.
Reviewing the grant history of the agent. The grant is unchanged. Everything that matters happened one level up in the identity model.
Reclassification of the data underneath
A source system starts holding a class of data it did not hold before — a new integration lands personal data in a support tool, a migration moves regulated records into a shared warehouse. Every agent reaching that source inherits an exposure it never requested.
Where the source systems publish classification changes, a feed mapped against the reachable-set field. Most organisations do not have that feed, and the fallback is a pull rather than a push: re-run the reachable-set-to-classification join quarterly, comparing the classification each source carries today against the value recorded in the class basis. That turns a feed you do not have into a check you can schedule. Both versions need the reachable set held as structured data. Where it is prose the shape is undetectable, and the control description should say that it detects reclassification in the systems that publish it — not imply coverage of the ones that do not.
Treating data classification and agent governance as two programmes that meet annually. They are the same programme viewed from two ends.
Mediation decay
The approval step still exists. The reviewer now clears three hundred and forty items a day in batches of forty, at a median of a few seconds each, and has rejected nothing since the spring. Nothing was removed and the control has stopped working.
Measure the queue rather than inspect it. Two numbers are enough: median approval latency, and rejection rate over a rolling window. A queue with a median measured in seconds and no rejections in eleven weeks is not a control, and the agents behind it are unattended whatever the design document says.
Sampling approval records for existence. Every record exists. That is precisely the property that makes this shape invisible to a conventional test, and it is why it belongs in the class control rather than in a per-agent check.
Measure the queue, do not inspect it
Two numbers make it visible: median approval latency, measured from proposal to decision, and rejection rate over a rolling window. Report both per queue rather than in aggregate, because aggregation across queues hides precisely the one that has failed. Set a threshold on each in advance, so that the finding is a measurement crossing a line rather than a judgement assembled afterwards by somebody who already knew the answer.
A rejection rate of zero is not automatically damning, and one follow-up separates the two cases. If the proposals really are almost all correct, the reviewer can describe a near-miss or point to proposals amended rather than rejected. If they cannot name anything they have ever changed, the control has never shown that it could change an outcome. What good mediation looks like is the subject of human in the loop that works.
The counter-drift metric. Count the agents whose class changed in the period. Across a live population of a few hundred, zero is a bad number: it says the detectors are not running. Publish it alongside the detected-change count and the median interval between the two, and you have three figures that describe whether this scheme is alive.
Four questions, four different populations
Once classes exist, you stop testing agents. You test the class controls, the classification decisions, the completeness of the population, and whether classification kept pace with change. Each of those is a different question over a different population, and the most common and most expensive error in this whole design is running one method across all four.
Is the class control operating?
The enforcement point — the credential store, the gateway, the platform configuration — not the agents that inherit from it.
Test the configuration, then establish from its change log that it held for the period. Often a population of one system with a change history — the whole economic argument for classes: one control tested once, however many agents stand behind it.
Testing the setting today and inferring the period. A configuration test is a point-in-time test. The period comes from the change log, and if the change log does not cover the configuration you have tested a fact about Tuesday.
Are agents in the right class?
The registry, stratified by class.
Sample classification decisions and re-perform them from the generated fields. This is a twenty-minute job per agent when the reachable set and the verbs are exported, and a two-day job when they are described — which is the entire reason to generate them.
Sampling proportionally. A proportional sample of a population weighted to Class A spends nearly all its effort on the class where being wrong costs least.
Is the population complete?
Independent enumeration sources, not the registry.
Reconciliation with counts stated and every difference explained: identity-provider grants for non-human identities, the platform’s listing per environment, gateway destination logs, repository and pipeline scans, spend records. The strongest version makes registration a precondition of credential issue, at which point completeness is enforced rather than argued.
Sampling. A sample of a register tells you nothing about what is absent from it, and this is the single most common error in the whole design. You cannot sample your way to completeness.
Did classification keep up with change?
Change events in the period, from the drift detectors.
Trace each detected event to its re-review and measure the interval against the window your procedure promises. Then compare detected events against promotions actioned. A large gap either way is informative.
Reporting zero class changes as stability. Across a live population of a few hundred agents, no promotions in a quarter means detection is broken, not that nothing moved.
Stratify, and sample the cheap class for the expensive error
Take a population of three hundred agents distributed two hundred and ten, sixty, twenty-five and five across the four classes. A proportional sample of twenty-five puts roughly eighteen items into Class A, which is the class where being wrong costs least and where the controls are thin by design. That sample is almost entirely wasted, and it is what a naive application of a sample-size table produces.
Stratify instead, and change what you are looking for as you go down the table: in the high classes, whether the stated controls operated, and in the low class, whether the agent belongs there at all.
| Stratum | Coverage | What you are looking for |
|---|---|---|
| Class D — Consequential | Test every one, every period. No sampling. | That the stated controls operated, and that the impact assessment and the second-line sign-off predate go-live rather than the audit. |
| Class C — Unattended | Test a substantial fraction, and cover every C agent at least once across a two-period cycle. | The containment boundary and the stop mechanism, specifically whether either has been exercised. A stop mechanism that has never been tested is a design, not a control. |
| Class B — Attended | Sample, sized to the frequency of the control being tested rather than to the number of agents. | Whether mediation is real. The latency and rejection measures do most of the work, and the sample confirms that the measured queue is the one the agents actually pass through. |
| Class A — Contained | Spot-check, and spend the saved effort on the misclassification question instead. | Not whether Class A controls worked — they are thin by design — but whether these agents belong in Class A at all. Sample it hunting for a write scope, an external destination or a schedule nobody noticed. The interesting error is never an over-controlled Class D agent. |
Sample the decision, not the agent. The unit of testing is the classification record — class, basis, date, and the exports the basis was drawn from — and the test is a re-performance: does the current export still support the recorded basis? A mismatch has found either undetected drift or a wrong decision. It is a twenty-minute job rather than a two-day one, and those twenty minutes are the whole economic case for generating both fields.
On sizes, use the same frequency-based logic you would apply to any other control rather than inventing an agent-specific table — the reasoning is set out in sampling and sample sizes. The two agent-specific adjustments are the stratification above, and the rule for what happens when a sample throws an exception: widen toward the whole stratum, and ask whether the error has a systematic cause. Misclassification is usually systematic, because it travels through a shared template, a platform default or a single team’s habit. One wrong Class A agent found in a sample of twenty-five is not a four per cent error rate. It is a thread to pull.
What the transition actually looks like
An illustrative composite, not a client. A software company with an agent platform goes from thirty-four agents to a hundred and forty-one in under a year, and the governance model has to change halfway through. The figures are illustrative, but the sequence and the failure points are the part worth taking.
| Baseline | 6 Oct 2025 | Thirty-four registered agents, all assessed individually. Median eleven working days from request to approval, two people in the governance function. Nothing about this model is wrong at thirty-four agents. |
| The inflection | Jan – Mar 2026 | A low-code agent console is opened to every product team. Registered agents go from thirty-four to ninety-six in eleven weeks. The assessment queue goes from eleven working days to forty-seven. A reconciliation against platform listings finds twenty-two agents running that were never submitted — the queue had become longer than the patience of the people in it. |
| The decision | 30 Mar 2026 | The per-agent model is abandoned and the minute says why: not because it was wrong, but because it had stopped being performed. A scheme replaced for being unaffordable invites a different question from one replaced for being ineffective. |
| Class design | Apr 2026 | Five discriminators agreed, four classes plus a refusal tier, and the inheritance contract written. The definitions take nine working days. The seven weeks after them are platform engineering to move three class controls from promised to enforced — because a control that is only promised cannot be inherited, and would have to be evidenced two hundred times instead of once. |
| Reclassification | May – Jun 2026 | One hundred and eighteen agents classified from generated fields rather than from questionnaires: seventy-one A, twenty-nine B, fourteen C, two D, and two in the refusal tier. The two refusals stop there — one held a standing payment credential with no per-transaction release, one sent unreviewed model output to customers as a factual assertion. The first pass runs at roughly twenty-five minutes an agent where both generated fields exist, and at the better part of a day each for the eleven where they did not. |
| First drift finding | 18 Jun 2026 | A manifest diff on a Class A agent shows a connector added on 4 June. Its reachable set now includes an HR system. It is promoted to Class C effective 4 June, not 18 June — which puts fourteen days of the period out of class and into the exception narrative, and is the correct answer rather than the comfortable one. |
| Mediation measured | Jul 2026 | Approval latency and rejection rate are measured on the Class B queues for the first time. One shows a median of six seconds and no rejection in eleven weeks. That class control is reported as not operating for the period and the agents behind it are re-tested as unattended — a worse finding than a missing control, and a more useful one. |
| Steady state | Sep 2026 | One hundred and forty-one agents. The governance function is one full-time role plus a review rota, and median time from request to class assignment is two working days. Eleven promotions and three demotions in the quarter — the number that says the detectors are alive. |
Three things in that sequence matter. The longest piece of work was not writing the classes but the platform engineering that moved three controls from promised to enforced, and a scheme designed without the platform team in the room finds that dependency late. The first drift finding was recorded with its true effective date rather than the comfortable one. And the mediation measurement produced the worst finding of the year — a class control reported as not operating — from two numbers nobody had ever calculated.
The first ninety days, in order
That was somebody else’s year. This is your own quarter, and the order is negotiable in every respect but one: the rule comes before the population. Everything else can be done badly and improved. A scheme written to fit a list that already exists cannot be, because the defect is in its provenance. The last column repays the most attention.
| Days | Step | Who owns it | Deliverable that must exist at the end | Where teams get it wrong |
|---|---|---|---|---|
| Days 1–10 | Publish and approve the class definitions | AI governance lead, approved by the executive who owns risk | The scheme at version 1.0: five discriminators with their allowed values, the class floors, the lattice overrides and the refusal tier — carrying an approval date that precedes the first classification. | Writing them after the population is classified. A rule reverse-engineered to fit a list is the first thing unpicked in an interview. |
| Days 1–20 | Stand up the two generated fields | Platform and identity owners, with the governance lead specifying the format | A dated effective-permissions export and a dated tool manifest per agent, in a shape that diffs mechanically rather than by reading. | Accepting a described reachable set to hit the date. Everything downstream — the twenty-minute re-performance, drift detection, a re-performable basis — rests on these two being data. |
| Days 21–45 | Classify from the generated fields | AI governance lead with each agent owner | A class, a basis in the discriminator vocabulary, and an effective date on every agent. Around twenty-five minutes each where both exports exist. | Classifying the agents whose owners answered first. The part of the population you have not heard from is the part the exercise exists for. |
| Days 30 onward | Run one detector on a schedule | Platform team runs it, and the governance lead reads the output | The manifest diff running weekly with its run history retained, and the first promotion it produces dated from the change rather than from the detection. | Waiting until all four detectors are ready. One running beats four designed, and the first promotion makes the effective-date rule real rather than theoretical. |
| Days 46–60 | Reconcile against one independent source | Governance lead, with identity producing the enumeration | A reconciliation with counts stated and every difference explained — a count of differences and their reasons, not a count of agents. | Reconciling against the agent platform’s own listing. It enumerates the agents on that platform, which is a smaller and easier question than the one being asked. |
| Days 61–90 | Close the inheritance gap the exercise found | Platform team, with the governance lead re-stating the contract | Every class control either moved up the inheritance table by building enforcement, or explicitly re-stated as owed per agent. Whichever it is, written down. | Leaving a control in the baseline because it ought to be enforced. Each one is a population of individual assertions waiting for somebody else to find. |
One note on effort, because the ranges above hide the figure everyone asks for. Writing the scheme is days rather than weeks — nine working days in the composite above, and a team spending two months on it is arguing about boundaries rather than drafting them. The expensive item is the platform engineering in the last step, seven weeks there, and you cannot size it until the inheritance test has been run honestly against the controls you already have. Run that test in week one, before anybody commits to a date.
The registry and the review cadence
A registry becomes a filing exercise the moment its fields stop being consulted by anything. Three properties prevent that. Generated fields should outnumber typed ones. Every entry should carry a next action with a date, since a register whose only dates are created and last-reviewed is a cabinet. And the strongest version is the one the platform checks against rather than describes: where an agent without an entry cannot obtain a credential, completeness stops being an argument and becomes a control.
The cadence then has four distinct acts, and conflating them is how a scheme ends up doing reassessment work on Class A entries and confirmation work on Class D ones.
| Act | Who performs it | What it involves | Where it applies | How it fails |
|---|---|---|---|---|
| Confirmation | The owner | A two-minute check that the entry is still accurate, presented alongside the generated fields so that the owner is confirming against data rather than against memory. | Class A, annually. | Sending a confirmation request with no generated fields attached. The owner then confirms their recollection of the agent, which is the thing that drifted. |
| Review | Someone other than the owner | Generated fields checked against the recorded class basis, the deviation register checked for expiries, and the drift detector output for that agent read rather than counted. | Class B annually, Class C semi-annually, and either on any change event. | A review record saying a review occurred. A usable one names what the reviewer looked at and concluded — the difference between a record and evidence. |
| Reassessment | Second line, with the accountable executive | The full exercise — impact assessment refreshed, containment boundary re-measured, stop mechanism tested, human reachability re-established against the current rota. | Class D quarterly, and on any promotion into Class D. | Refreshing the document without re-running the test. The reversal time and the stop mechanism are measurements with a shelf life, not paragraphs. |
| Event-driven re-review | Whoever the class assigns, within a stated window | Triggered by a detector rather than a date: a manifest diff, a permissions widening, a trigger change, an upstream reclassification, an altered approval step. | Every class, including A — the whole point of Class A is that events, not calendars, move things out of it. | A window with no clock on it. Promise a number of working days, measure the actual interval, and report the tail rather than the median. |
| Population reconciliation | The governance lead, with identity and platform owners | Registry counted against independent enumeration sources, differences enumerated and each one explained and closed. | Quarterly at minimum, monthly where the population is still growing quickly. | Asking teams what they have. A self-reported population cannot establish its own completeness. |
Who is accountable, by when, and what happens when the clock runs out
A cadence says how often. It does not say who, or by when, or what the state of the world is when nobody did it. That last column is the one that decides whether a scheme holds under pressure, because every act in it has a failure state and the failure state is reached by default. A service level with no stated consequence is a preference.
| The act | Accountable | Consulted | Service level | When it is breached |
|---|---|---|---|---|
| Raise and register an agent | The building team’s named agent owner | The platform owner, who cannot issue a credential without the entry | Before the credential is issued | No breach state, by design. Where registration is not enforced at credential issue this row becomes a request rather than a gate, and the completeness argument goes with it. |
| Assign the class | The AI governance lead | The owner for purpose and boundary. Identity and platform owners for the two generated exports | Two working days from a complete entry | Escalates on day three. Until classified the agent holds Class C — the only default that does not make delay attractive. |
| Scheduled review | A reviewer named on the entry who is not the owner | The owner | Within the month it falls due — A and B annual, C semi-annual, D quarterly | Ten working days past month-end it goes on the governance report by name rather than in a count. A count of overdue reviews is a metric. A list is an action. |
| Event-driven re-review | The AI governance lead, who owns the queue the detectors feed | The owner, and whoever made the change — frequently not the same person | Five working days from detection for C and D, ten for A and B | The agent takes the class the detected change implies without waiting for the review. Holding it until the paperwork catches up is the habit that puts the effective date on the wrong day. |
| Run the drift detectors | Platform owns the manifest and trigger diffs, and identity owns the effective-permissions diff | The governance lead, who reads the output rather than the count | The detector’s own schedule, with the run history retained | Out of hours, a detector firing on a C or D agent pages the platform on-call with one instruction — capture the diff and raise the re-review, not judge it. On an A or B agent it queues to the next working day. A detector that did not run is a finding in that period. |
| Action a promotion | The AI governance lead | The owner, and the accountable executive where the new class is D | The class changes on the date of the change, and the controls it carries land within ten working days | Where the controls cannot land in ten days the shortfall becomes a deviation with an approver and an expiry, not an open item on a list. That is the difference between a scheme and a backlog. |
| Approve a demotion | The AI governance lead, on a positive test performed by identity or the platform | The owner requests it, and the previous reviewer is asked whether anything they saw argues against it | Ten working days | Nothing happens and the agent stays in the higher class. The delay costs the owner and nobody else, which is the correct incentive. |
| Approve a deviation | A named executive who is neither the requester nor the agent’s owner | The governance lead, who drafts the compensating control and sets the expiry | Ten working days, and the agent does not go live meanwhile | The request lapses rather than being deemed approved. A queue that approves on timeout is a scheme approving by inaction. |
| Chase an expiry | The governance lead owns the register, and the approving executive owns their own entries | — | Thirty days before expiry the approver is asked to close or renew | On the date, an unclosed exception closes itself and the waived control becomes due. Expiry as a reminder rather than an event is how these registers become permanent. |
| Reconcile the population | The AI governance lead, accountable for the reconciliation and for every unexplained difference in it | Identity and platform owners produce the enumerations, but neither is accountable for the result | Quarterly at minimum, monthly while the population grows faster than a tenth a quarter | An unexplained difference is not closed as investigated. It carries into the next reconciliation with its age attached, because an ageing difference is the most informative number here. |
| Adjudicate a disputed classification | Whoever owns risk — the executive who approved the class definitions, not the lead who applied them | Owner and governance lead each state their case in writing, and the decision is recorded with its reasoning | Ten working days from the dispute being raised | The agent holds the higher of the two disputed classes until resolved. It is the only default that does not reward stalling, and publishing it in advance stops stalling being the strategy. |
One structural note. Population reconciliation is the row most often handed to a meeting rather than to a person, because the enumerations come from identity and the platform and neither team owns the register. Split it: identity and platform produce the enumerations and answer for their accuracy, the governance lead answers for the reconciliation and for every unexplained difference in it. Nobody is then responsible for both the count and the explanation of why it is wrong.
Five tests that tell you it has become theatre
Run these against your own scheme rather than waiting for somebody external to. Each has a cheap answer and an uncomfortable one, and the uncomfortable one is usually correct on the first pass. No entry has changed class in six months: detection is broken. Every review record says the same thing: nobody is reading the generated fields. An owner cannot say what an unacceptable output would be: the entry has an owner in name only. Completeness rests on having asked the teams: there is no completeness argument. And a class control cannot be demonstrated at an enforcement point: it is not inherited, and every agent in the class owes it individually.
Ownership is the field that makes every other field maintainable, and it is the first thing tested in an interview — the reasoning generalises beyond agents in control ownership. Where the accountable role does not exist internally, or where it exists but is also the role building the agents, a fractional CISO or DPO engagement is the usual way of separating the two.
Your classes are not anybody else’s classes
The most expensive confusion in this area is between an internal control designation and a statutory risk category. They are different objects, decided by different people, on different evidence, and they can disagree in both directions without either being wrong. Before the statutory ones, though, there is a nearer collision to settle — the other classification schemes already running inside your own estate.
Start with your own register. If you built the AI system register first — and this page assumes you did — every entry already carries a tier: minimal, standard, elevated, not permitted. Those tiers and these classes are close enough to be confused and different enough to disagree, because the tier reads a system and the class reads what an agent’s credentials can reach. Map them once, in writing.
| Register tier | Agent class | What the mapping hides |
|---|---|---|
| Minimal | Class A — Contained | Near-identical in practice, on different bases: the tier reads the system as a whole, the class reads what the agent’s credentials can reach. A Minimal system hosts a Class B agent the moment that agent holds a write scope the system record never described. |
| Standard | Class B — Attended | Both are the somebody-is-in-the-path tier, and the class is stricter. Standard accepts a human informed by the output, while Class B requires a named human who sees the proposed action before it takes effect, with latency and rejection rate measured. |
| Elevated | Class C or Class D | Elevated does not separate attended from unattended, which is the split that changes the most controls. Resolve it with D4 and D5: unattended inside a named containment boundary is C. Irreversible, externally visible, regulated-data-reaching or individual-affecting is D. |
| Not permitted | Class X — Not permitted | The same tier under two names, and the one row where both schemes were built from the same rule. Keep one exception register across the two, or an exception approved in one will be invisible in the other. |
State which one is authoritative, because a mapping with no precedence rule is two schemes with a table between them. The workable answer: the register tier governs the estate at large, including systems that are not agents. The agent class governs anything holding a tool manifest, and is therefore what drives controls, cadence and evidence for every agent. Where the two disagree on one deployment, the disagreement is informative — it usually means the register describes the system as specified and the class describes it as permissioned. The tiers in tool-server governance are a third vocabulary and deliberately map onto neither. They classify a server — what one tool surface exposes and how it is approved — where a class is a property of an agent. The transitive rule joins them: an agent’s class is set by everything it reaches through the servers it calls, so a low-tier server tells you nothing about an agent that also calls a high-tier one.
The EU AI Act is Regulation (EU) 2024/1689. Whether a system is high-risk under it is a legal determination about the system’s purpose and its deployment context, not a judgement about how much control you have wrapped around it. Your Class D is an internal designation that says this agent gets the expensive treatment. A deployment can be Class D internally and fall entirely outside the Act’s high-risk categories, and — far more dangerously — a deployment can be Class A internally and be high-risk in law, because the Act cares about what the system decides about people rather than about how many verbs it holds.
Where the Act does reach a deployment as high-risk, Article 14 requires human oversight, and the wording repays attention because it is about capability rather than presence: oversight has to be exercisable by natural persons with the competence, authority and means to do it. That is the same set of facts as the human-reachability discriminator above — named, rota’d, authorised, mechanised — which is why the discriminator is worth recording as an operational fact rather than a design claim. An organisation that can produce the rota, the permission and the tested mechanism is answering two questions at once.
The timetable moved, and the direction is often misread. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It deferred the stand-alone high-risk obligations for Annex III systems from 2 August 2026 to 2 December 2027, and AI embedded in products already covered by Annex I product-safety law to 2 August 2028. That is more time to build the control, not an exemption from having one — and it is worth being precise that 2024/1689 and 2026/1744 are two different instruments rather than two names for the same thing, since conflating them is how a compliance plan ends up citing an amending regulation for an obligation it never created. The scoping question for your own entity is worked through in the EU AI Act overview.
ISO/IEC 42001:2023 is the AI management system standard and it is the framework a class scheme most naturally lives inside, because it is a management system rather than a control checklist — it asks you to define scope, assign roles, control how AI systems are used, and then demonstrate that the system you defined is the system you operate. A class scheme is a defensible answer to that demand and is not prescribed by it. Do not cite Annex A control numbers from a summary. Read the standard, and if you already run ISO 27001 the integration question is covered in integrating the two management systems. The roles your organisation occupies — provider, deployer or both, and differently for different agents — are worked through in the AI roles an organisation can occupy.
The security literature moved in the same direction the discriminators point. The OWASP Top 10 for LLM Applications 2026 edition, published on 4 August 2026, lists Prompt Injection at LLM01 and Excessive Agency at LLM03 — up from LLM06 in the 2025 edition, the largest upward move on the list, driven by production incidents in agentic systems. Excessive Agency is, in substance, an argument that three of the five discriminators on this page are the ones that matter: what the agent can do, what it can reach, and how much it decides without a person. The same edition names categories for sensitive information disclosure, supply-chain exposure and unbounded consumption, each of which lands somewhere in a class baseline. Cite those by name alongside the edition rather than by number, since the ranking moves between editions.
Under the SOC 2 trust services criteria there is no criterion named for agents and none is needed. The behaviour lands on the existing ones: logical access for the identity and scope questions, change management for promotion and the tool manifest, monitoring and incident criteria for the drift detectors and what happens when one fires, and risk assessment for the class scheme itself. What an auditor tests is the control you describe, so the scheme is only as good as the description — which is the subject of the next section.
What gets asked for, and what gets sent back
A class scheme changes the evidence conversation more than it changes the controls. The requests get fewer and heavier: one enforcement-point test standing behind two hundred agents, and a sample of decisions rather than a stack of assessments. That concentration is efficient and unforgiving — a class control that cannot be evidenced at its enforcement point does not fail once.
| The request | What satisfies it | What comes back rejected |
|---|---|---|
| The class definitions, and evidence they were approved before they were used | The approved scheme with a version, an approval date preceding the classification exercise, a named approver, and the discriminator definitions with their allowed values. Plus the refusal tier, because a scheme with no way to say no reads as a labelling exercise. | Definitions dated after the population was classified. A rule reverse-engineered to fit a list is the first thing unpicked in an interview, and it cannot be defended by the person who wrote it. |
| The classification decision for a sampled agent | The class, the two or three attribute values that set it, the date, and the generated exports the decision was made from — the effective-permissions export and the tool manifest as they stood on that date. | A class with no basis. A basis naming values that do not match the current export, with no promotion record in between, which means either drift went undetected or the decision was wrong. |
| Evidence the inherited class control operated for the period | The configuration at the enforcement point, the change log for that configuration covering the full period, and the list of any per-workload waivers with their approvals. One test, standing behind every agent in the class. | A screenshot of the setting taken during fieldwork. It establishes today. The period is established by the change history, and without it the inheritance claim collapses into an assertion about every agent individually. |
| Evidence the population is complete | Reconciliation to independent sources with counts stated and differences explained. Stronger still: evidence that an agent cannot obtain a credential without a registry entry, which turns completeness from an argument into a control. | A single export from the agent platform offered as the population. It enumerates the agents on that platform, which is a different and smaller question than the one being asked. |
| Evidence promotions were detected and actioned | Detector output for the period, each detected change traced to its re-review, the interval measured against the stated window, and at least one promotion effective from the date of the change rather than the date of the paperwork. | A period with no promotions across a live population. It is offered as stability and reads as broken detection, and the follow-up question is always what the detectors are and when they last ran. |
| Evidence the mediation control in the attended class is real | Latency and rejection rate per queue over the period, alongside a sample of approvals showing what the reviewer was shown. At least one proposal amended or rejected, because a control that has never changed an outcome invites the question of whether it could. | Approval records offered for existence only. Every record exists in a queue that has stopped working, which is exactly why this test measures behaviour instead of counting artefacts. |
The row organisations are least prepared for is the period question on inherited controls, and the fix is the change log behind the configuration rather than the configuration. Keep the detector run history for the same reason — cheap to keep, impossible to reconstruct, and the thing that converts a claim about drift detection into evidence of it. How this fits the wider evidence discipline is covered in evidence collection, and what happens when a detector fires on something that turns out to be an incident in AI incident classification.
The two registers you will be asked for and probably do not have
A refusal shows the tier is load-bearing rather than decorative. A deviation shows the class baseline is a standard somebody had to be excused from rather than a description of whatever people already do. Both are referred to far more often than they are specified, so here are the fields — short enough that nobody has an excuse, specific enough that the record answers the follow-up question instead of prompting it.
Refusal record
One per proposal stopped by the refusal tier. Written at the time, not reconstructed when somebody asks to see one.
proposal · requester
What was proposed, in the requester’s own words, and who asked for it. Captured before the decision, so the record is not a reconstruction written by the person who said no.
date · decider
The date and the named individual who decided. A refusal attributed to “governance” is a refusal nobody can be questioned about, which makes it useless as evidence and unpleasant as politics.
discriminator · value
Which discriminator stopped it, at which value, or which lattice override fired. This is what makes a refusal re-performable and what stops the tier drifting into a matter of taste.
outcome
What shipped instead, or nothing. The most useful refusals are the ones that produced a narrower design, and recording the narrowing is how the tier earns its reputation as a design input rather than a veto.
converted_to_exception
Whether it became a bounded exception, and that exception’s identifier. A refusal that quietly turned into an approval with nothing linking the two is the precise failure this tier exists to prevent.
Deviation record
One per class baseline control an agent does not meet. The register of these is what makes a class baseline a standard rather than a description.
agent · class_baseline_control
The agent, and the specific baseline line not met — quoted from the class definition rather than paraphrased, because a paraphrase is what lets an exception widen without anyone amending it.
compensating_control
What stands in its place and how it is evidenced. “Accepted risk” is not a compensating control. It is the absence of one, recorded politely.
approver
A named executive who is neither the requester nor the agent’s owner. The executive’s own agent is the case this field exists for, and it is the case where it is hardest to enforce.
approval_date · expiry_date
Both, always. An exception without an expiry is a policy change made by accident, and it will be read that way by whoever finds it.
closing_review
The named review that closes or renews it, with its date, so that expiry is an event on somebody’s calendar rather than a property of a field nobody queries.
renewal_count
Renewals to date. A third renewal is a policy change being made by instalments: send it to whoever owns risk as a proposal to amend the class baseline, not back through the exception queue.
Two fields carry more weight than their length suggests, and both are about time. The renewal count, because an exception renewed three times is an amendment to the class baseline being made in instalments. And converted_to_exception on the refusal record, because the quiet failure of a refusal tier is not that it goes unused: it is that things refused in March reappear in June as bounded exceptions with nothing linking the two.
The cases that break the clean rule
The design above handles the ordinary population. These five are where it needs an explicit answer written down in advance, because each of them produces a genuine argument — between governance and a builder, between security and legal, or between you and an assessor — and settling them at the whiteboard is worth several days later.
Agents that create other agents
You cannot pre-register something that will exist for ninety seconds. Register three things instead: the parent, the template children are instantiated from, and the constraint envelope — the tools, identity and ceilings a child cannot exceed. Then require children to be enumerable after the fact from a log carrying the parent, the template version and the lifetime. The envelope is the control, the log is the evidence, and the parent takes the class the envelope permits rather than the class of a typical child.
One agent calling another across a class boundary
The transitive rule is unavoidable: if a Class A agent can call a Class C agent, the caller can cause everything the callee can cause, and it is Class C. The only defence is a genuinely narrower interface — the callee exposes one operation with fixed parameters rather than its full surface — and the narrowing has to be evidenced from the interface definition rather than asserted from the design intent. Record the call graph in the registry. It is the field most registries omit and the one that turns a population into a system.
The vendor agent inside a product you already bought
Your CRM ships an agent and enables it by default. Do not create a parallel system record. Attach the agent fields to the supplier entry that system already has, and classify the deployment rather than the product. The complication is genuine: you frequently cannot export its reachable set or its tool manifest, which means two of your generated fields are unavailable. That is itself a class-relevant fact. Record the limitation, push the question into the supplier review, and classify on what the vendor will tell you in writing — not on what the feature appears to do.
The agent whose owner has left
Find orphans by reconciling the owner field against the personnel roster at two dates inside the period, and prevent them with the deputy field. When one surfaces, resist switching it off immediately — establish what it does, who depends on it and what its credentials reach, because an unowned agent with a live credential is a finding whether or not it is running. Then give it a real owner or stop it, and give the credential an expiry either way.
The executive’s agent
An agent built by or for a senior executive tends to hold unusually broad reach, to be exempted informally, and to be the one nobody wants to classify — which also makes it the highest-value one to compromise. No special treatment here survives contact with everyone below it: classify on the same discriminators, and where a deviation is genuinely needed, register it with an approver who is not the executive and an expiry date. Someone independent enough to raise it should see that register.
The first two share a root: both are questions about a call graph rather than about an agent, and an organisation holding its population as a flat list gets both wrong. Record what calls what, including agents reached through a shared tool server, and the transitive class rule becomes computable rather than contestable. Where agents hold repository or pipeline access, the constraints are set out in coding agent governance, and the identity questions underneath all of this are the subject of agent identity and delegated authority.
What gets pushed back on and the answer
These three come from assessors, from enterprise buyers, and from the internal audit function that will eventually look at this. Two have good answers. The second does not have a comfortable one, and the right response is to give the uncomfortable answer rather than the constructed one.
If one class control fails, do you not have two hundred findings?
Yes, and that is the correct consequence rather than an argument against the design. Concentration cuts both ways: one test covers two hundred agents, and one failure reaches all of them. It is why class controls belong at enforcement points with change logs and monitoring rather than in documents, why the deviation register exists, and why the population behind each class control should be a number the governance function can state on request.
You promoted an agent effective fourteen days before you detected it. What covered those fourteen days?
Nothing did, and the record says so. Dating a promotion from detection rather than from the change would make the gap disappear from the paperwork while leaving it in the world, and an assessor who finds that pattern will reasonably distrust everything else. The mitigations are detector frequency and the class controls that operate regardless of class — logging, egress, credential lifetime. The honest answer names the gap, the detector interval that bounds it, and what was reviewed in the period after the fact.
Show me an agent you refused.
The most informative question anyone asks about this scheme, and the one that most schemes cannot answer. A refusal tier that has never been used is either a sign of an unusually disciplined builder population or a sign that the tier is decorative. Keep the refusals, keep the bounded exceptions that replaced some of them, and be able to describe one in specifics: what it wanted to do, which discriminator stopped it, and what shape it eventually shipped in.
The difference between a policy and a scheme is whether anything it produces was generated by a system rather than written by the person being governed. Count your artefacts on that basis before anybody asks you to. The approval architecture underneath is separated out in use-case approval versus vendor approval.
Frequently Asked Questions
What is risk-class inheritance for AI agents?
How many classes should we have?
Does ISO 42001 require risk classes for AI agents?
Is an internal agent class the same as an EU AI Act risk category?
Did the Digital Omnibus remove the EU AI Act high-risk obligations?
How do we stop owners gaming their class?
Can we sample agents rather than assess all of them?
What triggers a promotion to a higher class?
Can an agent ever be demoted to a lower class?
How do we govern agents that create other agents?
What is the smallest version of this that actually works?
Related reading: building the AI system and agent register, when a tool becomes an agent, the ten governance questions, monitoring agents that work unattended, human in the loop that works, risk assessment versus impact assessment, shadow AI and personal accounts, AI competence obligations, and the ISO 42001 hub.
Related Reading
AI Supplier Due Diligence and Ongoing Review
The artefacts to obtain, why plan tier changes the answer, and what triggers re-review.
Read moreWhen a Model Changes, What Do You Reassess?
The material-change test, the detection problem, and regression testing at scale.
Read moreMonitoring Agents That Work Unattended
Tool-call history is the load-bearing record. What must be captured for an action to be investigable.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more