humans                         non-human identities
   joiner -> mover -> leaver      created -> ... -> ?
      |                              |
   HR system drives it            nothing drives it
   revocation is automatic        nobody ever leaves

   the fix is to run ONE protocol over both:

     HR/IdP --SCIM--> POST   /Users     a person joins
                      POST   /Agents    an agent is deployed
                      PATCH  active:false   a leaver, or a retirement

   owner is a $ref to a User, not a string, so the leaver
   event that already exists is the one that retires the agent

Mitigates: T9 Identity Spoofing · T13 Rogue Agents · T3 Privilege Compromise.

Human identities have a lifecycle: someone joins, moves team, leaves, and an HR event drives the change. Non-human identities have none of that. They are created by whoever needed one, owned by nobody in particular, and removed never.

They also outnumber humans, often by a large multiple.

B1.11's rogue agent was admitted because the orchestrator had no notion of an approved agent. The control is a registry, and a registry is only useful if it carries three fields:

A named owner. A person, not a team alias. An identity with no owner cannot be renewed, questioned or revoked, because nobody is accountable for answering.

An expiry. Not for the credential — for the registration. It forces a recurring decision about whether this agent should still exist, which is the only mechanism that removes the ones nobody uses.

An admission binding. The registry entry names the workload identity from B2.2. Admission then checks the presented identity against the registry rather than checking a name the caller supplied.

That last point is what makes it a control rather than a spreadsheet. A registry consulted by name is documentation; a registry consulted by attested identity is an authorization decision.

The registry has to be driven by something, and that something is SCIM

A registry nobody updates decays into the spreadsheet it replaced. Humans do not have this problem, because their lifecycle is already automated by a protocol: SCIM — System for Cross-domain Identity Management, RFC 7643 for the schema and RFC 7644 for the protocol. The HR system creates a user, the identity provider POSTs it to /Users, a leaver event PATCHes {"active": false}, and every downstream application finds out without anybody filing a ticket.

Point the same protocol at agents and three things become true at once:

The joiner-mover-leaver machinery you already run is the machinery that governs agents. No parallel process, no second system of record. Deploying an agent means creating a SCIM resource; retiring it means one PATCH.

The owner is a reference, not a string. owner.$ref points at the SCIM User — so when Sam leaves, Sam's own leaver event is enough to answer "which agents just lost their owner", automatically, on the day it happens rather than at the next audit.

Orphans become a query. GET /Agents?filter=active eq true and owner pr false is a one-line answer to a question that is otherwise a quarter of someone's life.

What is and is not standard here. SCIM's protocol — the endpoints, the filter syntax, PATCH with active: false, the meta block — is RFC 7644 and your IdP already speaks it. A resource type for agents is not in RFC 7643; you declare it as a schema extension under your own URN, exactly as the enterprise extension does for manager. The protocol is standard, the schema is yours, and that split is the whole reason this is cheap to adopt.