Who is accountable when a malicious transaction is approved or secrets are exfiltrated?

Why This Matters for Security Teams

Accountability gets contested fast when a malicious approval or secret exfiltration is the result of several weak points lining up: wallet policy, endpoint controls, secret storage, monitoring, and human review. The real risk is not only the transaction or leak itself, but the false assumption that ownership lives in one team’s lane. That assumption delays containment, slows post-incident analysis, and leaves gaps between identity, endpoint, and application security.

This is especially visible in NHI-heavy environments where machine access is reused, secrets are duplicated, and approval paths are only partially observable. NHIMG’s Guide to the Secret Sprawl Challenge shows how secret duplication and fragmented control make it difficult to prove which safeguard failed first. OWASP’s OWASP Non-Human Identity Top 10 reinforces that non-human access failures are rarely isolated events. In practice, many security teams encounter accountability disputes only after the wallet has been drained or the secret has already been reused elsewhere.

How It Works in Practice

Operational accountability should follow control ownership, not just incident impact. If a malicious transaction is approved, the approving control owner needs to answer for policy design, but endpoint, secret, and detection owners also need to explain whether their controls were supposed to prevent, detect, or limit the blast radius. The same logic applies when secrets are exfiltrated: the team that stored the secret, the team that protected the endpoint, and the team that monitored anomalous access all have partial accountability.

For practitioners, the cleanest way to manage this is to map each failure point to a control domain and define who can change it, who monitors it, and who signs off on exceptions. Current guidance suggests using policy-as-code for approval logic, short-lived secrets for high-risk workflows, and explicit ownership for detection rules and revocation paths. In NHI programs, Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful because it frames why long-lived secrets create more durable failure modes than ephemeral ones. NIST’s Zero Trust Architecture guidance is relevant here because it shifts the question from “who owns the incident” to “which control should have stopped this request at runtime?”

• Assign wallet approval policy to the team that owns transaction logic.
• Assign secret lifecycle, storage, and rotation to the team that manages the secrets platform.
• Assign endpoint telemetry, tamper detection, and malware response to the endpoint team.
• Assign detection engineering and alert triage to the monitoring or SOC function.
• Document exception handling so shared responsibility does not become no responsibility.

When a transaction or secret crosses multiple systems, accountability should be reconstructed from control evidence, not from whichever team receives the first alert. These controls tend to break down in highly delegated environments where approvals, credential issuance, and logging are split across too many tooling owners to produce a single, defensible chain of custody.

Common Variations and Edge Cases

Tighter accountability often increases operating overhead, requiring organisations to balance clearer ownership against slower change management. That tradeoff becomes visible when a platform team runs the vault, a product team owns the application, and a security team owns the policy engine. The answer is not to centralise everything, but to make ownership explicit at each layer.

There is no universal standard for this yet, especially in hybrid environments where a malicious approval may involve a browser wallet extension, a CI runner, and a cloud secret store. In those cases, the incident commander may be accountable for coordination, while the control owners remain accountable for their respective failures. A useful refinement is to separate blame from responsibility: one owner may be responsible for a missed rotation, another for a failed alert, and another for an approval path that allowed the action. That distinction matters because it drives remediations that actually close the gap. NHIMG’s 52 NHI Breaches Analysis is a practical reminder that repeated compromise patterns usually reflect systemic control failure, not one-off mistakes.

For mature programs, the best practice is evolving toward shared accountability with named control owners, written exception paths, and post-incident evidence that shows which layer failed first and which layer failed to contain the blast radius.

Related resources from NHI Mgmt Group

• Who is accountable when high-risk access is approved through a uniform process?
• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?