Bringing agent credentials inside the recertification perimeter

The companion teardown on this site — “Your access recertification covers people. Most of your principals are not people.” — argues that the gap is structural rather than a matter of diligence. A recertification pack is assembled from a directory built around employment, reviewed by owners assigned because someone hired them, and closed by a trigger that fires when a person leaves. Agent principals enter through a different door, hold entitlements no joiner-mover-leaver event will ever touch, and are absent from the pack not because anyone excluded them but because nothing in the process was asked to include them. I am not going to re-argue that. This piece assumes it and answers the question that follows: what do you build, precisely, and what does it cost.

The scope is deliberately narrow. Not an agent governance programme. Not a model inventory. Not a discovery tool that crawls the estate and reconciles what it finds against what it expected. A register of the agent principals your institution creates, populated at the moment of creation, that emits one attestable line per principal into the recertification process you already run. The boundary matters because everything outside it is a multi-year programme, and the thing inside it is a quarter of work that produces an artefact an examiner can read.

Two constraints rule out most of what you would otherwise build first, and both come from the sector rather than from taste. The design has to survive an examination that asks for evidence rather than architecture — an examiner does not accept a diagram of a control, they ask what the control produced, on what date, signed by whom. And it must not depend on a control framework the current supervisory guidance expressly declines to specify. Taken seriously, those two force nearly every decision that follows.

What has to be true before anything else

Start from the premise and follow it without shortcuts, because most of what follows is forced, and it is worth being able to see which parts are genuinely choices.

The premise: an identity without a defined lifecycle owner and a tested revocation path is a liability, not an asset. Both qualifiers carry weight. Without an owner, there is nobody to ask whether the thing is still needed, so nobody ever asks, so it is never removed. Without a tested revocation path, the ability to withdraw the access is a belief rather than a capability, and beliefs about revocation are unusually badly calibrated for reasons the specifications themselves are candid about.

First consequence, and it is the one the sector imposes. If the design has to survive an examination that asks for evidence, every layer of it must be judged by the artefact it produces rather than by the function it performs. A register that holds beautiful records and emits nothing is worth exactly as much, in an examination, as a slide describing a register. That rules out the shape most identity programmes take, which is a dashboard: a dashboard is a view over state, and a view is not an artefact. What an examiner can read is a dated, signed line attributing a decision to a named person. So the register's output type is an attestation line, and everything upstream exists to make that line true.

Second consequence. If the output is one line per principal, the population has to be enumerable, and enumerable requires that the unit be defined. This sounds like pedantry until you try to count. Is one OAuth client with four scopes one principal or four? Is an agent that assumes a cloud role to reach a warehouse a principal, or is the role the principal? Institutions answer these differently, and answer them inconsistently across their own teams, which is why counts from two tools never reconcile. The unit has to be written down before anything is counted, in a form a program can check.

Third, and this is the load-bearing move: a record missing any required field is not partial. It is undefined, and undefined fails closed. The value of that rule is not moral rigour — it is that “undefined” is actionable in a way “too many” is not. An institution told it has roughly four thousand non-human identities convenes a working group. An institution told it has two thousand six hundred defined records and fourteen hundred undefined ones, each with a named missing field and a named issuance path, has a work queue and a specific person to ask about each item in it. The first number produces a programme. The second produces a backlog, which is worse to look at and far better to have.

Fourth consequence, and this is where the sector instantiation earns its place. The institution already runs a process that consumes exactly this shape of record. Access recertification takes a principal, an entitlement, an owner and a review period, and produces a signed decision; it has tooling, a cadence, an escalation path, an audit trail and a track record of surviving examination. Building a second, parallel review process for agent principals means building all of that again, badly, then explaining to an examiner why there are two. So the register reviews nothing. It emits into the process that already works, and that single decision is why this is a quarter of work rather than a programme.

Fifth, and it is the thing the existing process cannot supply for itself. Recertification's removal trigger is a departure. A service account never resigns. So agent principals simply added to the pack are reviewed on a cadence and never triggered by an event, which leaves every intermediate decision to an owner's judgement with nothing to anchor it. The register has to supply the missing trigger, and the only honest substitute for a departure is an expiry — a moment at which the credential stops working unless somebody re-argues for it. That is why expiry is required rather than optional, and why the record must make a non-expiring credential explicitly representable, so the argument for one happens at creation instead of at incident.

Sixth. Revocation has to be observed, not asserted, because the specifications governing it are explicit that the acknowledgement is not the evidence. RFC 7009 makes the cascade from a refresh token to the access tokens issued under the same grant a SHOULD, conditioned on the authorization server supporting access-token revocation at all, and in the same section concedes that in practice there could be a propagation delay in which some servers know about the invalidation while others do not; Section 3 adds that self-contained tokens may require back-end interaction between the authorization server and the resource server if immediate revocation is desired. For certificate-based identity the bound is plainer still: RFC 5280 states that the time granularity of revocation is limited to the CRL issue period, which may be up to one hour, one day, or one week depending on the frequency that CRLs are issued. And RFC 6960 permits pre-produced OCSP responses while warning that their use allows replay attacks in which an old good response is replayed prior to its expiration date but after the certificate has been revoked — the countermeasure written as a SHOULD, not a MUST.

Seventh, and this closes the derivation. Because undefined is a first-class state and the output is an attestation line, the emitter needs a third outcome. The existing pack offers an owner two: certify, or revoke. An undefined record can honestly be given neither — you cannot certify a principal whose purpose is unknown, and you cannot instruct an owner to revoke an entitlement whose revocation path has never been observed to work. So the line carries a third recommendation, cannot certify, with the missing field named on the row. That is the only genuinely new thing this design puts into the institution's process, and it is one enumeration value.

The two exclusions, read directly

The obvious objection is that this is a problem the model risk function already owns, that a bank of any size has a validated model inventory with an inventory owner and a periodic review cycle, and that agent systems will simply be onboarded to it as they mature. That objection deserves to be taken at its strongest, because at a large institution it is very nearly right about everything except the one thing that matters.

A bank with over thirty billion dollars in total assets — the applicability threshold the Federal Reserve names in SR 26-2, which states that the letter is expected to be most relevant to banking organizations with over $30 billion in total assets regulated by the Federal Reserve — runs privileged access management with credentials vaulted and checked out, joiner-mover-leaver automation wired to the human resources system, quarterly entitlement recertification with named attesting owners, a tiered model inventory, an independent validation function that challenges model owners, and an examiner-facing evidence process that has survived cycles of scrutiny. The concession is real and it is not grudging: the machinery exists, it works, and the people running it are better at it than most of the people writing about it.

The problem is not maturity. It is that the perimeter the model risk function operates has just been drawn to exclude the object, twice, in the same document.

Read footnote 3 of the interagency guidance in full rather than in the two sentences that circulate. The document is “Supervisory Guidance on Model Risk Management”, dated 17 April 2026, whose masthead reads Board of Governors of the Federal Reserve System, Federal Deposit Insurance Corporation, Office of the Comptroller of the Currency, and which is distributed as the attachment to Federal Reserve SR 26-2. It is jointly the three agencies', and the identical sentence appears in the OCC's transmittal bulletin as well.

Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document. However, the principles described in this guidance apply to traditional statistical and quantitative models and non-generative, non-agentic AI models.

The third sentence is the half nobody quotes, and it is the half that decides the argument. The agencies did not remove a duty. They placed the determination of appropriate governance and controls for out-of-scope tools on the banking organization's own risk management and governance practices. Read as a deferral rather than an exemption, this is straightforwardly a stronger position for building now: every obligation attached to the underlying action survives untouched, and what was withdrawn is the framework that would have specified the controls. Nobody is going to hand an institution an agent control specification. The institution has been told, in the agencies' own words, that determining the controls is its job.

The second exclusion is less discussed and, for anyone building the plumbing, more consequential. Section II defines the object the guidance governs.

For the purposes of this guidance, the term “model” refers to a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates. The term “model” in this guidance excludes simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use.

Consider what an agent deployment is actually made of. A deterministic tool-calling router that maps an intent to an endpoint. A policy decision point. A credential broker that exchanges one token for another. An audit writer. None of those applies a statistical, economic or financial theory to produce a quantitative estimate; they are deterministic rule-based processes and software, excluded by name. The model they front is carved out by footnote 3. The two exclusions meet, and the entire stack sits in the space between them.

Then there is the non-enforceability sentence, which appears in identical wording in both documents and is usually quoted with its stronger half missing: “This guidance does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism against a banking organization.” In the interagency attachment it sits at the end of Section I, immediately before the scope section, carrying footnote marker 1. The first clause tells you the document is not a rule. The second tells you that a control built to it earns nothing and a control absent against it costs nothing. Anyone designing an agent control regime whose justification is “the guidance requires it” has built the justification on a document that has explicitly disclaimed being the kind of thing that requires anything.

Be precise about what comes next, because the loose version of the claim is that separate AI guidance has been promised. It has not. The OCC's transmittal bulletin states that the agencies plan to issue in the near future a request for information that addresses model risk management generally and considers, in particular, banks' use of AI, including generative AI and agentic AI and AI-based models. A request for information is a consultation: the agencies are asking what should be in the specification, not drafting it. And that sentence appears only in the OCC transmittal — the strings for request for information return zero matches across all twelve pages of the interagency attachment. The honest reading is that the specification does not exist, its content is an open question, and the answers will be written against whatever institutions have already built by the time the consultation closes.

Supersession should be stated by agency rather than loosely. Fed SR 26-2 supersedes the Federal Reserve's own SR 11-7 and SR 21-8. OCC Bulletin 2026-13 separately rescinds four OCC issuances: the Model Risk Management booklet of the Comptroller's Handbook, OCC Bulletin 1997-24 including its appendix, OCC Bulletin 2011-12, and OCC Bulletin 2021-19. SR 11-7 does not appear in the OCC's rescission list because it was never an OCC issuance. Anyone still citing SR 11-7 as current guidance is citing a superseded document; cite it only as superseded.

So the answer to the objection is not that model risk management is weak. It is that model risk management has been told, by the three agencies supervising it, that this object is not its object — and told, in the same footnote, that determining the controls falls to the institution. The design must therefore stand on instruments that were not deferred. They exist, and they are older and harder than the one everybody is watching.

The perimeter that did not move

Banking supervision has classed non-human identities as users for years, in an instrument nobody cites in the agent conversation. The FFIEC's authentication and access guidance sets out practices for the authentication of, in its own enumeration, users accessing financial institution information systems, including employees, board members, third parties, service accounts, applications, and devices — and then defines all of those, collectively, as users. Its risk assessment section is more direct still: Identify Users. Identify all users, including employees, service accounts, and users at third parties, that access financial institution information systems and data. The duty to enumerate machine identities is not new, does not depend on the 2026 model risk guidance, and was not affected by anything that happened in April.

There is a revealing detail in how that guidance handles the object: it does not define a service account itself. Footnote 14 imports the definition wholesale from an outside control framework — a dedicated account with escalated privileges used for running applications and other processes, which may also be created just to own data and configuration files, and which is not intended to be used by people except for performing administrative operations, attributed to the CIS Controls version 8 glossary. The banking regulator's definition of the thing it instructs institutions to enumerate is a citation to somebody else's glossary. That is not a criticism of the FFIEC; it is direct evidence for the second consequence above. The sector has no definition of its own for the unit being counted, which is why institutions' counts disagree, and why writing the unit down is the first engineering task rather than a documentation task.

And now the gap, which I checked rather than assumed. Across the full eighteen pages of that guidance, the string for revoke appears zero times. The string for terminate appears zero times. The string for disable appears six times, and not one of the six is about withdrawing a principal's access: two sit inside a cited reference title, two are email and browser hardening — macro scripts disabled, unnecessary browser plug-ins disabled or removed — and only two touch accounts at all, being the changing or disabling of default credentials for system, service, or administrative accounts and the disabling of unused remote-access software. The sector's principal authentication guidance instructs institutions to identify and authenticate service accounts, and never addresses withdrawing their access. I confirmed that by regular expression over the locally extracted full text of the document, not by reading a summary of it, because this is exactly the kind of claim that gets repeated after somebody skimmed a section heading.

The binding instrument is where owner and expiry stop being good practice and become law. For a New York covered entity, 23 NYCRR 500.13(a) requires written policies and procedures designed to produce and maintain a complete, accurate and documented asset inventory, and specifies the minimum contents: a method to track key information for each asset, including, as applicable, the owner, the location, the classification or sensitivity, the support expiration date, and the recovery time objectives; and the frequency required to update and validate the inventory. Owner and expiry — two of the seven fields this design argues for — are already legally mandated inventory fields. The compliance date ran two years from the Second Amendment's 1 November 2023 effective date, which is 1 November 2025. It has passed.

The access rule is where the human framing shows through in the verbs. 23 NYCRR 500.7(a) requires covered entities to limit the number of privileged accounts and limit the access functions of privileged accounts to only those necessary to perform the user's job; to limit the use of privileged accounts to only when performing functions requiring such access; to review all user access privileges periodically, at a minimum annually, and remove or disable accounts and access that are no longer necessary; and to promptly terminate access following departures. The annual review is the hook this design emits into, and it says all user access privileges — which, given the FFIEC's definition of users, includes service accounts on any straightforward reading. The departure trigger is the gap: a service account has no departure. Class A companies must additionally implement a privileged access management solution, and Class A is defined at 500.1(d) with exact thresholds rather than by size in the abstract — at least $20,000,000 in gross annual revenue in each of the last two fiscal years, and over 2,000 employees averaged over the last two fiscal years including affiliates wherever located, or the alternative revenue limb. Use the thresholds, not the phrase “large banks”. The compliance date for 500.7 ran eighteen months from 1 November 2023, which is 1 May 2025.

That is the whole strategic point of this design, and it is worth saying flatly. You do not need the deferred framework. The obligation to enumerate machine identities is supervised practice under the FFIEC. The obligations to record an owner and an expiry per asset, and to review all user access annually and remove what is unnecessary, are binding law in New York. A register that emits agent principals into the annual review, with an owner and an expiry, is a control derived from instruments that were not deferred and that no regulator has disclaimed. When the request for information closes and something eventually gets specified, an institution running this will find its practice described rather than corrected.

The unit, field by field

Seven fields. Each is here because leaving it out breaks something specific, and it is worth walking the derivation rather than presenting the schema as settled.

Issuer. Which system minted the credential, and how revocation is reached through it. Without this you cannot find the thing in order to withdraw it, and the field has to carry the reachability rather than a bare name, because the issuer families behave differently enough that a flattened field produces a runbook that does not work. An OAuth authorization server has a revocation endpoint whose semantics RFC 7009 describes; a private certificate authority has a CRL distribution point and, sometimes, an OCSP responder. The register stores what the runbook will need, not what looks tidy in a table.

Principal. Which workload holds the credential — the field where the institution has to make its own definition, because nobody else has made one for it. Even the leading workload identity standard declines. The SPIFFE-ID specification defines a SPIFFE ID as an RFC 3986 compliant URI comprising a trust domain name and an associated path, and states that the path component allows for the unique identification of a given workload. It never defines what a workload is. That is a boundary honestly drawn rather than a defect, but it means the register must carry the institution's own resolution rule as data, and re-resolve the principal on a schedule so a workload deleted six months ago surfaces rather than lingering as a plausible string.

Credential material. The class of credential and its identifier. Class matters more than it appears to, because revocation semantics differ per class in ways that are not interchangeable, and because the drill attaches to the class rather than the instance. An OAuth client with a refresh token, a certificate with a serial, a static secret at a named path, a cloud role identifier: four things, four failure modes, one field that must not collapse them.

Owner, and only a named individual. A directory principal the register re-resolves on a schedule, with its own resolution expiry: past that moment the record returns to undefined until re-resolution succeeds, which bounds the decay to the schedule interval. The type forbids a group, a distribution list or a team name. That will be argued with, because assigning four hundred principals to individuals is unpopular and assigning them to a team is easy — and it is how attestation becomes unfalsifiable, because a team cannot be asked what a credential is for. 23 NYCRR 500.13(a) says owner; it does not say owning team.

Purpose, as a reference rather than a sentence. Free-text purpose is unfalsifiable, and an unfalsifiable field is decoration with a maintenance cost. The workable form is a reference into a register of action classes the institution already maintains, plus the change record or product approval that caused the credential to exist. The second half is the one people skip and the one that pays: a credential traceable to an authorising decision can be retired when that decision is superseded, which is the closest thing to a decommissioning trigger this problem has.

Expiry. The moment it stops working on its own. Three shapes are real: it expires at a timestamp, it rotates on an interval, or it does neither. The third is representable because it exists in enormous numbers in every real estate, and it is never a defined record. That rule is harsh on purpose: the argument for a credential that never expires is sometimes correct — a market data feed that must not fail at three in the morning is not a governance failure — and it should be made at creation by a named person, rather than discovered during an incident by whoever is on call.

Revocation binding. Not a URL. A method, a target, a runbook reference naming who can actually execute it, and the date on which a drill last observed a real refusal through that binding. If that last element is null, the binding is undefined, and the record attached to it is undefined with it. The premise said tested revocation path; this field turns tested into something a program can check rather than an adjective in a closing report.

One decision inside that last field is why the design is affordable at all. The drill runs against the binding, not against each credential. A binding is a method plus a target: the revocation endpoint of one authorization server, the CRL publication schedule of one issuing CA, the deny path on one cloud account. Four hundred credentials might share nine bindings. Drilling nine on a quarterly cadence is a standing job for one engineer; drilling four hundred is a programme nobody will fund, and a design demanding it would be switched off by the second quarter. The trade is explicit, and its cost appears in the failure analysis below.

The data model

What follows is the core of the reference package, written against generic issuer and directory interfaces because that is the shape of most estates. The strict typing is load-bearing rather than stylistic: every field is required, so a caller cannot construct a partial record and a future contributor cannot add a field without every call site failing to compile — the completeness rule expressed somewhere it cannot be forgotten under delivery pressure. Note also what is computed rather than stored. Whether a record is defined is a function of the record and the current time, evaluated at read, because an owner resolution valid in March is not valid in September and a stored boolean would say otherwise.

// @authority/nhi — the unit of record for an agent principal in a supervised estate.
//
// Every property is required. That is the design decision, not an accident of style: a total
// type means no caller can construct a partial record, and no future contributor can add a
// field without every call site failing to compile.

declare const brand: unique symbol;
type Brand<T, B extends string> = T & { readonly [brand]: B };

export type PrincipalId = Brand<string, "PrincipalId">;
export type BindingId = Brand<string, "BindingId">;
export type DirectoryId = Brand<string, "DirectoryId">;
export type UnixSeconds = Brand<number, "UnixSeconds">;

/** Which system minted it, carrying what the runbook will need to reach revocation. */
export type IssuerRef =
  | { readonly kind: "oauth-as"; readonly issuer: string; readonly revocationEndpoint: string }
  | {
      readonly kind: "x509-ca";
      readonly caSubject: string;
      readonly crlDistributionPoint: string;
      /** null where the CA publishes no responder — then the CRL issue period is the only bound. */
      readonly ocspResponder: string | null;
    }
  | { readonly kind: "cloud-iam"; readonly provider: "aws" | "azure" | "gcp"; readonly accountScope: string }
  | { readonly kind: "workload-api"; readonly trustDomain: string };

/** The class matters because revocation semantics differ per class and are not interchangeable. */
export type CredentialMaterial =
  | { readonly class: "oauth-client"; readonly clientId: string; readonly refreshTokenIssued: boolean }
  | { readonly class: "x509"; readonly serial: string }
  | { readonly class: "static-secret"; readonly store: string; readonly path: string }
  | { readonly class: "cloud-role"; readonly resourceId: string };

/** Three shapes are real. The third is representable so it can be classified, not hidden. */
export type Expiry =
  | { readonly mode: "expires"; readonly notAfter: UnixSeconds }
  | { readonly mode: "rotates"; readonly intervalSeconds: number; readonly lastRotated: UnixSeconds }
  | { readonly mode: "none"; readonly justification: string; readonly approvedBy: DirectoryId };

/** A directory principal, re-resolved on a schedule. A group is not representable. */
export type Owner = {
  readonly directoryId: DirectoryId;
  readonly kind: "named-individual";
  readonly resolvedAt: UnixSeconds;
  /** Past this moment the record is undefined until re-resolution succeeds. */
  readonly resolutionValidUntil: UnixSeconds;
};

/** Purpose as a reference into taxonomies the institution already maintains. */
export type Purpose = {
  readonly actionClass: string;
  readonly businessService: string;
  /** The change record or product approval that caused the credential to exist. */
  readonly authorisingRecord: string;
};

/** A method plus a target. Many credentials share one binding; the drill runs here. */
export type RevocationBinding = {
  readonly id: BindingId;
  readonly method: "oauth-revoke" | "crl" | "ocsp" | "iam-deny" | "secret-delete";
  readonly target: string;
  /** Names who can actually execute it, not a link to a wiki index page. */
  readonly runbook: string;
  /** null until a drill has observed a real refusal at a real resource server. */
  readonly lastObservedRefusal: {
    readonly at: UnixSeconds;
    readonly observedIntervalSeconds: number;
    readonly resourceServer: string;
  } | null;
};

export type AgentPrincipalRecord = {
  readonly principalId: PrincipalId;
  readonly displayName: string;
  readonly issuer: IssuerRef;
  /** The institution's own resolution rule, stored as data because no standard supplies one. */
  readonly principalResolution: { readonly rule: string; readonly resolvesAt: UnixSeconds; readonly resolved: boolean };
  readonly material: CredentialMaterial;
  readonly owner: Owner;
  readonly purpose: Purpose;
  readonly expiry: Expiry;
  readonly binding: RevocationBinding;
};

export type MissingField =
  | "owner-resolution-stale"
  | "principal-unresolved"
  | "purpose-authorising-record"
  | "expiry-none-unjustified"
  | "revocation-never-drilled"
  | "revocation-drill-stale";

export type Classification =
  | { readonly state: "defined" }
  | { readonly state: "undefined"; readonly missing: readonly MissingField[] };

export type ClassifyPolicy = {
  /** How old an observed refusal may be before the binding stops counting as tested. */
  readonly drillMaxAgeSeconds: number;
};

/**
 * Computed at read time, never stored. An owner resolution valid in March is not valid in
 * September, and a stored boolean would claim otherwise.
 */
export function classify(
  record: AgentPrincipalRecord,
  now: UnixSeconds,
  policy: ClassifyPolicy,
): Classification {
  const missing: MissingField[] = [];

  if (record.owner.resolutionValidUntil <= now) missing.push("owner-resolution-stale");
  if (!record.principalResolution.resolved) missing.push("principal-unresolved");
  if (record.purpose.authorisingRecord.trim() === "") missing.push("purpose-authorising-record");

  if (record.expiry.mode === "none" && record.expiry.justification.trim() === "") {
    missing.push("expiry-none-unjustified");
  }

  const refusal = record.binding.lastObservedRefusal;
  if (refusal === null) {
    missing.push("revocation-never-drilled");
  } else if (now - refusal.at > policy.drillMaxAgeSeconds) {
    missing.push("revocation-drill-stale");
  }

  return missing.length === 0 ? { state: "defined" } : { state: "undefined", missing };
}

The control path, step by step

Six layers, read from the bottom. Nothing in the path replaces a system the institution already runs, and the only component with a genuinely new behaviour is the one at layer two.

1. Issuance points. The OAuth authorization server, the private certificate authority, cloud identity and access management, the workload identity API. These stay exactly as they are. Any design whose first step is a platform migration will be descoped before it reaches the second business line.
2. Creation hook. A wrapper around each issuance path that constructs the record and refuses to complete issuance when the record would be undefined. The refusal has to be mechanical rather than procedural, because a procedural gate is a checklist item and checklist items are the first thing to go when a delivery date moves. In practice it runs in log-only mode for the first weeks, producing the refusal log without producing an outage.
3. Register. Total records, with defined-or-undefined computed at read. Its output is a population statement: how many principals exist, how many are defined, and for each undefined one, which field is missing and which issuance path created it.
4. Attestation emitter. One line per principal, in the format the pack already consumes, with the third recommendation for undefined records. This is the join, and the reason the design is affordable — the review workflow, the escalation, the evidence retention and the audit trail are inherited rather than rebuilt.
5. Recertification. Unchanged. A named owner certifies, revokes, or is told the row cannot be certified and why. Existing cadence, existing tooling; the only difference is rows in the pack that were not there before.
6. Revocation drill and evidence store. Per binding, on a cadence, producing a dated interval observed at a named resource server. This is the layer that turns the word tested into a number, and the layer most likely to be dropped under pressure — worth saying now that dropping it converts the design back into documentation.

Where this design breaks

A design piece with no honest failure analysis is a brochure. Here is what I can find wrong with my own.

It counts what the hooks can see, and nothing else. A credential minted through a console by an engineer with sufficient privilege, or by a vendor integration nobody routed through the wrapper, does not exist as far as the register is concerned. That is the same limitation afflicting every estimate of how many non-human identities an enterprise has that I have been able to trace back to a named publisher — estimates which get quoted as though they were population counts, when each of the ones below is vendor research derived from that vendor's own discovery telemetry and can only count what its tooling sees. The published spread runs from 17 to 1, reported by Veza in State of Identity and Access 2026, to 144 to 1, reported by Entro Labs for cloud-native and DevOps estates in H1 2025; Palo Alto Networks reports 109 to 1 across 2,930 security leaders in its 2026 Identity Security Landscape, of which 79 of the 109 are AI agents. The spread is the finding, and the publisher-and-population labels are what make it one rather than a contradiction. Each is a lower bound. So is your register, and the only thing that moves it towards a population is coverage of the issuance paths — which is why enumerating the paths matters more than enumerating the credentials.

It inherits attestation fatigue, and may make it worse. Recertification's known failure mode is the owner who approves four hundred rows in ninety seconds because approving is the only action that closes the queue. Adding agent principals adds rows, and if the estate ratio resembles the vendor lower bounds above, it adds a lot of them. The cannot-certify recommendation is at least hard to rubber-stamp, since it does not offer approval as an option — but nothing here fixes a reviewer who does not read. An institution that adopts this and sees its certification rate stay at ninety-nine per cent has not improved a control; it has added rows to a ritual.

The undefined queue can become a parking lane. Undefined is only actionable if something forces closure. Without a service level and an escalation path, cannot-certify becomes the answer everybody gives for rows they do not want to think about, and the pile grows quarter over quarter while the reported certification rate looks healthy. The honest version carries an ageing report on the undefined population as a separate artefact — and the uncomfortable truth is that the ageing report, not the register, is what tells you whether any of this worked.

Expiry is a weak substitute for a departure. A departure is an event generated by a system of record nobody controls for convenience. An expiry is a date somebody chose, and dates chosen under delivery pressure drift towards distant. The design forces the argument to happen at creation and makes the non-expiring case explicit, which is better than nothing — but a field full of expiries five years out is a register that has technically passed every check while supplying no trigger at all. My only defence is reporting the distribution of expiry dates alongside the population, which is a detection, not a prevention.

The drill tests the binding, and credentials can be attached to the wrong one. This is the direct cost of the decision that made the drill affordable. If a record names binding B but the credential is in fact reachable only through binding C, the drill on B passes while that credential survives revocation. Nothing checks that the binding is the right one; the field is an assertion made at creation. The mitigation is a per-class sampling drill — one live credential per class per quarter, drilled individually — which catches misattachment at a bounded cost. I have specified it and have not measured its detection rate, because I have not run it.

The drill cannot see the failure mode it is most worried about. The specifications permit a resource server to accept a revoked credential — a pre-produced OCSP good response replayed before its nextUpdate, an access token validated only for signature and expiry, a CRL that will not be republished until Sunday. The drill polls the resource servers it knows about. One that caches aggressively, or does no revocation check at all, is not in its path unless somebody put it there. So the observed interval is a lower bound on how long the credential stayed usable somewhere, at the servers probed, on that date. It is not a property of the credential and must not be reported as one.

The register is itself a privileged system. It holds a map of every agent principal in the estate, its purpose, its owner, and the runbook for withdrawing its access — an unusually attractive target and an unusually convenient reconnaissance artefact. It also needs credentials of its own at every issuance point in order to write records and run drills, which means the register's own principals are agent principals and must appear in its own population, with the obvious circularity that it cannot be the sole attester for itself. In a Class A company under 23 NYCRR 500.1(d), those credentials belong in the privileged access management solution 500.7(c) already requires.

What it does not cover at all. The estate that existed before the hooks were installed, which is most of it on day one. Principals held by third parties inside their own tenancy, which the institution cannot enumerate and can only contract for. Delegation patterns where the agent acts on a human's token rather than holding its own credential — there the entitlement is the human's, recertification already covers it, and whether that is the right answer is a separate argument. And the non-US derivation entirely: the chain here runs through FFIEC supervised practice and New York law, and I am not asserting what the equivalent binding instruments require in India or the Gulf, because I have not read them for this piece.

What it costs

Three kinds of cost, and it matters which are engineering facts and which are guesses I am declining to make.

Latency, on the issuance path only. The creation hook adds a synchronous validation and a write to every issuance. For the common case that is irrelevant: a credential is minted once at deployment and used many times, so the cost lands on deploys rather than transactions. It stops being irrelevant for short-lived workload identity, where a credential may be minted per task — the SPIFFE specification states that SVIDs are valid for a limited period of time, primarily for the purpose of mitigating the likelihood of a key compromise, and defers actual lifetimes to the format-specific documents. Where lifetimes are short, issuance is on the hot path and the hook's cost matters. I have not measured it. The measurement is planned: hook overhead at the ninety-fifth and ninety-ninth percentiles against an unhooked baseline, on one issuance path, at representative rate. Until that runs, any figure quoted for this is an invention.

Operational burden, which is mostly the drill. The drill needs three things an institution does not automatically have: a credential that can be sacrificed, a resource server willing to be probed, and someone empowered to execute the revocation runbook on demand. Running it in a non-production environment is cheaper and produces materially weaker evidence, because what is being tested is the propagation behaviour of the production issuer and the production resource servers. My working assumption is that a quarterly cadence across single-digit bindings is one engineer's standing job rather than a team's — an estimate from the shape of the work, not from having run it at an institution, and labelled as such.

Review volume, which is the cost nobody budgets. Every agent principal added to the pack is a row a named individual has to decide about, on a cadence, forever. That is the real recurring cost, it falls on the business rather than engineering, and it is therefore the cost most likely to be discovered after approval. It also argues hardest for the purpose field: a row that says which business service a principal serves and which change record authorised it can be decided in seconds, while a row saying only that a service account has a role takes a conversation.

Migration difficulty, which is not where people expect. The register is a week of work. Enumerating the issuance paths is the hard part, and it is hard for an organisational reason rather than a technical one: paths are owned by different teams, some are undocumented, and at least one will turn out to be a person with a console and a legacy exception. The inherited estate is harder still and this design does not address it — stop the population growing before trying to shrink it, because a remediation programme running against a growing denominator never finishes.

Nothing in this section is a measurement. Where a number would be useful I have said that the measurement is planned and named what would be measured, because the alternative — a plausible figure with a specific-sounding horizon attached — is the exact shape of a laundered claim, and an assurance argument that launders a number has forfeited the thing it was arguing for.

What to build in the first week

One week, one engineer, no procurement. The objective is not coverage. It is three artefacts that did not exist on Monday, because real artefacts change a conversation in a way a roadmap does not.

1. Days one and two: enumerate the issuance paths, not the credentials. How many distinct ways can an agent principal come into existence in this estate? Write the list. It will be shorter than anyone expects and at least one entry will be embarrassing. This list, not a credential count, determines whether any subsequent number means anything.
2. Day two: write the record type and the classify function. One file, no persistence, no service. The value is that the argument about what constitutes a principal now has to be settled in a type rather than in a meeting, and it takes an afternoon once it cannot be deferred.
3. Days three and four: wrap the single highest-volume issuance path, in log-only mode. It refuses nothing and records what it would have refused. At the end of day four you have the first artefact: a count of credentials created without a defined record, by path, in a real week.
4. Day four: run one drill, once, against one binding, at one real resource server. Write down the interval. That is the second artefact, and the most persuasive object in the whole design, because nobody in the institution currently has one.
5. Day five: emit one recertification line from one real record into the existing pack format, and put it in front of the actual owner. Their reaction is the third artefact, and it will tell you more than any architecture review — including, quite possibly, that the entitlement summary as specified is unreadable to the person being asked to certify it.

What not to build that week: a discovery crawler, a dashboard, a new privileged access management capability, an ontology of agent types, or a policy document. Each is defensible eventually, and each will consume the week without producing an artefact anyone can read.

The reason to sequence it this way comes back to the sector constraint. When an examination reaches this, the questions will be what the population is, who owns each item in it, and what evidence exists that the access can actually be withdrawn. Those are three artefacts: a population statement split into defined and undefined, a set of signed attestations with named individuals against them, and a dated log of observed refusal intervals per binding. An institution that can produce those three is answering with evidence. An institution that produces an architecture diagram is answering a question nobody asked — and the guidance that would have told it which diagram to draw has been withdrawn without a replacement, which is precisely why the artefacts, and not the framework, are the thing to build.