An agent is not a user with an odd-looking address

Here is how a machine identity gets created in most organisations.

Somebody needs a service to call an API. They open the identity console, create a user, give it an address like [email protected], set a password nobody will ever type, and exempt it from the multi-factor policy because a service cannot answer a push notification. Then they put the credential in a configuration file, or a secrets manager if the organisation is careful.

It works. Tokens come out. And every downstream question about it is now unanswerable.

The four questions you cannot answer

How many machine identities do we have? You can count the accounts matching a naming convention. Two teams used a different convention. One team used a real person's account because it was faster and the deadline was Friday.

What did the agents do last night? You can filter a log by those same conventions. The filter is a guess with a regular expression in it.

Can we revoke them all? They are not a set. They are users who happen to have similar names, so revoking them all means constructing the list first, by hand, during an incident.

Which rows in this directory are people? Look at four hundred rows and decide one at a time. This one is worth dwelling on, because it is the question an auditor asks, and the answer "we can tell from the address" is not an answer, it is a convention you are trusting with the audit.

Every one of those failures has the same cause. The distinction between a person and a machine was encoded in a string instead of in the model.

Type first, then everything else follows

Give the identity a type. Person, service, device. That is the whole fix, and everything downstream becomes ordinary:

Counting them is a query. Reporting on them is a filter on a column. Revoking them as a set is possible because they are a set. Reading a directory works, because the type is a field and not an inference.

And the interesting part: the authorization model does not need to change. A service account should have functional roles, scopes and resolved entitlements exactly as a person does, and the same inspector should answer the same question about either. The temptation is to build a parallel system for machine identity, and it is a mistake, because then you have two authorization models and a seam between them, and the seam is where the incident happens.

What should differ is the credential, because what a credential should be depends on what is holding it. A person gets a session and factors. A service that lives on infrastructure you control should get a certificate. A device where a certificate is impractical gets a key with a lifecycle. An agent acting on behalf of a caller should get a token that names who it may present itself to, checked when it is minted and again at the edge.

The part everybody skips

There is a harder problem underneath, and almost nobody has a mechanism for it.

Agents need elevation, briefly. An incident-response agent needs a grant it should not hold for the rest of the year. Ask how that is handled today and the answer is nearly always the same: a permanent grant on a service account, with a comment in a configuration file explaining that it is temporary. The comment is the mechanism. Every organisation running agents at any scale has a collection of those, and none of them has an inventory of it.

The grant should belong to the work, not to the identity. Bind the role to the task, carry it on a token with its own audience and its own expiry, and the elevation is a thing with edges: it starts when the work starts, it is visible while it exists, and it stops being interesting when the token dies. Nobody finds it eighteen months later in an access review, unable to establish why it is there, because there is nothing left to find.

That is the difference between an elevation you can account for and an elevation you have merely written down.

Why this matters more every quarter

The volume argument is the one that gets attention, and it is real: in any working estate, machine token issuance passes human sign-ins well before anybody decides to govern it. People authenticate during working hours. Scheduled agents and service accounts do not stop, and they do not go home.

But volume is not the reason to fix the model. The reason is that identity systems are how you answer questions afterwards, and a system that cannot tell a person from a process can answer almost nothing afterwards. You will find out which questions those are at the least convenient moment, from somebody with a clipboard or somebody with a breach report.

Make it a type. The rest is straightforward.