NHI architecture for identity and platform architects

The credential model

Three facts must be separable at every call, and collapsing any two of them is the source of most downstream governance failure:

1. What the workload is. A stable identifier plus an attested, short-lived credential derived from the runtime. The Kubernetes projected token, the cloud instance identity document, the CI/CD OIDC token. Never a value a human pasted into a config.
2. What authority it carries. If acting for a human, a separate delegation token binding agent identity, human identity, and consented scope. Two facts, two tokens, both logged.
3. Whether it may act now. An authorization decision at the moment of the call, not baked into token issuance.

The classical anti-pattern collapses all three into a long-lived API key that encodes identity, authority, and permission in one opaque string with no expiry. Every property you want (attribution, least privilege, revocation, audit) is unavailable once that collapse has happened.

Migrating off static secrets

The migration is well-trodden and does not require any pending standard:

1. Inventory and classify by runtime. Kubernetes, cloud compute, CI/CD, SaaS integration, on-premise. Each has a native attestation mechanism.
2. Adopt federated identity where the runtime already supports it. Cloud provider OIDC federation from CI/CD, workload identity federation, IRSA-style role assumption. This eliminates a large fraction of static secrets with no new infrastructure.
3. Deploy a workload identity plane for what is left. SPIFFE/SPIRE is the mature option and issues short-lived SVIDs based on runtime attestation.
4. Move remaining secrets into dynamic issuance. A secrets engine that mints per-use database credentials is categorically different from one that stores a static password. Storage is the interim step; dynamic issuance is the target.
5. Bind tokens to keys. DPoP for OAuth, and the WIMSE Workload Proof Token pattern for workload-to-workload HTTP. This is the most under-implemented layer and the one that matters after the first token-theft incident.
6. Shorten lifetimes until something breaks, then fix that thing. The same forcing logic driving 47-day certificates. Short lifetimes surface every process that cannot automate.

Designing for substitutability

Nothing in agent identity is ratified. The correct response is not paralysis and not betting on a favourite; it is keeping three interfaces replaceable:

• Credential format. Consume identity through an abstraction, not by parsing a specific token structure throughout your services. X.509 and JWT-based workload credentials are both in scope in WIMSE, and you should be able to switch.
• Policy decision point. Externalise authorization. Even a crude PDP behind an AuthZEN-shaped interface is more substitutable than scopes hard-coded into issuance.
• Signal transport. Revocation and risk signals should arrive over a replaceable channel. CAEP is the emerging shape; the property that matters is that your enforcement points react to pushed events rather than only to token expiry.

See the agent identity standards map for what sits behind each interface and the standards tracker for current status.

Where agents actually differ

Less than the discourse suggests. An agent is a workload, and layers one and three above are unchanged. What is genuinely new:

• Delegated authority is the normal case, not the exception. Most workloads act for themselves; agents usually act for a person. That makes the delegation token a first-class architectural element rather than an edge case.
• Fan-out. One user request becomes many downstream calls across trust boundaries. Authorization context must propagate, which is the Transaction Tokens problem.
• The action rate breaks expiry-as-revocation. A fifteen-minute token is a fifteen-minute window in which a human does a few things and an agent does thousands. Push-based revocation stops being optional.
• The input channel is adversarial. Prompt injection is an authority-escalation vector with no analogue in classical workload identity. The architectural mitigation is scope, not filtering: an agent that cannot reach a resource cannot be talked into reaching it.

Frequently asked questions

Should we deploy SPIFFE now or wait for WIMSE?

Deploy SPIFFE-shaped workload identity now. WIMSE is entirely at Internet-Draft stage with no RFC and no published timeline, and it is being designed so that SPIFFE deployments are a reachable migration path rather than a dead end. Waiting means running static secrets for an indefinite period in exchange for no benefit.

How do we stop an AI agent mid-action?

Token expiry is not revocation. You need push-based revocation, which is what the Shared Signals Framework and CAEP provide, combined with enforcement points that react to pushed events rather than only checking expiry. The practical starting point is to measure the current time from revocation to confirmed loss of access, because most organisations have never measured it and the number is usually much larger than assumed.

What is the single most important architectural decision for agent identity?

Separating the agent's own identity from the authority it has been delegated. Two facts, two tokens, both logged. Collapsing them, typically by giving an agent a human's credential, makes attribution permanently impossible because downstream logs cannot distinguish agent action from human action after the fact.

How do we protect against prompt injection at the identity layer?

By scope rather than by filtering. Input filtering is a defence in depth measure and will be bypassed. The durable control is that an agent cannot reach resources outside its bounded, per-invocation authority, so a successful injection escalates to nothing. This is an argument for narrow, short-lived, per-task delegation tokens rather than broad standing scopes.