Accountability sits with the organisation that controls the exposed identity, custody workflow, or approval process, and with the operators who failed to design containment fast enough. For regulated environments, that maps to governance over privileged access, transaction approval, incident response, and user verification. The core question is whether the control owner could have prevented or limited the transfer window.
Why This Matters for Security Teams
When stolen crypto is moved through exchanges and mixers, accountability is rarely limited to the thief. The practical issue is whether the organisation that owned the exposed identity, approval path, or custody workflow had controls strong enough to slow, flag, or block the transfer window. That means privileged access, transaction approval, user verification, and incident response must be treated as one chain of responsibility, not isolated functions. NHI Mgmt Group notes in 52 NHI Breaches Analysis that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that compromised automation often becomes the bridge to financial loss. NIST’s Security and Privacy Controls reinforce that control ownership and evidence of enforcement matter as much as policy statements. In practice, many security teams discover transfer accountability only after assets have already crossed multiple services and jurisdictional boundaries.
How It Works in Practice
In these cases, accountability follows the control that failed to contain the movement, not just the endpoint that first detected it. If a compromised API key signed withdrawal requests, the owner of that workload identity, secret lifecycle, and approval logic has direct responsibility for the exposure window. If a human approver was bypassed through weak step-up verification, then the approval workflow owner shares accountability for the gap. If monitoring detected the event but incident response could not freeze or quarantine assets quickly enough, then the containment process owner is accountable for the delay.
Practically, teams should map the path of custody and ask three questions:
- Who controlled the identity or token used to authorize the transfer?
- Who owned the policy that should have blocked unusual destination, amount, or velocity?
- Who had the operational authority to pause accounts, revoke secrets, or notify exchanges?
This is where NHI governance becomes critical. The Ultimate Guide to NHIs — Why NHI Security Matters Now shows why exposed secrets and excessive privileges turn ordinary credentials into high-speed loss channels. Current guidance also aligns with identity-centric controls such as rotation, least privilege, and rapid offboarding, because those reduce the time an attacker can move value through exchanges or mixers. These controls tend to break down when custody spans multiple vendors and no single team can revoke access across the full transfer path.
Common Variations and Edge Cases
Tighter approval and containment controls often increase operational friction, requiring organisations to balance fraud resistance against user experience and settlement speed. That tradeoff becomes sharper in high-volume environments, where every additional verification step can affect legitimate transactions.
There is no universal standard for attributing blame across exchanges, mixers, custodians, and internal operators, so current guidance suggests separating legal liability from control accountability. A platform that merely routes funds may have limited duty, while the organisation that exposed the credential or failed to revoke it usually bears the clearest governance obligation. If an attacker used an agentic workflow or automated toolchain to chain actions across multiple services, accountability may also extend to the team that failed to model that behaviour in threat scenarios. The Anthropic report on first AI-orchestrated cyber espionage campaign report is a useful reminder that automation can accelerate misuse once a foothold exists. The key edge case is when a third party receives the stolen crypto after the first hop, because attribution becomes forensic while accountability remains tied to the control owner who allowed the initial transfer window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Stolen crypto often starts with stale or overprivileged NHI secrets. |
| OWASP Agentic AI Top 10 | A-04 | Automated transfer chains can amplify the blast radius of compromised identities. |
| CSA MAESTRO | GOV-01 | Accountability depends on clear ownership of identity, workflow, and containment controls. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance shape who could have moved the assets. |
| NIST AI RMF | Autonomous or automated transfer logic increases the need for governed, accountable controls. |
Rotate exposed secrets quickly and revoke dormant machine credentials before they can sign transfers.
Related resources from NHI Mgmt Group
- Who is accountable when a sensitive user exposes movement data through a personal app?
- Who is accountable when secrets are exposed through compromised infrastructure software?
- How do attackers operationalise stolen OAuth tokens at scale?
- How do attackers turn stolen npm secrets into broader compromise?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
