The accountable teams are the owners of secret issuance, runtime policy, and revocation workflows, because JIT access only works when identity, policy, and delivery are governed together. The control failure is not just exposure, it is allowing access to persist beyond its intended task.
Why This Matters for Security Teams
When a workload secret stays active after compromise, the question is not just who discovered it. Accountability sits with the teams that issued the secret, defined the runtime policy, and owned revocation, because a credential that can still be used has already outlived its intended trust boundary. That is why NHI governance treats secret lifecycle as an operational control, not a one-time configuration choice.
This matters because machine and workload identities are now often more numerous than human identities, and visibility is still weak. SailPoint reports that The Critical Gaps in Machine Identity Management report found 57% of organisations lack a complete inventory of their machine identities. If the inventory is incomplete, revocation is slow, ownership is ambiguous, and post-compromise access can persist far longer than leadership expects. Guidance from the OWASP Non-Human Identity Top 10 also points to poor lifecycle control as a recurring weakness. In practice, many security teams encounter secret abuse only after lateral movement or data access has already occurred, rather than through intentional detection.
How It Works in Practice
The practical answer starts with separating three responsibilities. Secret issuance owns how the credential is created, scoped, and delivered. Runtime policy owns whether the workload is allowed to use it for the task at hand. Revocation owns how quickly the credential is killed after task completion or compromise. In a mature flow, JIT credentials are short-lived, workload identity is cryptographically verifiable, and authorisation is evaluated at request time rather than assumed from a static role.
That model is consistent with the SPIFFE workload identity specification, which treats identity as a verifiable property of the workload rather than a reusable secret. It also aligns with NHIMG guidance in the Guide to the Secret Sprawl Challenge, where the problem is not simply secret volume but uncontrolled distribution and weak ownership. For agentic or autonomous workloads, this becomes even more important because behaviour can change at runtime, so static RBAC alone is often too blunt.
- Issue ephemeral secrets with a narrow TTL tied to a single task or session.
- Bind the secret to a workload identity, not a shared account or reusable token.
- Re-evaluate access on each sensitive action using policy-as-code and contextual signals.
- Revoke automatically when compromise is suspected, even if the workflow has not ended cleanly.
Threat research reinforces the need for speed. NHIMG notes in Shai Hulud npm malware campaign that exposed credentials can be targeted within minutes, which leaves very little room for manual cleanup. These controls tend to break down when secrets are embedded in long-lived pipelines and revocation depends on human ticket queues because compromise outpaces the operational response.
Common Variations and Edge Cases
Tighter secret controls often increase delivery friction, so organisations have to balance fast deployment against recovery speed and auditability. That tradeoff is especially visible in legacy CI/CD, shared service accounts, and environments where a single secret still powers many jobs. Current guidance suggests that the more broadly a credential can be reused, the harder it is to assign meaningful accountability after compromise.
There is no universal standard for this yet, but best practice is evolving toward explicit owner tagging, short TTLs, and policy decisions that are evaluated in context. For agent-driven or autonomous workflows, that means the same secret should not be treated as a permanent permission token. The governing question becomes whether the workload still has intent to perform the action, whether the action is permitted right now, and whether the secret should exist at all. The 52 NHI Breaches Analysis is useful here because it shows how ownership gaps and delayed revocation recur across incidents, while the Anthropic — first AI-orchestrated cyber espionage campaign report illustrates how autonomous tool use can magnify the impact of stale credentials. In environments with shared clusters or high-churn ephemeral workloads, the control model can still fail if ownership is not mapped before the secret is issued.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret rotation and lifecycle control are central to post-compromise accountability. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access should limit what a compromised workload secret can do. |
| NIST AI RMF | GOVERN | Autonomous or agentic workloads need explicit ownership and oversight of access decisions. |
Set clear accountability for secret issuance, policy, and revocation before deployment.
Related resources from NHI Mgmt Group
- Who is accountable when inherited NHI credentials remain active after a merger or acquisition?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when delegated workload identity ownership drifts over time?
- Who is accountable for third-party access after a campaign or project ends?
