Your access recertification covers people. Most of your principals are not people.

The institution described in the opening section, and referred to throughout, is a constructed illustration assembled from publicly documented mechanisms and from the plain text of the instruments cited below. It is not a client system, it is not an incident report, and no part of it describes work done for any organisation. Where a failure is illustrated rather than sourced, the text says so at that point. No number in the illustration is presented as a measurement.

The campaign

The quarterly campaign opens on the first working day after quarter end. The population comes out of the joiners-movers-leavers feed, which is anchored on employment status in the human-resources system of record, so the set is knowable and, importantly, it closes: every identity in it belongs to somebody who is on the payroll today, and every identity that stopped belonging to somebody on the payroll has already been picked up by the leaver rule. Entitlements are grouped by application. Each group is routed to the line manager the directory already records, or to an application owner where the manager is not the right person to ask. The reviewer sees a name, a role, a set of entitlements, and a prompt requiring an explicit decision. The decision is signed. The record is retained.

By the end of the window the completion rate is somewhere in the high nineties, and the residue is chased by a governance team that has done this every quarter for eleven years. Revocations from the campaign are pushed into the provisioning system and confirmed. Exceptions are escalated with a written rationale and an accepted-risk owner. When an examiner or an internal auditor samples the campaign, they pull forty entitlements at random, and for each one the institution can show who held it, who approved it, on what date, on the basis of what role, and what happened to the ones nobody approved. That is a control in the full sense: a population, a decision-maker, a decision, and an artefact that survives the people who made it.

In the same institution, in a different part of the organisational chart, there is a second population. It is not in the campaign. Service accounts in the directory sit in a spreadsheet maintained by an infrastructure team, reviewed annually or on change. Workload identities minted by the container platform live in the platform's own control plane and never appear in the directory at all. Certificates are tracked in a certificate-lifecycle tool that knows expiry dates and knows nothing about purpose. Secrets sit in a vault, which is an inventory of objects rather than of principals. Keys issued for a vendor interface live in that vendor's console. Four inventories, four owners, four cadences, and no attestation requirement anywhere in the chain: nobody signs a statement that this principal should hold this access, and no artefact records who decided it should.

The separation is not a scandal. It is what happens when two processes grow up under two sponsors — identity governance and platform engineering — each solving the problem in front of it competently. For twenty years the asymmetry mattered little, because the second population grew slowly and for reasons a change process could see.

Then an agent workflow goes into production. Take the shape of it rather than the specifics: a model with tools, doing something narrow and useful in operations — reconciling breaks, triaging exceptions, assembling a first-pass credit memo. It reads from a case system, writes to a workflow system, calls an internal reference-data service, and logs somewhere. On the day it ships the estate acquires a client credential for the agent runtime, a distinct credential per tool integration because the systems do not federate, a broker identity that mints the short-lived tokens, and a service principal for the scheduler. Whether that is four principals or one depends entirely on what you count, which is the subject of a later section. What is not in dispute is the direction: the first population grew by nobody, and the second grew.

Multiply that by a portfolio of workflows over eight quarters. The campaign still runs. Its completion rate is still in the high nineties. The evidence pack is still clean, and the sample of forty still traces. Everything the institution can demonstrate about access is a demonstration about the population that is not growing, and nothing follows about the population that is.

That is the object of this essay. Not whether agents are risky. Whether the control the institution most believes in still reaches the principals the institution is now creating.

The strongest case for the arrangement as it stands

The case for leaving recertification scoped to people is much better than its critics allow, and it should be put at full strength before anything is said against it.

Attestation is meaningful because there is somebody who can answer. The premise of a recertification decision is that a named human being has knowledge the system does not: what this person does all day, whether the project that justified the entitlement has ended, whether the secondment finished in March. That premise holds for employees and dissolves for workload identities. Asking a line manager to attest that a Kubernetes service account should retain a scoped role in a namespace they have never opened does not produce knowledge. It produces a click. An institution that declines to manufacture that click is making a defensible judgement about what an attestation is for.

Machine principals are, in several respects, better governed than human ones. A workload identity declared in infrastructure code passed through a pull request, a reviewer, a policy check and an audit log before it existed — a provenance trail no human entitlement request can match. It is issued short-lived by construction, rotated without a human touching a secret, never shared over a phone call, never phished, and never given to a contractor for the afternoon. Against a population like that, a quarterly human attestation is not obviously an upgrade. It is a compensating control designed for the absence of exactly the discipline that the platform lane already has.

Scaling attestation to a population an order of magnitude larger destroys it. This is the strongest objection of the four. A campaign that works at fourteen thousand identities does not work at a hundred and forty thousand by running the same thing longer. It works by reviewers spending less time per item, and past a certain density the decision degenerates into approval-by-default. Rubber-stamped attestation is worse than no attestation, because it manufactures durable evidence of a decision that nobody made, and that evidence is precisely what a reviewer will rely on years later. An identity team that refuses to put machine principals into the campaign may be protecting the campaign.

And the control does exist for machines, under other names. Privileged access management covers privileged service accounts; the New York rule requires Class A covered entities — a threshold defined at section 500.1(d), not a synonym for large — to implement such a solution outright. Certificate lifecycle tooling enforces expiry mechanically, which is stronger than an annual review. Secret rotation runs on a schedule nobody can defer. Cloud posture tooling flags over-permissioned roles continuously rather than quarterly. On that account the second population is not ungoverned; it is governed by continuous automated controls rather than by a periodic human ceremony, which for a machine is arguably the right shape.

Every one of those points is correct. None of them answers the objection, because none of them is about the same question. All four are statements about behaviour and hygiene: is this credential likely to be misused, would we notice, is it short-lived, is it rotated. Recertification does not ask any of those questions. It asks a different one, which is a question about authority: who decided that this principal should hold this access, on whose authority, for what purpose, until when — and can the institution produce that decision when somebody asks. Rotation does not answer it. Expiry does not answer it. Posture management does not answer it. A shorter credential lifetime narrows the window in which an unauthorised access can be exercised; it says nothing at all about whether the access was authorised.

The scaling objection deserves a more careful answer than dismissal, because it is right about the arithmetic. But its correct conclusion is not that machine principals should stay outside the perimeter. It is that the unit of attestation cannot be the individual credential. Something coarser has to carry the decision — a workload, a capability, a delegation grant with an owner and an expiry — and the credentials underneath it have to inherit from that decision rather than each demanding one of their own. That is a design claim, and this essay is not the place for it. It is flagged here only so the concession is not mistaken for agreement.

A label without a unit

The reason the second population resists the control is not local to any institution. It is that the object being counted has no agreed definition anywhere, and the published numbers about it are therefore not comparable with each other.

Anybody who has read industry material on machine identity has met the ratio: so many non-human identities for every human user. The figures in circulation span roughly seventeen to one at the low end and a hundred and forty-four to one at the high end. The usual gloss is that estates differ, or that methodologies have different error bars, and that the truth is somewhere in the middle. That gloss is wrong, and the specific way in which it is wrong is the intellectual core of this piece.

These are not estimates of one quantity taken with different instruments. They are measurements of different quantities that happen to share a label. Seventeen to one is published by Veza in its State of Identity and Access 2026. Forty-five to one is Rubrik Zero Labs, in Identity Crisis. Ninety-two to one is Entro Labs, in its non-human identity and secrets risk reporting for the first half of 2024. A hundred and forty-four to one is Entro Labs again, for the first half of 2025 — but drawn from cloud-native and DevOps estates, which is a different population from the one that produced its own earlier figure. A hundred and nine to one comes from Palo Alto Networks in its 2026 Identity Security Landscape, from a survey of 2,930 security leaders, and the publisher states that seventy-nine of those hundred and nine are AI agents rather than conventional service accounts. Averaging those five is not a better estimate of anything. It is a category error with a decimal point.

Two things follow that matter more than the spread itself. The first is that every figure in the series is vendor-published research derived from that vendor's own discovery telemetry, and a discovery product can only count what its collector can see. Each figure is therefore a lower bound on one instrument's field of view, not an estimate of a population. Strip the publisher and the population off any of them and you have converted a bounded observation into a fact about the world, which is the standard laundering path for a number of this kind. Every one of them should travel with its label attached or not travel at all.

The second is a correction this practice has had to make against its own published work. A figure of around eighty to one, frequently cited in this context, does not belong in the series: it measures secrets sprawl in public repositories, which is neither a count of principals nor a ratio against human users. It has been miscredited here before and was corrected. It is set out in the figure above as an excluded row rather than quietly dropped, because the excluded row demonstrates the argument better than the included ones do. When the label is the only thing distinguishing two numbers, the label is doing all the work.

It would be comfortable to treat this as a maturity problem that better tooling will close. It is more accurate to treat it as a definitional gap that the market has an incentive to leave open. Every discovery product defines the unit as whatever its collector observes, and each such definition is internally coherent and honestly described in the vendor's own methodology section. Nothing in the market pushes toward a shared unit, because a shared unit would make products comparable. The gap is stable under commercial pressure, which is one good reason to call it structural.

There is a better reason, and it is that the standards work closest to the problem has the same hole. The SPIFFE identity specification is precise about the identifier: a SPIFFE ID is an RFC 3986 compliant URI comprising a trust domain name and an associated path, the scheme must be spiffe, the trust domain must be non-empty, and query and fragment components are not permitted. On what the path denotes, it says the path component allows for the unique identification of a given workload — and never defines what a workload is. It is similarly careful that the documents carrying these identities are valid for a limited period of time, primarily for the purpose of mitigating the likelihood of a key compromise, while deferring actual lifetimes to the format-specific specifications. The identifier is scoped, structured and time-boxed. The entity it identifies is left to the reader.

That is not a criticism of the specification, which is doing the right thing at its own layer. It is an observation about where the definitional load has come to rest: if the naming standard does not fix the unit and each discovery vendor fixes it differently, the only place left is inside the institution — a schema somebody has to write, own and defend.

The banking regulator has already run into this and left a mark on the record. Where the sector's authentication guidance needed to say what a service account is, it did not define one. It quoted a third-party control framework, attributing the definition in a footnote to the glossary of CIS Controls version 8: 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. A prudential regulator borrowing its definition of the object from an outside catalogue is not an error. It is the clearest available evidence that the sector had no definition of its own to use.

An unenumerable object cannot carry a duty. A campaign requires a closed population, and a closed population requires a predicate that decides membership. For employees the predicate is employment, maintained by a system whose entire purpose is to be authoritative about it. For machine principals there is no such predicate, only five defensible queries that return five different sets. That is why the second population is not merely under-reviewed. It cannot currently be selected.

What a campaign actually does, stage by stage

It is worth being pedantic about the mechanism, because the failure is not diffuse. A recertification campaign is four operations in sequence, and each one fails for a different reason when the principal is not a person.

Stage one selects the population, and there is no unit to select on. The human lane draws from an authoritative feed whose membership question has a single correct answer. The machine lane has no such feed and no such question. An identity team that runs the directory query gets service-account rows and misses everything the container platform minted. A platform team that enumerates workload identities misses the static keys pasted into a configuration file in 2021. A security team that pulls the vault gets objects rather than principals, so one identity holding four secrets contributes four and one secret shared by four systems contributes one. A network team that counts credentials observed in traffic during a window structurally excludes the dormant ones, which are the credentials most likely to matter. None of those four teams is wrong. There are four right answers, which is the same as none.

Stage two assigns an approver, and the owner field is optional. In every schema that commonly holds these principals — directory objects, cloud roles, vault paths, certificate records — an owner is a nice-to-have attribute, populated at creation by whoever remembered, and never validated against a live human afterwards. When the creator leaves, the field does not become empty; it becomes wrong, which is worse, because a wrong owner passes a completeness check. The campaign cannot route what it cannot address, and a routing failure at stage two is silent: the item does not appear on anybody's queue, so nobody reports that it was missed.

Stage three attests, and the parallel process has no attestation step at all. This is the crux, and it is the part most often misdescribed as a coverage gap. The separate machine process is not a lower-quality recertification. It is a different activity: an inventory review, or a rotation check, or an expiry sweep. Those produce hygiene, not authority. They can tell you that a credential is fresh and scoped; they cannot tell you that anybody with standing ever decided it should exist. There is no signature, because nothing in the design asked for one, and consequently there is no artefact for a reviewer to read.

Stage four revokes what was not attested, and there is no trigger and no proof. For people, revocation has an unambiguous trigger — the departure — and a verifiable effect: the account is disabled, and the person is not in the building to contradict it. A service account never resigns. Nothing in the estate generates the event that would start the clock. And when revocation is finally attempted, the effect it produces is bounded by protocol semantics rather than by intent, which is a large enough problem to take on its own.

Run the constructed illustration through those four stages, because the abstraction hides how ordinary the failure looks from inside. The workflow ships in March. Platform engineering creates the runtime identity through infrastructure code, with a merge request, a reviewer and an audit trail — a better provenance record than any human entitlement in the campaign. Three tool integrations follow. Two reuse existing service accounts, which already have the read scopes the workflow needs; both reuses are recorded in the change ticket and neither is recorded against the accounts themselves. The third needs a credential in a vendor system that federates with nothing, so a key is issued from that vendor's console by an engineer who is, at that moment, the only person who knows it exists. The broker mints short-lived tokens for the model runtime — the most modern part of the arrangement, and the part that appears in the fewest inventories.

In June the workflow is extended to a second business line. Scopes widen. Nobody reopens the March change ticket. In September the engineer who issued the vendor key moves to another team inside the same institution, so no leaver rule fires — the departure trigger is scoped to leaving the firm, and this was a transfer. In December the campaign runs, hits the high nineties, produces a clean evidence pack, and touches none of it. The following March an internal auditor asks a reasonable question: for the entitlements this workflow exercises, who approved them and when. The two reused accounts are discoverable from a change ticket if somebody remembers the ticket number; the vendor key from the vendor console if somebody remembers the vendor; the broker identity from the platform. What does not exist anywhere is a decision — a record of a person with authority deciding that this workflow should hold this access until a stated date. Every step was performed competently by somebody following the process that governed their own lane.

/** The five bases on which a machine-identity population is commonly counted. Each is
 *  defensible on its own terms; no two of them count the same object. */
export type CountingBasis =
  | "directory-service-account-rows"
  | "platform-minted-workload-identities"
  | "secrets-stored-in-a-vault"
  | "credentials-observed-in-traffic"
  | "credentials-ever-issued";

export interface PopulationCount {
  readonly basis: CountingBasis;
  /** Who counted, and over what. Stripping either field is how a bounded observation
   *  becomes a fact about the world. */
  readonly publisher: string;
  readonly scope: string;
  readonly total: number;
  /** Discovery telemetry sees what its collector reaches. Every such figure is a floor. */
  readonly isLowerBound: true;
}

/** Two counts are comparable only if they share a basis AND a scope. */
export const comparable = (a: PopulationCount, b: PopulationCount): boolean =>
  a.basis === b.basis && a.scope === b.scope;

/** Summing across bases double-counts and under-counts simultaneously: one identity
 *  holding four secrets contributes four to the vault basis; one secret shared by four
 *  systems contributes one. There is no coefficient that reconciles them. */
export function totalPrincipals(counts: readonly PopulationCount[]): number {
  const bases = new Set(counts.map((c) => c.basis));
  if (bases.size > 1) {
    throw new Error(
      "Refusing to sum counts taken on " +
        bases.size +
        " different bases: " +
        [...bases].join(", ") +
        ". These are different quantities sharing a label.",
    );
  }
  return counts.reduce((n, c) => n + c.total, 0);
}

The revocation you cannot evidence

Suppose the first three stages were solved: a unit exists, an owner is named, an attestation is signed. Stage four would still not close, because the specifications that govern how a credential is withdrawn bound propagation rather than effect, and they say so in their own text.

For anything carrying an X.509 identity — which is most workload identity in a bank, whether or not the people running the workloads think of it that way — the granularity of revocation is the publication cadence of the revocation list.

One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until all currently issued CRLs are scheduled to be updated -- this may be up to one hour, one day, or one week depending on the frequency that CRLs are issued.

The online status protocol was designed to narrow that window, and it does, but it does not close it. It permits responders to serve pre-produced responses, and its own Security Considerations state the consequence plainly: the use of precomputed responses allows replay attacks in which an old good response is replayed prior to its expiration date but after the certificate has been revoked. The mitigation a client is offered — that responses whose nextUpdate value is earlier than local system time should be considered unreliable — carries a SHOULD, not a MUST. A conforming implementation may therefore continue to accept a revoked agent credential for the life of a cached or pre-signed affirmative response, and it is conforming while it does so.

For token-based identity the position is analogous and, in one respect, weaker, because the cascade that most people assume is a requirement is not one.

In practice, there could be a propagation delay, for example, in which some servers know about the invalidation while others do not... If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens based on the same authorization grant.

Two conditionals sit in front of that recommendation: the token must be a refresh token, and the server must support access-token revocation at all. Section 3 completes the picture for self-contained tokens, noting that where immediate revocation is desired, some currently non-standardised backend interaction between the authorization server and the resource server may be used — and offering short token lifetimes as the alternative design, which is a mitigation of exposure rather than a mechanism of withdrawal.

Now consider what that does to an attestation. In the human lane, a revocation is evidenced by the disabled account and by the absence of the person. In the machine lane, the artefact produced is an acknowledgement, and an acknowledgement is not evidence of effect. An institution that added machine principals to its campaign tomorrow, without changing anything else, would generate attestation records at stage three and receipts at stage four, and would have produced a control whose final step it cannot demonstrate. That is a worse outcome than the current arrangement, and it is the reason this essay does not recommend simply widening the campaign's scope.

One thing must be said about the limits of this section, because the shape of the claim invites exaggeration. The specifications establish that the failure mode is permitted; they do not establish how often it occurs. I could find no primary publication that measures revocation propagation latency in production systems, or the rate at which a revocation silently fails to take effect. That is a genuinely open research question, and stating it as unmeasured is a stronger position than borrowing a number for it would be. What can be said without a measurement is narrower and sufficient: an institution cannot today produce, from standard mechanisms, an artefact demonstrating that a specific machine credential stopped being accepted at a specific time.

Two exclusions and the space between them

The instrument that a banking audience would expect to specify controls for this — model risk management — was revised on 17 April 2026, and the revision moved in the opposite direction from the one most commentary assumed.

The mechanics first, because they are frequently stated loosely. OCC Bulletin 2026-13, Model Risk Management: Revised Guidance, rescinds four OCC issuances: the Model Risk Management booklet of the Comptroller's Handbook; OCC Bulletin 1997-24 on credit scoring models, including its appendix; OCC Bulletin 2011-12, Sound Practices for Model Risk Management; and OCC Bulletin 2021-19 on model risk management in the BSA and anti-money-laundering context. Separately, Federal Reserve SR 26-2 supersedes the Federal Reserve's own designations, SR 11-7 and SR 21-8 — SR 11-7 is not among the OCC rescissions because it was never an OCC issuance, and from here on it should be cited only as superseded. The Federal Reserve letter states that it is expected to be most relevant to banking organizations with over 30 billion dollars in total assets regulated by the Federal Reserve.

The substance sits in the attachment to that letter: an interagency document, Supervisory Guidance on Model Risk Management, issued jointly by the Board of Governors, the Federal Deposit Insurance Corporation and the Office of the Comptroller of the Currency. Its footnote 3 is the passage everybody quotes, and almost everybody quotes it half-length.

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 first two sentences are read as an exemption and circulated as one. The third sentence is the one that decides the question, and it says the opposite: where a tool is not covered by the guidance, the banking organisation's own risk management and governance practices are what determine the appropriate governance and controls for it. The agencies did not withdraw the duty. They declined to specify it and returned the determination to the institution. That is a deferral, and it is written in their words rather than inferred from silence.

A second exclusion runs alongside the first, and it is less discussed because it is not in a footnote. The guidance defines its own subject.

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.

Read those two exclusions against the thing actually deployed. The model at the centre of an agent workflow is carved out by footnote 3. Everything around it — the tool router, the policy engine, the credential broker, the retry and fallback logic, the queue that holds the work — is deterministic rule-based software with no statistical, economic or financial theory underpinning its design, and is therefore not a model under the definition. The machinery that decides which credential is presented to which system, on whose behalf, is excluded by the definition; the component whose output triggers that decision is excluded by the footnote. The agent stack falls between the two.

The non-enforceability sentence is usually quoted at half length as well, and the omitted clause is the stronger one.

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.

The first clause is a familiar formula about the status of guidance. The second is a specific statement about supervisory consequence, and it is what makes the situation genuinely unusual: the framework that would have told an institution what good looks like has been withdrawn, and the successor expressly declines to be the thing anyone is measured against.

What is coming next is also frequently overstated, including in this practice's own earlier drafts. The OCC's transmittal notes 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. That sentence appears in the transmittal bulletin and not in the interagency guidance itself; a full-text extraction of the twelve-page attachment returns no occurrence of the phrase. And a request for information is a consultation step. It is not draft guidance and it is not a rule. The correct reading is not that separate AI guidance has been promised — it is that the agencies have not begun writing a specification, they have begun asking what should be in it. That places the eventual specification further away, not nearer.

A sharper version of this point is worth stating against my own argument. Even in full application to generative and agentic systems, the guidance would have governed the model — its development, validation, monitoring and use. Model risk management was never the instrument that would have covered credentials and principals. So this section does not establish that a hole has opened in the control that would otherwise have caught the recertification gap. It establishes something narrower and more useful: the instrument everyone is waiting for has stepped back and pointed at the institution's own governance, while the instrument that does cover this — access management — is already in place and written around employment. No forthcoming document will close the gap. There is only the campaign the institution already runs, aimed at the wrong population.

What the field already knows near this

None of this requires new law, and it is worth being precise about how much of it is already written down, because the usual objection at this point is that regulators have not asked for any of it.

Banking supervision already classes machines as users. The FFIEC's authentication guidance, issued on behalf of the Council and transmitted to national banks by the OCC, sets out practices for the authentication of users accessing financial institution information systems — and enumerates those users as employees, board members, third parties, service accounts, applications, and devices, collectively users. Its risk-assessment section is directive about enumeration: 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 predates the agent question entirely and does not depend on the 2026 model-risk guidance in any way.

But the same guidance never addresses withdrawal. Across the full eighteen pages of that document, the string revok does not appear, and neither does terminat. Disabl appears six times, and not one of the six concerns 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. I confirmed this by regular expression over the locally extracted full text rather than by reading a summary, and I state the method because a negative finding is only worth as much as the search behind it. The sector's principal authentication guidance tells institutions to identify and authenticate service accounts, and never tells them how or when to take their access away.

Two of the missing fields are already legally mandated in New York. Section 500.13(a) of 23 NYCRR Part 500 requires covered entities to maintain a complete, accurate and documented asset inventory, and specifies what must be tracked for each asset: owner; location; classification or sensitivity; support expiration date; and recovery time objectives — together with the frequency required to update and validate the inventory. Owner and expiry, the two fields whose optionality breaks stages two and four of the campaign, are not aspirations in this jurisdiction. They are required tracked fields, with a compliance date of 1 November 2025 under the transitional provisions of the Second Amendment.

And the access rule shows the gap in its own verbs. Section 500.7(a) requires covered entities to limit the number of privileged accounts and their access functions to only what is necessary to perform the user's job; to limit their use to only when performing functions requiring such access; to review all user access privileges periodically and at least annually, removing or disabling accounts and access no longer necessary; and to promptly terminate access following departures. The trigger in that last limb is a departure, which has no analogue for a service account. Section 500.7(c) additionally requires Class A companies to implement a privileged access management solution — Class A being defined at section 500.1(d) by at least twenty million dollars of gross annual revenue in each of the last two fiscal years from the covered entity's operations and its affiliates' New York operations, together with over two thousand employees averaged over the same period including affiliates wherever located, or the alternative revenue limb. Compliance with section 500.7 fell on 1 May 2025.

Put those four together and the position is not that the sector lacks instruments. It is that the instruments name the population and the fields, and the operating process was built around the one trigger that machines do not generate. A firm subject to the New York rule is already required to know the owner and the expiry of its assets and already required to review privileged access at least annually. What it is not required to do — by any text I can find — is attest to a machine principal in the way it attests to a person, with a named approver and a retained decision. That is the space this essay is pointing at, and it is a design space rather than a legislative one.

The mechanism travels beyond the United States even where the citations do not. An institution in Mumbai or Riyadh running the same quarterly campaign has the same two populations, the same missing unit and the same absent trigger; what differs is the instrument under which it answers for them, and I do not cite instruments here that I have not read in the original. The argument for building the evidence layer does not rest on any one supervisor's text. It rests on the fact that the second population is growing and the control is not following it.

The limits of this argument

A teardown that cannot say what would falsify it is advocacy. Five things would damage this one, in descending order of how much.

1. If agent deployments predominantly reuse existing service accounts rather than creating new principals, the population claim weakens considerably. I have no measurement either way, and the illustration above deliberately includes both patterns. Reuse does not make the problem better — two workflows and a legacy batch job then share one principal and the logs cannot separate them — but it would mean the argument belongs to attribution rather than to population growth.
2. If institutions already run attestation over machine principals under another name, at equivalent rigour, the gap is nominal rather than real. The test is specific and takes an afternoon: take ten machine principals holding production access and, for each, produce the name of the person who approved it, the date, and the stated expiry. If those artefacts exist, this essay does not describe your institution. I could find no published evidence either way, and would rather say so than assume the answer that suits the argument.
3. The revocation claims are bounded to what conforming implementations are permitted to do, not to what deployed systems actually do. No primary publication measures propagation latency or silent-failure rates. If someone publishes that measurement and it turns out to be small in practice, the section on stage four weakens to a theoretical concern — though the absence of an evidence artefact would remain, because that is a property of the specifications rather than of any implementation's speed.
4. Every ratio in the third section is vendor discovery telemetry. If an independent enumeration under a fixed unit found the real ratio to be close to one to one in a typical bank, the framing of the whole piece would be wrong. I judge that unlikely, but I have no non-vendor measurement to offer against it, which is exactly why the essay argues from the incomparability of the figures rather than from their magnitude.
5. Jurisdiction bounds the citations. The New York rule binds covered entities in New York. The Federal Reserve letter states that it is expected to be most relevant to organisations over thirty billion dollars in total assets regulated by the Federal Reserve. A smaller institution, or one supervised elsewhere, inherits the mechanism but not the specific obligations quoted here, and should not be told otherwise.

One further limit, of a different kind. Nothing in this essay claims that any institution has been harmed by this gap. No incident is cited because none is claimed, and the illustration is marked as constructed for that reason. The argument is about examinability, not about damage: an institution can be entirely unharmed and still unable to answer the question. In a sector where the answer is expected to survive years of retention and a hostile reader, being unable to answer is itself the finding.

Where this goes, and where it stops

It should now be possible to state the requirement without designing to it, which is the discipline this piece has been observing throughout.

Whatever closes this gap has to do four things, one for each stage that currently fails. It has to fix a unit coarse enough to be attestable and precise enough to be enumerable, which almost certainly means the unit is not the credential. It has to make the owner a required, validated field rather than an optional string, which the New York rule already anticipates. It has to produce an attestation record carrying the grant, the authority, the scope and the expiry, not merely a tick. And it has to make revocation evidenced rather than acknowledged — the genuinely hard one, which probably has to be solved at the point of issuance rather than by improving the withdrawal path.

Those are requirements, not architecture. Turning them into a mechanism that a bank could actually operate — the schema, the broker, the delegation record, the campaign that runs over workloads rather than over secrets, and the evidence artefact that comes out of the far end — is the subject of the companion piece, Bringing agent credentials inside the recertification perimeter, which is forthcoming. Deliberately, it is a separate essay. A teardown that solves its own problem in the last section tends to solve it too quickly, and the reader ends up with a diagnosis they have not had time to check and a design they have not had time to doubt.

What is worth carrying out of this one is narrow. The institution is not missing a control. It has a mature, examinable, well-run access recertification that does exactly what it was built to do. The population it was built for stopped being the whole population some time ago, and the part that is growing is the part with no unit, no owner, no attestation and no trigger. Everything else in this essay is an elaboration of that sentence.