Who is accountable when a customer support agent approves a fraudulent reset?

Why This Matters for Security Teams

A fraudulent reset is not just a service desk mistake. It is a control failure in an identity workflow that can hand an attacker access to email, payroll, SaaS, or even privileged systems. The key question is not whether the support agent meant well, but whether the organisation designed verification, approval, and review controls that could stand up to pressure, impersonation, and social engineering. That is why accountability belongs to the organisation, with specific owners for policy, tooling, training, and oversight.

Current guidance from the NIST AI Risk Management Framework is clear that governance must cover the full lifecycle of an automated or human-assisted decision process, including escalation and monitoring. In practice, many security teams encounter this failure only after a reset has already been used to pivot into a wider compromise, rather than through intentional control testing.

How It Works in Practice

Responsibility should be split across roles, but ownership should not be vague. Service desk teams execute the workflow, IAM defines the required assurance level, fraud and security set the verification thresholds, and management approves the exception handling model. If the reset is linked to a customer-facing process, the business owner also needs to accept the risk of bypasses, manual overrides, and false positives.

A workable model usually includes:

• Clear identity proofing rules for normal resets and step-up checks for high-risk accounts
• Logging of who approved the reset, what evidence was used, and whether any exception applied
• Quality assurance reviews that sample resets for pattern abuse, not just completion speed
• Escalation paths for suspicious requests, especially where urgency or emotional pressure is used
• Post-incident review that traces whether the issue was policy, training, tooling, or supervision

Because support agents increasingly interact with AI-assisted workflows, the control environment now also intersects with agentic systems. The OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix are relevant where AI suggestions, scripted approvals, or decision support influence the reset path. That means the organisation must validate both the human approval and any AI-assisted recommendation before access is restored. These controls tend to break down when support teams are measured only on speed-to-resolution because verification gets compressed into a box-ticking exercise.

Common Variations and Edge Cases

Tighter reset controls often increase call handling time and customer friction, requiring organisations to balance fraud prevention against service continuity. That tradeoff becomes sharper for executive accounts, remote users, outsourced contact centres, and situations where a customer has lost multiple authenticators at once.

Guidance is still evolving on how much automation is acceptable in reset decisions. Current practice suggests that low-risk requests can be handled with standard checks, while high-risk resets need stronger step-up validation, supervisor review, or independent callback verification. Where financial services, regulated data, or admin access is involved, the bar should be higher because the blast radius is larger.

The most important edge case is delegated accountability. Even if a vendor runs the contact centre, the organisation remains responsible for the control design and the outcome. The NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps responsibility to access control, audit logging, and incident response requirements. For AI-enabled support environments, the NIST AI Risk Management Framework and the Anthropic report on AI-orchestrated cyber espionage both reinforce the same point: if assistance tools shape decisions, those tools must be governed as part of the control chain, not treated as neutral helpers.

Related resources from NHI Mgmt Group

• Who is accountable when a customer is tricked into authorising a fraudulent payment?
• Who is accountable when a supplier support workflow exposes customer data?
• Who is accountable when support workflows expose customer data across tenants?
• Who should be accountable when an AI marketing agent changes customer data incorrectly?