NHI architecture for identity and platform architects

The credential model

Three facts must be separable at every call, and in our view collapsing any two of them is a common source of 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 or EKS Pod Identity on Amazon EKS. This can remove many static secrets with no new infrastructure.
3. Deploy a workload identity plane for what is left. SPIFFE and SPIRE are CNCF graduated projects; SPIRE issues short-lived SVIDs based on workload 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 (RFC 9449) for OAuth, and the pattern in the WIMSE Workload Proof Token draft for workload-to-workload HTTP. The WIMSE document is an Internet-Draft, not an RFC. In our view this layer gets too little attention, and it matters after a 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

No agent-specific identity standard is final yet, although some building blocks are (see below). 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 over the Shared Signals Framework is the standardised shape (both were approved as OpenID final specifications in September 2025); 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. Many workloads act for themselves; agents often 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 problem the OAuth Transaction Tokens draft addresses (an Internet-Draft, not an RFC).
• 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 that, in our view, has no close 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?

Our advice is to deploy SPIFFE-shaped workload identity now. No WIMSE document is an RFC yet; one informational document was submitted to the IESG in September 2026. The WIMSE architecture draft cites the SPIFFE ID as an example of a conforming workload identifier, so in our reading a SPIFFE deployment is not a dead end. Waiting means running static secrets for an indefinite period.

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 a number that has not been measured cannot be relied on.

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 can 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.

Companies working on this: NHI governance and security, Identity governance platforms, AI agent security and governance. Each category lists sourced company profiles in alphabetical order; it is not a ranking. All categories: NHI market map.