Who is accountable when production access cannot be explained after an incident?

Why This Matters for Security Teams

When production access cannot be explained after an incident, the issue is not only who clicked or scripted a change. The deeper failure is that the organisation lost the ability to prove scope, timing, and revocation for the access path itself. That makes containment, forensics, and executive accountability far harder than a normal privileged access event. Current guidance in OWASP Non-Human Identity Top 10 treats this as an identity governance problem, not just an audit problem.

For NHI programs, unexplained access usually means the control plane was too weak to answer basic questions: which credential was active, who approved it, what system issued it, and whether revocation actually succeeded. NHIMG research on 52 NHI Breaches Analysis shows that compromise patterns often persist because credentials and service accounts are not mapped tightly enough to operational ownership. In practice, many security teams encounter this only after logs have already aged out and the incident review has become a reconstruction exercise rather than a controlled investigation.

How It Works in Practice

Accountability should be assigned across three layers: the business owner of the workload, the platform owner of the identity mechanism, and the control owner responsible for approval and revocation evidence. That division matters because an agent, service account, or API client can keep operating long after a human operator leaves the scene. The incident question is therefore not simply “who had access,” but “what policy allowed that access, and can it be replayed?”

Practitioners increasingly use short-lived credentials, workload identity, and policy-as-code to reduce ambiguity. A well-run program issues access just in time, binds it to a specific workload or task, and revokes it automatically when the task ends. The JetBrains GitHub plugin token exposure illustrates why long-lived tokens are so difficult to defend after the fact: once the secret exists broadly and persists too long, proving legitimate use becomes nearly impossible. For that reason, teams should prefer workload identity primitives such as SPIFFE/SPIRE or OIDC-bound tokens, then evaluate requests at runtime rather than relying on static role grants.

• Define a named owner for every non-human identity and every production scope it can touch.
• Log issuance, approval, use, and revocation in a way that can be reconstructed during incident response.
• Replace standing access with just-in-time access where possible.
• Separate human operator actions from autonomous or delegated system actions.
• Test whether revocation is immediate, complete, and observable, not merely requested.

AI-driven or automated access paths raise the bar further because their behaviour can shift by task, context, or tool chain. The emerging direction in Anthropic’s report on AI-orchestrated cyber espionage is that runtime control matters more than static trust. These controls tend to break down when legacy systems cannot emit trustworthy identity events or when shared credentials are embedded in automation that no one can inventory.

Common Variations and Edge Cases

Tighter revocation and traceability often increases operational overhead, requiring organisations to balance incident clarity against release velocity. That tradeoff is real, especially where legacy applications, batch jobs, or vendor-managed integrations still depend on static secrets. Current guidance suggests those exceptions should be time-boxed, explicitly owned, and monitored more aggressively than standard workloads.

There is no universal standard for exactly how much evidence is enough to assign accountability after an incident, but the practical test is simple: can the team show who authorised the access, what identity was used, and whether that access was still valid at the time of impact? If the answer is no, accountability shifts from the individual operator to the governance function that allowed opaque access to persist. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because the operational risk is usually visibility failure, not just credential theft.

In environments with shared break-glass accounts, outsourced operations, or multi-agent pipelines, ownership can become diluted quickly. Best practice is evolving, but the direction is consistent: every production privilege needs a provable owner, a time boundary, and a revocation path that is tested before an incident proves the gap.

Related resources from NHI Mgmt Group

• Who is accountable for access cleanup after ransomware recovery?
• Who is accountable when a third party retains access after offboarding?
• Who is accountable when temporary access becomes permanent after a merger?
• Who is accountable when OT remote access cannot be traced after the fact?