Non-Human Identity: provisioning for the machine and agent era
A target architecture that replaces distributed secrets with attested, ephemeral, cryptographically verifiable identity — and a governance model that treats every workload, pipeline, bot and AI agent as a first-class identity with an owner, a lifespan and a purpose.
Thesis
One idea carries the whole strategy
Stop provisioning secrets to workloads. Start provisioning identity to workloads, and let secrets — where they are still unavoidable — be a short-lived consequence of identity rather than the basis of it.
Almost every non-human identity problem an enterprise has is downstream of a single design decision made decades ago: we authenticate machines the way we authenticate people. We issue a shared string, we copy it to wherever it is needed, and we hope it does not escape. Everything else — vaults, rotation schedules, secret scanners, credential-leak monitoring — is compensating machinery built around that original mistake.
Machines do not need this. Unlike a human, a workload can prove what it is to its runtime environment: which orchestrator scheduled it, which image it was built from, which node it runs on, which pipeline deployed it, which hardware root of trust vouches for the platform. That proof — attestation — can be exchanged for a short-lived, audience-bound, cryptographically verifiable credential that never persists, never gets copied, and cannot be replayed elsewhere.
Once identity is attested rather than distributed, most of the traditional NHI control set becomes unnecessary rather than automated. You do not rotate what expires in five minutes. You do not scan repositories for a credential that was never issued to a file. You do not chase offboarding for an identity that ceases to exist when the workload does.
The second figure is the important one. A secret that leaked four years ago and still works is not a rotation failure — it is evidence that nobody knew the identity existed, who owned it, or what it was for. That is a governance problem wearing a cryptography costume, and no amount of vaulting fixes it.
What this document is
A target-state design and the reasoning behind it: a taxonomy, a set of principles, a reference architecture, a decision model for choosing credential types, a lifecycle and governance model, and an assessment of the tooling landscape. It deliberately contains no delivery plan, sequencing or effort estimate. Those are downstream of agreeing the destination, and mixing them in tends to collapse the architectural conversation into a scheduling one.
01 — Framing
What counts as a non-human identity
Most NHI programmes fail at the definition stage. They scope to "service accounts", build a vault, and discover two years later that the majority of their machine credentials were never in scope: OAuth tokens granted to SaaS integrations, CI/CD pipeline identities, certificates, cloud roles, RPA logins, and now AI agents. A strategy needs a taxonomy broad enough to be honest and structured enough to be actionable.
A programme scoped to "service accounts" typically captures Class E and a fraction of C — perhaps 15% of the real population, and the least dynamic 15% at that. Classes B, D and F are where the growth and the incidents are. If the taxonomy above cannot be mapped onto your existing inventory, that gap is the first finding.
02 — Framing
Why the conventional model fails
The conventional model — inventory the accounts, vault the secrets, rotate on a schedule, review annually — is not wrong so much as structurally unable to keep up. It has four failure mechanics, and they compound.
1 · Creation outruns governance
Any engineer can mint an NHI in seconds — a cloud role, a PAT, an OAuth grant, a pipeline secret — while onboarding it to governance takes days and a form. The gap is not a discipline problem; it is a gradient, and identities flow down it. Population growth is exponential; governance capacity is linear.
2 · Secrets copy, identities don't
A secret's defining property is that it works wherever it is presented. So it spreads — into config, CI variables, container images, wikis, tickets, laptops, chat. You can never enumerate all copies, which means you can never be sure rotation was complete or that a leak was contained.
3 · Nobody owns them
Human identities have an obvious owner: the human. NHIs are created by someone who then changes team, and the identity persists with no accountable party. Ownership decays silently, and the absence of an owner is precisely why nothing gets offboarded — OWASP's number-one NHI risk.
4 · Rotation is a treadmill, not a control
Rotation reduces the window of a compromise, not its probability. It is expensive, breaks things, and creates its own outage risk. A 90-day rotation on a credential that leaked on day 2 gives an attacker 88 days. Expiry measured in minutes is a different control class entirely.
The OWASP NHI Top 10, and what actually resolves each risk
The OWASP Non-Human Identities Top 10 (2025) is the best available shared vocabulary for this domain. What is striking when you map remediations against it is how many of the ten are dissolved rather than mitigated by attestation-based identity — they stop being possible rather than becoming better managed.
| # | Risk | Conventional mitigation | What the target architecture does |
|---|---|---|---|
| 1 | Improper offboarding | Joiner-mover-leaver process, periodic review | Dissolved Identity is bound to workload lifetime. When the pod, function or pipeline run ends, the identity ends. Nothing to offboard. |
| 2 | Secret leakage | Secret scanning, pre-commit hooks, remediation workflow | Dissolved No secret is issued to a file, variable or image. There is nothing to commit. |
| 3 | Vulnerable third-party NHI | Vendor review, periodic reassessment | Mitigated Class D remains a real exposure. Answer is discovery, brokered egress, tight scopes and blast-radius containment — not elimination. |
| 4 | Insecure authentication | Standards policy, exception register | Dissolved mTLS with X.509 SVIDs or signed JWTs by default. Weak mechanisms are unreachable rather than discouraged. |
| 5 | Overprivileged NHI | Periodic entitlement review, least-privilege guidance | Mitigated Requires the authorization model in §8. Ephemeral identity does not fix over-scoping — a short-lived admin token is still admin. |
| 6 | Insecure cloud deployment config | Static keys in CI, or OIDC with loose claim conditions | Dissolved Workload identity federation with strictly bound subject claims — repository, ref, environment and job constrained. |
| 7 | Long-lived secrets | Rotation schedule, expiry policy | Dissolved Credential lifetime measured in minutes and tied to workload lifetime. Rotation as a scheduled activity disappears. |
| 8 | Environment isolation failure | Naming conventions, reviews | Dissolved Trust domains are cryptographically separate. A non-prod identity cannot be presented in prod — the trust bundle rejects it. |
| 9 | NHI reuse across services | Guidance, code review | Dissolved Identity derives from workload attestation, so two workloads cannot share one identity even if an engineer wants them to. |
| 10 | Human use of NHI | Policy prohibition | Mitigated Attestation makes it structurally hard — a human at a laptop cannot produce a valid pod attestation — but Class E remains exposed and needs the human PAM path. |
Seven of the ten stop being achievable states rather than becoming better-managed risks. That is the difference between a control programme and an architectural change — and it is the argument to make to a board, because it is the only version of this story where the operational cost curve bends downwards instead of upwards.
03 — Framing
Design principles
Ten principles. Every design decision downstream should be traceable to one of them, and any exception should name the principle it breaks.
Identity is attested, not issued
A workload's identity derives from verifiable properties of its runtime — orchestrator, image digest, node, hardware root of trust — not from a credential handed to it. If you cannot attest it, you have a legacy exception, not an identity.
Credentials are ephemeral by default
Minutes, not months. Lifetime should be the shortest value the workload's call pattern tolerates. Long-lived credentials are exceptions requiring named ownership and an expiry date on the exception itself.
Every credential is audience-bound
A token valid for any recipient is a bearer token waiting to be replayed. Bind to the intended audience, and prefer sender-constrained mechanisms (mTLS, DPoP) so possession alone is insufficient.
Every NHI has a human owner and an expiry
No identity exists without an accountable human and a date at which its continued existence must be re-justified. Ownership is a property of the identity, not of a spreadsheet, and it must survive re-orgs by binding to a team or service, not a person.
Identity is declared with the workload
An NHI is requested in the same artefact that defines the workload — the manifest, the IaC, the service definition — and reviewed through the same change process. Identity created out-of-band is shadow identity by definition.
The secure path is the easy path
If the governed route is slower than minting a PAT, engineers will mint the PAT and be right to. Developer experience is a security control, and it is the one most often left out of the design.
Trust domains are explicit and cryptographic
Environment separation is enforced by distinct trust roots, not by naming conventions or firewall rules. Crossing a boundary is a deliberate, policy-mediated federation event with its own record.
Authorization is policy-evaluated, not pre-granted
Entitlement is computed at request time from identity, context and policy, rather than accumulated as standing grants. This is what stops ephemeral credentials from simply becoming short-lived over-privilege.
Delegation is explicit and traceable end to end
When an identity acts for another party — an agent for a user, a service for a caller — the delegation chain travels with the request and is verifiable at every hop. No collapsing of chains into a single powerful identity.
Discovery is continuous and assumes you are wrong
The inventory is never complete. Treat discovery as a permanent detective control across cloud, SaaS, source and network — not a one-off onboarding exercise. Design for the identities you do not yet know about.
04 — The architecture
The NHI identity fabric
Five planes. The essential separation is between the issuance plane, which turns attestation into credentials, and the governance plane, which decides whether an identity should exist at all. Most enterprises build only the first and wonder why the population still grows without control.
Note what is not at the centre of this diagram: the vault. In the conventional model the vault is the hub and everything routes through it. Here it is one box in the issuance plane, explicitly labelled as the exception path. If your architecture diagram has a vault in the middle, you have drawn the current state, not the target.
05 — The architecture
The credential decision model
This is the single most useful artefact in the strategy — the rule that determines, for any new workload, what kind of identity it gets. Published and enforced, it prevents the drift that produces a heterogeneous credential estate nobody can reason about.
Credential classes and their properties
| Class | Typical lifetime | Replay resistance | Where it fits, and the trade-off |
|---|---|---|---|
| X.509 SVID / mTLS | Minutes–hours | Sender-constrained | The strongest option. Possession of the certificate alone is insufficient without the private key, which never leaves the workload. Cost is PKI operational maturity and mesh or library integration. |
| JWT SVID | Minutes | Bearer | Necessary where mTLS is impractical — through L7 proxies, across clouds, into services that terminate TLS. Mitigate the bearer weakness with very short TTLs and strict audience binding. |
| Federated cloud credential | 15 min – 1 hr | Bearer | Replaces long-lived cloud access keys entirely. The control that matters is the subject-claim condition — a loosely scoped trust policy is the most common serious misconfiguration in this pattern. |
| Dynamic secret | Minutes–hours | Bearer | Generated per request against a real backend account. Excellent for databases and cloud. Constrained by what the target system supports, and by connection-pool behaviour under short TTLs. |
| Brokered / injected | N/A to caller | Caller never holds it | The pragmatic answer for SaaS and legacy APIs. Concentrates secrets into one hardened, monitored component — which is also a single point of failure and a high-value target. Design accordingly. |
| Workload-bound API token | Hours–days | Bearer | Acceptable only when bound to an attested identity at issue time and revocable. Treat as a transitional state, not a destination. |
| Static vaulted secret | Months | Bearer, copyable | The exception. Every instance needs an owner, a reason, an expiry on the exception and a retirement plan. Count these and drive the number down — it is the single best measure of programme progress. |
Short lifetimes are not free. They multiply issuance traffic, make the identity authority a hard availability dependency, and can break connection pooling, long-running batch jobs and anything that assumed a credential lasts as long as the process. The right lifetime is the shortest one the workload's call pattern actually tolerates — deriving that per workload class is real design work, and pretending otherwise is how these programmes acquire a reputation for breaking production.
06 — The architecture
Lifecycle and the ownership problem
Ephemeral credentials solve credential lifetime. They do not solve identity lifetime — the registry entry, the entitlements, the trust-policy binding and the accountable owner all persist beyond any single credential and are what actually rot. Two distinct lifecycles, often conflated.
Solving ownership: bind to services, not people
Ownership decay is the root cause of OWASP NHI-1. The fix is structural rather than procedural:
- Own by service, not individual. The owner field points at a service or team record. When the team changes shape, the org handles it through normal service ownership — no orphan is created by a single resignation.
- Derive, don't declare, where you can. If the NHI is declared in a repository, the repository's owning team is the owner. Ownership becomes a by-product of engineering structure rather than a field someone must remember to maintain.
- Make ownership consequential. Owners receive the anomaly alerts and the recertification tasks, and their identities are what get suspended when review lapses. Ownership that carries no consequence gets assigned carelessly.
- No orphan state — quarantine instead. If an owner cannot be resolved, the identity moves to QUARANTINED and stops issuing. This is dramatic on purpose: the alternative is a permanent orphan population that everyone is too afraid to delete.
- Dormancy is a lifecycle event. An identity that has not authenticated in N days enters review automatically. Unused NHIs are the most common and most exploitable residue, and dormancy is the cheapest signal you have.
07 — The architecture
Trust domains and federation topology
Trust domain design is the decision most likely to be regretted later. Too few and you lose isolation; too many and you drown in federation relationships. The principle: a trust domain is the blast radius you are willing to accept.
08 — The architecture
Authorization: the half that ephemerality does not solve
A five-minute credential attached to an over-privileged role is a five-minute window of total compromise. Ephemeral identity without an authorization redesign converts a standing-privilege problem into a fast-moving standing-privilege problem, and it is very easy to declare victory at exactly this point. Authentication modernisation without authorization modernisation is half a strategy.
The shift is from pre-granted, accumulated entitlement to computed, contextual, minimal-scope decisions:
| Dimension | Conventional | Target |
|---|---|---|
| Grant model | Roles attached to the identity, accumulating over time | Policy evaluated per request against identity, resource, action and context. Nothing accumulates because nothing is stored. |
| Scope | Broad enough to cover every task the workload might ever do | Narrowed at exchange time to the specific task in flight. A workload that both reads a queue and writes a bucket holds two narrow credentials, not one wide one. |
| Context | Ignored — the same grant applies always | Time, source domain, target sensitivity, deployment state, current risk signals and recent behaviour all inform the decision. |
| Change control | Ticket to add an entitlement; nobody ever removes one | Policy as code — versioned, reviewed, tested, diffable. Removal is as easy as addition, which is what makes least privilege sustainable. |
| Revocation | Wait for the credential to expire, or attempt a manual revoke | Continuous evaluation: a risk signal invalidates in-flight sessions rather than waiting for natural expiry. |
| Verification | Manual entitlement review, annually | Observed-versus-granted analysis. Compare what the identity actually did against what it was allowed to do, and propose the reduction automatically. |
Right-sizing from observed behaviour
The most effective least-privilege mechanism for NHIs is not review — it is observation. Machine behaviour, unlike human behaviour, is narrow, repetitive and highly predictable. A service that has made exactly four API call types every day for six months almost certainly needs exactly those four. That regularity makes automated scope reduction genuinely safe for NHIs in a way it never is for people, and it is the strongest argument for treating machine authorization as a different discipline rather than a variant of the human one.
// The pattern, expressed as intent rather than implementation OBSERVE every authorization decision for identity I over window W DERIVE the minimal policy P' that would have permitted all observed calls COMPARE P' against the granted policy P PROPOSE the reduction P → P' to the identity's owner STAGE shadow-evaluate P' alongside P — count what would have been denied APPLY when the shadow period is clean, with automatic rollback on denial spike // Shadow evaluation is the load-bearing step. Without it, least // privilege becomes an outage generator and the programme loses consent.
09 — The frontier
Agentic identity: the class that breaks the model
AI agents are not simply another workload. They break three assumptions the rest of this architecture rests on, and any strategy written in 2026 that does not address them will need rewriting within a year.
Assumption broken: identity acts for itself
An agent acts on behalf of a user, or of another agent acting for a user. Authorization must consider the whole delegation chain, not just the calling identity. A permission check that sees only the agent sees the wrong principal.
Assumption broken: behaviour is predictable
The observed-behaviour right-sizing in §8 depends on workloads being repetitive. Agents are non-deterministic by design — the same prompt may legitimately produce a different tool sequence. Behavioural baselining degrades badly.
Assumption broken: scope is knowable in advance
A workload's API surface is fixed at build time. An agent's is discovered at runtime through tool invocation. You cannot enumerate the permissions it needs before it runs, which is fatal to pre-granted entitlement.
The building blocks are real but the stack is not finished. OAuth 2.1 with PKCE, RFC 8693 token exchange, DPoP for sender-constraining and CAEP-style continuous evaluation are all deployable today. The Model Context Protocol authorization specification defines OAuth-style protected resources, authorization-server discovery, audience binding via resource indicators and delegation via token exchange — that is the emerging interoperability point for tool invocation. SPIFFE/SPIRE is production-proven for workload identity. IETF WIMSE is the standardisation of what SPIFFE proved, with an architecture document expected to reach RFC across 2026–27 and SPIFFE already publishing a WIMSE-aligned token profile.
Strategic reading: build on SPIFFE and OAuth today, design your abstractions so WIMSE token formats can be adopted without re-architecture, and do not wait for the agentic standards to settle before establishing the delegation-chain principle. The principle is stable even where the wire format is not.
What to do about non-deterministic behaviour
Since behavioural baselining works poorly for agents, the compensating controls shift from prediction to containment:
- Budget rather than baseline. Constrain agents by call volume, spend, data volume and blast radius per task, rather than by expected call pattern. Budgets are enforceable against non-determinism in a way baselines are not.
- Classify tools by consequence, not by sensitivity. The relevant axis is reversibility. A read of highly sensitive data is recoverable; an irreversible write of trivial data may not be. Gate on reversibility.
- Make the task the unit of authorization. Scope, lifetime and budget attach to a task instance, so an agent that goes off-course exhausts a task grant rather than roaming with a session credential.
- Record the reasoning trace alongside the access trace. For agents, the audit question is not only "what did it do" but "why did it decide to". Correlating the two is what makes post-incident analysis tractable.
- Treat prompt injection as a privilege-escalation vector. An agent that can be talked into misusing its legitimate credentials is an authorization problem, not only a model-safety problem — which is precisely why intersection semantics and consequence gating matter more than input filtering.
10 — Making it real
Governance model
Three questions define the operating model: who may create an NHI, who is accountable for it, and what happens when nobody answers. The architecture is only as good as the answer to the third.
| Function | Accountable | Design intent |
|---|---|---|
| Identity standard | Security architecture | Owns the decision model in §5, the trust-domain topology, credential-class definitions and maximum lifetimes. Publishes as policy-as-code, not as a document. |
| Platform provision | Platform engineering | Runs the fabric as an internal product with an SLA. Critically, owns developer experience — Principle 6 makes this a security responsibility, not a convenience one. |
| Identity ownership | Service owning team | Declares identities with their workloads, responds to recertification and anomaly alerts, accepts exceptions. Accountability sits with the team that benefits from the identity. |
| Exception authority | Risk function | Approves deviations from the decision model — every static secret is an exception with an owner and an expiry. The exception register is the programme's true backlog. |
| Discovery & assurance | Security operations | Continuous discovery, reconciliation of unknowns, anomaly detection, and evidence generation. Operates on the assumption the registry is incomplete. |
| Agent governance | Joint — AI governance + security | Tool consequence classification, delegation depth limits, budget policy, human-gate definitions. Genuinely novel; do not bolt onto an existing forum without dedicated attention. |
Three governance mechanisms that carry most of the weight
Creation gate
An identity cannot be registered without its six birth-certificate fields. Because declaration happens in the workload manifest, the gate lives in the deployment pipeline — enforcement is a policy check on a merge, not a ticket queue. This is what makes governance scale with engineering rather than against it.
Expiry by default
Every identity carries an expiry date at which existence must be re-justified. Not the credential — the identity. This inverts the default from "persists until someone removes it" to "ceases unless someone renews it", which is the only version that survives organisational churn.
Quarantine over deletion
Unowned, dormant or failed-recertification identities stop issuing but keep their record. This removes the fear that blocks cleanup — quarantine is reversible in minutes, deletion is not. Programmes that go straight to deletion stall, because nobody will approve the first batch.
If the organisation already runs a CMDB with a service catalogue and ownership model, the NHI registry should be an extension of it rather than a parallel universe. The relationship NHI → parent service → business application → owner is exactly the join that makes recertification meaningful, blast radius computable and incident triage fast. Building a standalone NHI inventory beside an existing CMDB is a common and expensive mistake — you inherit all the reconciliation problems and none of the context.
11 — Making it real
Tooling archetypes
Palo Alto Networks completed its acquisition of CyberArk on 11 February 2026, at roughly $25bn — the largest cybersecurity acquisition to date. CyberArk had itself acquired Venafi (machine identity / certificates, now CyberArk Certificate Manager) in 2024 and Zilla (identity governance). Product naming is in flux; Conjur Cloud Secrets Manager has been renamed under the new ownership, and the portfolio is being positioned inside the acquirer's broader platform.
The strategic implication is not that CyberArk is a worse choice — the combined machine-identity portfolio is arguably the most complete on the market. It is that a platform bet now carries integration and roadmap uncertainty that it did not carry eighteen months ago, and that any architecture should preserve the option to swap components. That argues for standards-based interfaces (SPIFFE, OIDC, OAuth) at every seam.
Rather than name a winner, the useful framing is four archetypes with different failure modes. Most large enterprises end up with a deliberate blend; the mistake is arriving at a blend by accident.
| Archetype | Shape | Strongest when | Failure mode |
|---|---|---|---|
| Suite | One vendor across vaulting, certificates, workload identity and governance. CyberArk (now within Palo Alto Networks) is the most complete example; others are assembling comparable stacks. | You need broad coverage including heavy Class E legacy, have a strong compliance driver, and want one accountable throat. Fastest route to auditable coverage. | Lock-in at the moment the market is consolidating. Suite breadth tends to be uneven — excellent vaulting, adequate workload identity. Roadmap now depends on post-acquisition integration decisions outside your control. |
| Open core | SPIFFE/SPIRE as the identity authority, with policy engines and your own control plane around it. Production-proven at large technology companies. | You have genuine platform engineering capability, a container-heavy estate, and want standards purity with no vendor dependency at the trust root. | You are now a product team. SPIFFE deliberately solves issuance and says little about governance, discovery, legacy or SaaS — you build or buy those anyway. Underestimating this is the classic error. |
| Cloud-native | Hyperscaler primitives: managed identities, workload identity federation, native secret stores, cloud CAs. | Single-cloud or strongly cloud-dominant estates. Excellent economics, deep integration, nothing to run. | Falls apart at boundaries — multi-cloud, on-premises, SaaS and partner federation are exactly where NHI incidents happen. Produces per-cloud silos with no consistent policy or inventory. |
| Best-of-breed | Specialist tools per plane: an NHI discovery and posture product, a secrets platform, a certificate manager, a policy engine, an agent gateway. | You have a specific acute problem — usually SaaS/OAuth sprawl or certificate outages — and need depth fast in one plane. | Integration tax, and no single system holds the complete identity picture. The registry ends up fragmented across five tools, which defeats the governance plane that carries most of the value. |
Own the governance plane; buy the issuance plane; standardise every seam. The registry, ownership model, policy authority and exception register are where durable value and institutional knowledge live — keep them yours and keep them adjacent to your CMDB. Issuance, certificates and vaulting are increasingly commodity and are reasonable to buy from whoever is strongest for your estate. Insist on SPIFFE-compatible identity, OIDC federation and RFC 8693 exchange at every interface, so that a vendor change is a migration rather than a rebuild. Given the consolidation now underway, that optionality is worth paying for.
12 — Making it real
Maturity model
A diagnostic, not a plan. Its purpose is to locate the organisation honestly and to make clear that the jump from Level 2 to Level 3 is an architectural change rather than an incremental improvement — which is where most programmes stall.
13 — Making it real
Anti-patterns
| Anti-pattern | Why it is tempting | Why it fails |
|---|---|---|
| Vault-first thinking | Tangible, purchasable, produces an inventory and satisfies an audit finding quickly. | Optimises the exception path. You industrialise secret storage and thereby make the secret-based model permanent, because now it works well enough that nobody funds replacing it. |
| Boiling the ocean on discovery | "We must know everything before we can act." | The inventory is stale before it is complete, and two years pass with no control change. Discovery is a permanent capability, not a prerequisite phase. |
| Rotation as the headline metric | Easy to measure, easy to report, feels like progress. | Measures effort, not risk. A high rotation rate on a large static-secret estate is a sign of failure at the architectural level, reported as success at the operational one. |
| One trust domain | Simple, avoids federation complexity, "we'll segment later". | Segmentation is never retrofitted, and a single trust root means a single compromise reaches everything. This is the decision most regretted at Level 4. |
| Treating agents as ordinary workloads | They run in containers; they look like services. | Ignores delegation entirely. The agent's identity silently replaces the user's and every user inherits the union of the agent's permissions. |
| Governance without developer experience | Security sets policy; engineering complies. | If the governed path is slower than the ungoverned one, you have built a shadow-NHI generator with a compliance dashboard attached. |
| A separate NHI inventory | The CMDB is messy; a clean purpose-built registry is faster to stand up. | You lose the service, ownership and criticality context that makes recertification meaningful — and acquire a permanent reconciliation problem between two inventories. |
| Ephemeral credentials, unchanged permissions | The hard engineering is done; the metrics look transformed. | Short-lived over-privilege. The credential window shrinks while blast radius stays constant, and the programme declares victory before addressing §8. |
14 — Making it real
Measurement
Four measures matter more than the rest. Each is deliberately chosen to be hard to game and to move only when the architecture actually changes.
Standing credential count
The absolute number of long-lived, copyable secrets that exist anywhere. This is the strategy in one number. It should fall every quarter, and a rise means new build is still creating them — which points at the decision model not being enforced at the pipeline gate.
Attested identity share
Proportion of authentications made with an attested, short-lived credential versus a stored secret. Measured on traffic, not on inventory — a thousand dormant modernised identities matter less than one busy legacy one.
Unowned and dormant population
Identities with no resolvable owner, plus those that have not authenticated in 90 days. Directly proxies OWASP NHI-1, and is the population an attacker would most like you to keep.
Time to a working identity
Minutes from an engineer needing an identity to having a working one on the governed path. The leading indicator for shadow NHI creation. If this exceeds the time to mint a PAT by hand, every other metric will eventually degrade.
Secondary measures worth tracking
- Median credential lifetime, weighted by call volume — the honest version of "we use short-lived credentials"
- Open exceptions to the decision model, and count past their expiry date
- Discovered-but-unregistered identities per month, and mean time to reconcile
- Granted-versus-observed permission delta, aggregated across the estate
- Cross-trust-domain crossings per month, and how many were policy-approved in advance
- For agents: delegation chains exceeding depth limits, consequence-gate invocations, and task-budget exhaustion events
15 — Making it real
Strategic risks in this design
An honest strategy names the ways it could go wrong. These are inherent to the target architecture, not to any particular implementation of it.
| Risk | Description | Design response |
|---|---|---|
| The identity authority becomes Tier-0 | If issuance is unavailable, workloads cannot authenticate and everything stops. You have concentrated availability risk into one component and made it more critical than any application it serves. | Regional redundancy, generous credential overlap windows so brief outages are invisible, cached trust bundles, and a documented degraded mode. Accept and fund this as a Tier-0 platform, or do not start. |
| Trust root compromise | Compromise of a trust domain's signing key allows an attacker to mint any identity in that domain. Higher impact than any individual secret leak. | HSM-backed roots, short-lived intermediates, per-domain separation to bound blast radius, and a rehearsed key-compromise recovery procedure. This is the one scenario worth a dedicated exercise. |
| Attestation forgery | If the attestation source can be spoofed — a compromised orchestrator, a forged OIDC claim, a permissive trust policy — the whole model inverts and identity becomes trivially mintable. | Layer attestation sources rather than relying on one; prefer hardware-rooted evidence where available; treat orchestrator control-plane security as identity-critical; audit federation trust policies for over-broad subject conditions continuously. |
| The long tail never moves | Class E legacy is precisely the estate that cannot be changed — mainframes, appliances, OT, vendor-supplied software. It may persist for a decade, and it holds disproportionate privilege. | Ring-fence rather than pretend. Brokered access, network isolation, strong monitoring, and an explicit, resourced acceptance that this population is managed differently — with the exception register as the honest record. |
| Standards churn | WIMSE is not finished; agentic identity standards are actively moving. Building deeply against a draft risks rework. | Build against stable primitives (X.509, OAuth 2.1, OIDC, RFC 8693) and keep token formats behind an abstraction. Adopt the delegation-chain principle now; treat the wire format as replaceable. |
| Vendor consolidation | The market is consolidating rapidly. Today's best-of-breed choice may be inside a platform with different priorities in eighteen months. | Standards at every seam; own the governance plane; avoid proprietary identity formats at the trust root. Optionality is the hedge, and it is cheap to design in and expensive to retrofit. |
| Agent adoption outruns agent governance | Business demand for agents is immediate; delegation infrastructure is not. The default is a powerful shared service account — the collapsed chain in §9. | Establish the intersection and consequence-gate rules as policy before the first production agent, even where enforcement is partly manual. The principle is cheap early and very expensive to retrofit across a fleet. |
16
References
Consulted August 2026. The NHI space is moving quickly; market and standards positions should be re-validated before decisions with procurement or architectural lock-in.
- OWASP Non-Human Identities Top 10 (2025) — the shared vocabulary used throughout §2
- IETF WIMSE — Workload Identity Practices (draft) · WIMSE working group overview
- What SPIFFE answers for workload identity — and what it doesn't
- Palo Alto Networks completes acquisition of CyberArk (11 February 2026)
- CyberArk positions machine identity security as its 2026 growth engine
- Secure Workload Access with SPIFFE — vendor implementation of attested workload identity
- OAuth token exchange and agentic AI — delegation, DPoP, CAEP
- Multi-user AI agent authentication and the MCP authorization model
- NHI sprawl — scale and growth data · Independent NHI vendor comparison