Who is accountable when AI-assisted attacks compromise wallet or protocol access?

Accountability sits with the teams that own identity governance, key management, and incident response, not with the model itself. Where human and non-human access paths intersect, owners must define who can approve, revoke, and recover access before an incident occurs.

Why This Matters for Security Teams

AI-assisted attacks change the accountability model because the model is not the asset owner, but it can still accelerate reconnaissance, phishing, token theft, and privilege abuse. The practical question is not whether an attacker used AI, but which control owners were supposed to prevent or contain the resulting access compromise. NIST guidance on control ownership and incident handling, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, helps frame that responsibility.

For wallet or protocol access, accountability typically spans identity governance, key management, application security, and incident response. If a human operator approves a malicious transaction, that is a governance failure. If a bot or agent signs it, that is an NHI control failure. If recovery paths are unclear, that is an operational resilience failure. Mature teams define ownership before compromise, including who can freeze access, rotate secrets, revoke sessions, and validate recovery.

In practice, many security teams encounter accountability gaps only after a wallet drain or protocol abuse has already forced a crisis response.

How It Works in Practice

Accountability should be mapped to the control plane, not to the attacker’s tooling. When AI-assisted attacks target wallet or protocol access, the likely failure points are credential theft, prompt-assisted social engineering, session hijacking, malicious transaction approval, or abuse of over-privileged automation. The investigation should therefore trace which trust boundary failed: identity proofing, privileged approval, signing authority, or monitoring and response. Public attack pattern references such as the MITRE ATT&CK Enterprise Matrix help teams classify how access was obtained and maintained.

Operationally, ownership usually breaks down into four functions:

• Identity governance, which decides who can approve access and under what conditions.
• Key and secret management, which controls generation, storage, rotation, and revocation.
• Application or protocol administration, which defines transaction rules, policy checks, and recovery paths.
• Security operations and incident response, which detect abuse and coordinate containment.

Where non-human identities are used, the same accountability principles apply to service accounts, bots, delegated agents, and signing services. The OWASP Non-Human Identity Top 10 is useful here because many wallet and protocol compromises succeed through stale credentials, excessive permissions, or weak secret lifecycle controls. For AI-driven attack methods, the MITRE ATLAS adversarial AI threat matrix helps distinguish model abuse from downstream access abuse.

Good practice is to predefine who can pause signing, invalidate sessions, trigger emergency rotation, and confirm recovery integrity. These controls tend to break down when wallets, brokers, and protocol automation are spread across different teams because no single owner can act fast enough during an active compromise.

Common Variations and Edge Cases

Tighter access controls often increase operational friction, requiring organisations to balance recovery speed against the risk of false revocation or transaction disruption. That tradeoff matters especially in protocol environments where there is no universal standard for emergency rollback, and the right answer depends on chain design, custody model, and business criticality.

In custodial environments, accountability usually sits with the platform operator, because it controls keys, policy enforcement, and customer recovery workflows. In self-custody or delegated-signing setups, accountability becomes more distributed, and current guidance suggests documenting which party owns policy, which party approves transactions, and which party absorbs the operational risk if a key is misused. For agentic workflows, the intersection with NHI governance matters: if an AI agent can trigger signing or release secrets, then its permissions must be treated like any other privileged identity.

Incident teams should also watch for gaps between detection and attribution. A compromise may be visible in logs long before the responsible owner is identified, especially if the attack used automation or token replay. That is where advisories from CISA cyber threat advisories and real-world incident reporting such as Anthropic’s first AI-orchestrated cyber espionage campaign report are useful reminders that AI often amplifies existing access-control weaknesses rather than creating entirely new ones.

Related resources from NHI Mgmt Group

• How do organisations keep AI-assisted access changes accountable?
• Who is accountable when AI-enabled attacks bypass legacy access controls?
• Who should be accountable for access created by automation and AI-assisted development?
• Who is accountable when an AI-assisted compromise escapes its initial boundary?