Who is accountable when AI impersonation causes an unauthorised reset or payment change?

Why This Matters for Security Teams

AI impersonation changes the accountability question because the request may look legitimate while the decision path is not. A reset, payout change, or bank-detail update should not be treated as routine user support when an agent, bot, or cloned voice is involved. The real control issue is whether the organisation required enough evidence before allowing the change to proceed.

NIST’s NIST Cybersecurity Framework 2.0 frames this as a governance and risk problem, not just an authentication problem. That matters because identity checks alone do not prove intent, and intent is exactly what impersonation attacks exploit. NHIMG’s DeepSeek breach coverage shows how quickly exposed identities and secrets can become operational risk when trust is misplaced.

Security teams often assume the help desk, finance team, or customer-facing agent “owns” the mistake. In practice, many organisations only discover the weak approval path after an unauthorised reset or payment change has already been executed.

How It Works in Practice

Accountability should be assigned to the organisation that designed the control path, then traced across the people and systems that approved it. In operational terms, that means security defines the evidence threshold, IAM defines the identity proofing and step-up checks, and the service owner defines which changes are high risk and must be delayed, reviewed, or dual-approved.

The strongest pattern is to require context-aware verification for sensitive actions such as password resets, bank-account updates, MFA re-enrolment, payment destination changes, and support escalations. This is where policy must be explicit: what data can trigger approval, what secondary channel is required, who can override a denial, and what logs are retained for audit and dispute handling. Current guidance suggests that a single factor, such as caller ID or email similarity, is not enough for high-impact changes.

• Classify change requests by impact, not by convenience.
• Require step-up verification for actions that can move money, revoke access, or alter recovery paths.
• Use dual approval or callback verification for exceptions.
• Record the evidence used, the approver, and the exact change made.
• Retain logs so incident response can reconstruct who authorised what and why.

For deeper NHI context, NHIMG’s research on DeepSeek breach and the broader The State of Secrets in AppSec findings both reinforce the same point: once trust signals are weak, attackers can move faster than manual review can compensate. These controls tend to break down in high-volume support centres and payment operations because speed pressure pushes staff to accept incomplete evidence.

Common Variations and Edge Cases

Tighter approval controls often increase friction, requiring organisations to balance fraud resistance against customer experience and operational speed. That tradeoff is real, especially where urgent account recovery is expected or where payment operations cannot pause for long manual reviews.

There is no universal standard for this yet, but best practice is evolving toward risk-based approval paths. A low-risk profile change may need only standard identity proofing, while a high-value transfer, vendor banking change, or account takeover recovery should trigger stronger checks, such as out-of-band confirmation, supervisor review, or an enforced waiting period.

Edge cases matter. If an employee follows policy but the policy is weak, accountability remains with the organisation that approved the policy. If an AI agent or support automation initiated the request, the service owner still owns the control design that allowed the action. If a third-party workflow performed the change, procurement and vendor governance must still ensure the organisation defined acceptable evidence and retained the audit trail. The practical lesson is that “the user requested it” is not a sufficient control answer when impersonation is plausible.

Related resources from NHI Mgmt Group

• Who is accountable when AI API traffic causes cost blowout or abuse?
• Who is accountable when an AI agent delegation chain causes an unauthorised action?
• Who is accountable when an AI agent makes an unauthorised change?
• Who should be accountable for AI access revocation risk?