Accountability sits across the wallet provider, the dApp developer, and the organisation operating the wallet trust model. If the approval flow allows spoofed identity signals or ambiguous signing prompts, then control ownership is incomplete. NIST SP 800-53 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines are relevant for defining assurance and access governance expectations.
Why This Matters for Security Teams
When a malicious dApp triggers an unauthorised transfer, the immediate question is not just who signed, but who allowed the signing path to be trusted in the first place. That makes this an identity assurance and control ownership problem, not only a fraud or blockchain problem. NIST SP 800-53 Rev 5 Security and Privacy Controls gives security teams a vocabulary for accountability, while NHIMG’s Ultimate Guide to NHIs shows how often identity controls fail when privileges, secrets, and offboarding are not tightly governed.
In practice, the weak point is usually the trust model around the wallet, the dApp, and the approval prompt. If users or automated agents are shown ambiguous signing context, the organisation has already lost control of the decision boundary. That is especially risky because NHIs outnumber human identities by 25x to 50x in modern enterprises, and static assumptions about “trusted” execution do not survive adversarial tooling or deceptive interfaces. In practice, many security teams encounter unauthorised transfers only after the transaction is already finalised, rather than through intentional governance of the approval flow.
How It Works in Practice
Accountability is typically shared across three layers: the wallet provider, the dApp developer, and the organisation that set the operating policy for wallet use. The wallet provider is accountable for the safety and clarity of the signing experience, including phishing-resistant prompts, accurate transaction detail rendering, and protections against spoofed identity signals. The dApp developer is accountable for the contract interaction design, especially where approvals, delegated permissions, or opaque token movements are involved. The operating organisation is accountable for policy, training, and technical guardrails such as allowlisting, approval thresholds, and separation between high-risk and routine transactions.
Security teams should treat wallet interactions as identity and authorisation events, not just user clicks. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping control ownership around access enforcement, auditability, and system integrity. In mature environments, the trust model should include:
- clear signing intent, so the user sees what asset, amount, and destination are being approved
- strong workload or session identity for automated wallet actions, so policy can distinguish legitimate operations from abuse
- step-up approvals for high-value transfers, especially where the dApp requests broad token permissions
- loggable, reviewable transaction metadata that supports post-incident attribution
- revocation and containment paths for compromised approvals or session keys
Current guidance suggests this should be paired with identity assurance concepts from NIST SP 800-63 Digital Identity Guidelines, because the question is not only whether a signer exists, but whether the signer context is trustworthy at the moment of authorisation. The Ultimate Guide to NHIs is also relevant here because wallet-connected agents, bots, and service accounts often inherit broad privileges without the lifecycle controls that human identities receive. These controls tend to break down when dApps rely on generic approval text and the organisation has no transaction-level policy engine, because the malicious payload is hidden inside a superficially normal interaction.
Common Variations and Edge Cases
Tighter approval controls often increase friction, requiring organisations to balance user experience against transfer safety. That tradeoff becomes harder in environments where wallets are used by both humans and autonomous agents, because one-size-fits-all approval rules can either block legitimate activity or permit dangerous overreach. There is no universal standard for this yet, but best practice is evolving toward contextual authorisation, where the transaction itself carries the evidence needed for the decision.
Edge cases matter. If the dApp is legitimate but compromised through a dependency or front-end attack, accountability may shift toward the dApp operator for weak software supply chain controls. If the wallet provider fails to display the real destination or token scope, the provider may share responsibility for misleading UX. If the organisation allowed unrestricted approvals, no transaction limits, or reusable session credentials, internal governance is part of the failure. This is why security teams should document who owns the wallet policy, who approves high-risk contract interactions, and who can revoke permissions when behaviour changes. NHIMG’s Ultimate Guide to NHIs is useful here because the same lifecycle gaps that weaken service-account governance also weaken wallet-connected operational identities.
Where this guidance breaks down most often is in cross-organisation Web3 workflows, because no single party controls the full signing chain and incident response can be too slow to stop a finalised transfer.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Shared accountability depends on enforcing least privilege and controlled access. |
| NIST SP 800-63 | Identity assurance matters when signing context is spoofed or ambiguous. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Unauthorised transfers often follow weak secret and credential lifecycle controls. |
| CSA MAESTRO | Agent and workflow governance helps assign responsibility across autonomous actors. | |
| NIST AI RMF | Risk governance clarifies accountability for automated or semi-autonomous decision paths. |
Raise assurance requirements for sensitive approvals and step up when context is unclear.
Related resources from NHI Mgmt Group
- How should teams reduce risk from malicious npm package installs?
- Who is accountable when an AI agent delegation chain causes an unauthorised action?
- Who is accountable when AI impersonation causes an unauthorised reset or payment change?
- Who is accountable when an autonomous system triggers a breach?
