What breaks when organisations cannot prove who had access during an incident?

Containment slows, reporting becomes uncertain, and investigators lose the ability to reconstruct how an event moved through the environment. Under NIS2, that gap is serious because the directive expects fast notification, clear accountability, and evidence-backed response across critical services.

Why This Matters for Security Teams

When an organisation cannot prove which non-human identity, account, or agent had access during an incident, containment becomes a guessing exercise. Security teams lose the ability to distinguish legitimate automation from malicious use, and that uncertainty weakens triage, notification, and post-incident scope determination. The issue is not just technical. It directly affects accountability, evidence quality, and whether response actions can be defended to regulators and auditors.

This is especially important for NHI environments because secrets, service accounts, and agent credentials are often shared, long-lived, or poorly inventoried. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which means many teams are already operating with blind spots before an incident begins. The risk is highlighted in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10, both of which stress visibility, lifecycle control, and access governance as core controls rather than optional hygiene.

In practice, many security teams discover the absence of proof only after logs have aged out, shared credentials have been reused, or incident responders cannot tell whether access came from a human operator, a workload, or an autonomous agent.

How It Works in Practice

Proving access during an incident depends on joining identity evidence, authentication events, and workload context into a chain that can be reconstructed later. That means knowing which NHI existed, what it was allowed to do, when it was issued credentials, and whether those credentials were still valid at the time of the event. For humans, that usually involves SSO, MFA, and privileged session records. For workloads and agents, the proof often comes from workload identity, short-lived tokens, and policy decisions made at request time.

Current guidance suggests using per-request or per-task evidence rather than relying on static role assignments alone. For autonomous systems, the critical question is not just who owned the account, but what the agent was authorised to do at that moment and whether the action matched approved context. That is why practitioners increasingly combine workload identity standards with policy-as-code and runtime authorisation. Frameworks such as NIST AI Risk Management Framework and NIST SP 800-53 Rev 5 Security and Privacy Controls support this approach by emphasising traceability, accountability, and control monitoring.

• Issue short-lived credentials tied to a specific task or workload.
• Log token issuance, policy evaluation, and tool invocation together.
• Separate human approval from machine execution where possible.
• Record immutable evidence for revocation, rotation, and session termination.
• Correlate access logs with asset, secret, and privilege inventories.

For agentic environments, this aligns with the practical lessons in the 52 NHI Breaches Analysis, where identity ambiguity repeatedly magnified incident scope. These controls tend to break down in environments that still rely on shared API keys, unmanaged service accounts, or asynchronous pipelines where access logs do not preserve the full execution context.

Common Variations and Edge Cases

Tighter identity proof often increases operational overhead, requiring organisations to balance evidentiary strength against automation speed and platform complexity. That tradeoff is real in CI/CD systems, ephemeral containers, and multi-agent workflows where access can be created and destroyed faster than traditional review cycles can keep up.

There is no universal standard for this yet, but best practice is evolving toward evidence that survives incident handling. In some environments, that means using token-bound sessions and centralised secret issuance. In others, it means mapping every privileged action to a workload identity and an approval record. The same principle applies even when vendors provide telemetry: if the organisation cannot tie access to a specific identity, the evidence will still be weak.

Agentic systems make this harder because behaviour is dynamic. A single agent may chain tools, escalate through intermediate services, or call external systems outside normal human access patterns. That is why current guidance from OWASP Non-Human Identity Top 10 and the broader NHI guidance in Ultimate Guide to NHIs favours least privilege, rotation, and traceable ownership. In environments with shared runners, third-party automation, or long-lived integration secrets, the proof chain often fails because the same credential is reused across many actors and no longer maps cleanly to one incident path.

Related resources from NHI Mgmt Group

• How do organisations prove access governance is working during audit?
• What breaks when organisations cannot see access activity across IT and OT?
• What breaks when organisations leave third-party access standing during geopolitical escalation?
• What breaks when SOC 2 teams cannot prove access controls are working?