An identity model for non-human actors: DIDs, VCs and the backing human

Most automations in production today authenticate the same way: a long-lived API key, copied into a node, shared by whoever needs it. That is not an identity. It is a password with no name attached — and it is the reason nobody can answer who authorised an action after the fact.

Why a key is not an identity

A credential worth the name answers four things: who this actor is, what it is allowed to do, who vouches for it, and whether that is still true right now. An API key answers none of them. It cannot be verified by a third party without asking the system that issued it, it carries no scope beyond whatever the target platform assumes, and it has no expiry that anybody tracks.

DIDs and Verifiable Credentials, briefly

A W3C Decentralised Identifier is a stable name bound to a public key. A Verifiable Credential is a signed statement about the holder of that identifier — issued by someone, scoped, dated and revocable. The property that matters here is offline verifiability: a receiving system can check the signature without trusting the automation presenting it, and without a round trip to us.

The field that changes the conversation: backed_by

Every credential should name a person. Not a team, not a mailbox, not “IT” — a person, who can be asked why this automation exists and who inherits the obligation when it misbehaves. This is not a philosophical preference: it is what makes an audit trail attributable, and attribution is what the frameworks in force are actually asking for.

An automation with no backing human is an obligation with no address.

It also gives offboarding a meaning it currently lacks. When someone leaves, their user account gets disabled and their automations keep running on a service credential nobody reviews. With a named backer, departure raises a question that has to be answered: who takes this over, or does it stop?

What to do without rebuilding anything

• →Give every automation in the inventory a named owner before you give it a credential.
• →Scope credentials to the action, not to the platform: “create payment up to €5,000 for approved vendors”, not “full API access”.
• →Rotate automatically and make revocation global — one place, seconds, not a ticket per platform.
• →Federate with the identity provider you already run (Okta, Entra ID, Google Workspace) so the backing human is a real, current employee.

None of this requires rewriting the automation. The identity sits in front of it, in the authorization request — which is also where the policy decision belongs.