Agent identity

Every agent call carries three identities, and a system that models only one of them will get an authorisation question wrong sooner or later. There is the human, who asked for the work and whose own access ought to bound it. There is the workload — the container, pod or function the code is executing in — which is what an infrastructure platform can attest to. And there is the agent: the durable logical actor with a name, an owner, a purpose and a permission set, which outlives any particular pod and is not the same thing as the person. The agent is the unit governance is scoped to, because it is the only one of the three that has a purpose you can compare behaviour against.

The credential half of an agent identity takes one of three shapes in practice. An opaque high-entropy bearer token, presented in an Authorization header. An OIDC or OAuth 2.1 client-credentials JWT, short-lived and issued by a directory. Or a certificate or signed identity document bound to a workload, in the SPIFFE style. What almost every estate actually runs is the first, for a dull reason worth being honest about: mainstream agent frameworks and SDKs authenticate by putting a string in a header, so anything stronger requires code changes inside the customer’s agent rather than a change of base URL and key. The difference between a config edit and a project decides what gets adopted.

The consequence of a bearer credential should be stated plainly rather than designed around quietly. There is no cryptographic binding to a workload, so any process holding the string is the agent. A leaked token is valid until somebody revokes it. Rotation is a manual administrative act, which means it is rare, which means long-lived credentials accumulate — precisely the standing-privilege pattern that agent governance exists to reduce. What follows from that is not that bearer tokens are unusable, but that the permission set becomes the load-bearing control: whatever the token can reach is whatever the roles name.

Storage and lifecycle are where a bearer identity is either defensible or not. The plaintext should exist exactly once, in the response to the create call; the store should hold a SHA-256 digest and a short display prefix, look the credential up by digest, and compare in constant time so that a store which ever answered a prefix match cannot be turned into a byte-at-a-time oracle. Expiry, revocation and a last-used timestamp are not conveniences: revocation is the whole of the incident response, a dormant key is a finding, and an identity whose revocation takes effect at the next deployment rather than the next call is not revocable.

The record half matters as much as the credential, because an identity that resolves to nothing but a name authorises nothing useful. What makes an agent identity governable is the set of fields the enforcement path actually reads on every call: a named human owner rather than a team alias, so that accountability for a non-human has somewhere to land; a declared purpose, so behaviour has something to be compared against; a lifecycle status, so suspension is a state rather than a deployment; role grants, budgets and data-handling requirements. Three failure modes recur. One credential shared across several agents destroys both attribution and per-agent revocation. An identity minted per deployment rather than per agent scatters an agent’s history across records nobody joins. And an agent configured with a human’s own provider API key inherits everything that person can do, permanently, while the provider’s records say the person did it.