Who is accountable when a DeFi theft is driven by compromised identities and supply chain risk?

Why This Matters for Security Teams

When a DeFi theft follows compromised identities or supply chain exposure, accountability is not limited to the wallet owner or the attacker. It usually spans protocol governance, engineering leadership, security operations, and any third party that can sign, deploy, or publish updates. That matters because the failure is often in control ownership long before the transfer is executed.

Security teams also need to separate what was technically possible from what was operationally permitted. Identity compromise, leaked secrets, and unsafe release paths are exactly the kinds of weak points highlighted in the 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10. If a protocol depends on signing keys, CI/CD tokens, or delegated admin access, then ownership for those paths is part of the blast radius.

NHIMG research on secrets exposure shows why this is not a theoretical concern: in The State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. In practice, many security teams discover accountability gaps only after the theft has already been routed through a trusted deployment path.

How It Works in Practice

The practical answer starts with mapping the chain of custody for privileged actions. In DeFi, that usually includes signing keys, release pipelines, governance multisigs, secret stores, CI/CD runners, build artifacts, and any vendor that can influence a deployment or admin decision. The accountable party is the organisation or collective that defined, approved, and monitored those controls, even if the attacker triggered the event.

A defensible model usually looks like this:

• Protocol governance owns the rules for upgrade authority, emergency controls, and signer replacement.
• Engineering leadership owns secure release design, key handling, and dependency hygiene.
• Security operations owns monitoring, detection, rotation, and incident escalation.
• Third parties own the security of their own build, signing, or hosting paths unless the contract says otherwise.

This is where NIST guidance becomes useful. The NIST Cybersecurity Framework 2.0 frames accountability through governance, risk management, and recovery, while NIST SP 800-53 Rev. 5 helps translate that into controls for access enforcement, auditability, change management, and supplier oversight. NHIMG’s LiteLLM PyPI package breach is a reminder that compromise can arrive through the software supply chain, not just direct credential theft.

For DeFi teams, the operational question is whether privileged paths were reviewable, revocable, and attributable before the incident. If a compromised identity could deploy code, move funds, or alter contract logic without secondary approval, accountability is shared by the people who allowed that path to exist. These controls tend to break down when fast-moving governance overrides remove separation of duties during emergency response, because the exception becomes the normal operating path.

Common Variations and Edge Cases

Tighter governance often increases deployment friction, requiring organisations to balance transaction speed against review depth and signer resilience. That tradeoff is especially visible in decentralised environments where there is no single executive owner, yet users still expect clear responsibility after loss.

There is no universal standard for this yet, but current guidance suggests three edge cases need explicit treatment. First, if the compromise came through a contractor or managed service, accountability does not disappear; it shifts into vendor oversight, contract scope, and shared control design. Second, if governance is distributed across token holders or a foundation, responsibility should still be documented for day-to-day operational controls, not only constitutional authority. Third, if the theft involved a compromised build or dependency pipeline, the accountable team is the one that accepted the release risk without compensating controls such as code signing, reproducible builds, and short-lived credentials.

The Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack both show how quickly trusted automation can become the attack path. For that reason, accountability should be documented not only for who approved the funds movement, but also for who owned the identity, secret, and pipeline controls that made the theft possible. In practice, the hardest failures appear when teams assume “decentralised” also means “unassigned,” after a single compromised token has already bridged governance and production.

Related resources from NHI Mgmt Group

• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• How do attackers turn a supply-chain incident into wider NHI compromise?