Who is accountable when run provenance is incomplete or cannot be read?

Why This Matters for Security Teams

When run provenance is missing or unreadable, accountability shifts from a simple reporting question to a control assurance problem. Security teams need to know whether the failure is in the source system, the permissions model, or the evidence pipeline itself. That distinction matters because incomplete provenance can hide unauthorised execution, broken change control, or gaps in auditability long after the event.

This is not a theoretical issue. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a strong indicator that execution evidence is often incomplete before anyone asks for it. The practical lesson is that accountability cannot rest on a report that the system cannot reliably produce. Teams should treat provenance as part of the control set, not just the logging layer, and map it to baseline audit requirements in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover provenance gaps only after an incident review or access dispute has already started.

How It Works in Practice

Accountability usually follows ownership of the reporting workflow, but the operational question is which control failed first. If the source was unreadable, the system may have captured evidence that cannot be parsed. If permissions blocked inspection, the evidence may exist but be inaccessible to the reviewer. If the pipeline failed, the report may never have been assembled at all. Each case implies a different owner, remediation path, and level of residual risk.

Good practice is to separate three layers:

• source provenance, meaning the original execution record or run metadata;
• access provenance, meaning who can inspect, export, or attest to that record;
• reporting provenance, meaning whether the workflow preserved the evidence end to end.

For NHI-driven or agentic workflows, this becomes more important because tool calls, delegated actions, and service identities can generate many partial records. The right question is not only whether a run happened, but whether the organisation can reconstruct who or what executed, under which identity, and with which permissions. That aligns with the evidence-and-control expectations discussed in the Schneider Electric credentials breach, where identity and access weaknesses can quickly complicate forensic clarity. Current guidance suggests pairing immutable logs with access-controlled attestations and retention rules, then testing whether the report remains readable after credential rotation, parser changes, or data export. These controls tend to break down when provenance is stored in one system, access is governed in another, and the reporting pipeline depends on brittle format assumptions.

Common Variations and Edge Cases

Tighter provenance controls often increase operational overhead, requiring organisations to balance evidentiary strength against reporting speed and admin burden. That tradeoff becomes especially visible when evidence is distributed across SaaS platforms, CI/CD tooling, and NHI-heavy automation.

There is no universal standard for this yet, but the best practice is evolving toward preserving machine-readable run records with explicit ownership and fallback access paths. If provenance is incomplete because a log format changed, the issue is usually engineering debt. If it is unreadable because permissions are too restrictive, the issue is often segregation of duties or emergency access design. If the source cannot be trusted at all, then the organisation may need to treat the run as unverified rather than merely undocumented.

Edge cases also arise when third-party systems generate the run evidence, when legal holds prevent alteration, or when incident responders need temporary access outside normal RBAC. In those situations, accountability should remain with the workflow owner, but verification responsibility may shift to security, platform, or compliance teams depending on who controls the evidence path. The key is to define who must prove the run, who can read the proof, and who is allowed to remediate when the proof is missing.

Related resources from NHI Mgmt Group

• Who is accountable when a business cannot prove valid consent later?
• How should security teams run access reviews for non-human identities?
• Who is accountable when AI traces are incomplete and production behaviour cannot be reconstructed?
• Who is accountable when a business continues dealing with an ASF-linked counterparty after red flags appear?