Identity teams should treat support and recovery as high-risk verification points, not routine service interactions. Require separate-channel proof, higher assurance for account changes, and behavioural or device signals that can confirm the request matches the legitimate user. If the same channel can be spoofed, it should not be the channel that authorises the action.
Why This Matters for Security Teams
Customer support and recovery flows are attractive to agentic fraud because they combine urgency, authority, and partial information. An attacker does not need full account compromise if they can persuade a support agent, exploit a scripted workflow, or trigger an AI-assisted case handler to make a bad exception. The risk is higher when recovery steps are optimised for speed rather than assurance, especially in environments where chat, voice, and ticketing systems all feed the same decision path.
For identity teams, the core issue is trust transfer. A support interaction may feel legitimate because the user knows account details, recent purchases, or prior case numbers, but those signals are often observable, reusable, or inferable. Current guidance suggests treating recovery as a privileged workflow with explicit step-up checks, not a customer service convenience. That aligns with the control intent in the NIST Cybersecurity Framework 2.0, where identity assurance and response discipline are part of broader resilience.
Agentic fraud becomes especially dangerous when an AI agent can draft responses, summarise evidence, or recommend next actions without strong guardrails. If the support stack is allowed to act on weak signals, the attacker only needs to find the shortest path from conversation to account reset. In practice, many security teams encounter this only after a recovery workflow has already been abused to change contact details, reset MFA, or reroute funds.
How It Works in Practice
Effective handling starts by separating authentication, verification, and authorisation. A customer may be authenticated for a support session, but that does not automatically justify account recovery or profile changes. Identity teams should define which actions require higher assurance, which require independent verification, and which should always be denied through assisted channels.
In practice, the strongest pattern is to combine multiple proof types that are hard to spoof at the same time:
- Separate-channel confirmation for any high-risk change, such as a callback to a previously enrolled number or a verified in-app approval.
- Behavioural and device signals that help confirm continuity, including familiar device recognition, session history, and risk-based friction.
- Case handling rules that block overrides when the request is time-sensitive, emotionally urgent, or tied to payment change, MFA reset, or email replacement.
- Human review for exceptions, with decision logging that captures who approved the action and what evidence supported it.
This is where agentic AI changes the threat model. A support copilot can accelerate triage, but it can also over-trust persuasive narratives, hallucinated context, or manipulated transcripts. NHI governance matters here because support automations often hold delegated authority over passwords, tokens, recovery links, and profile attributes. Security teams should map every AI-assisted support action to a named owner, a bounded purpose, and an auditable policy. The NIST AI Risk Management Framework is useful because it emphasises governance, measurement, and ongoing monitoring rather than one-time approval.
Teams should also define abuse detection around the workflow itself. Look for repeated recovery attempts, mismatched channels, rapid changes to recovery destinations, and requests that combine low-confidence identity evidence with high-impact actions. When agentic tooling is present, review the instructions, retrieval sources, and tool permissions that shape support recommendations. Guidance from the OWASP Agentic AI Top 10 is especially relevant for controlling overreach, tool misuse, and indirect prompt injection in support automation. These controls tend to break down when a single case queue spans multiple products and regions because policy exceptions, inconsistent identity proofing, and outsourced agents create gaps between verification and approval.
Common Variations and Edge Cases
Tighter recovery controls often increase customer friction and contact-centre handling time, so organisations must balance fraud resistance against abandonment and accessibility. There is no universal standard for this yet, especially where voice support, multilingual queues, or regulated vulnerable-customer processes are involved.
One common edge case is legitimate users who have lost access to both primary and secondary channels. In those situations, best practice is evolving toward stepwise recovery rather than a single all-or-nothing reset. That may mean issuing limited access, delaying high-risk changes, or requiring an out-of-band proofing path before full restoration. For high-value accounts, support should never be the sole authority for MFA resets or payment destination changes without independent controls.
Another edge case is AI-assisted contact centres. If an agentic system can create summaries, suggest next steps, or auto-populate forms, it must not become the final decision-maker for recovery. The MITRE ATLAS adversarial AI threat matrix is useful for thinking through manipulation, deception, and abuse paths in AI-enabled workflows, while the CSA MAESTRO agentic AI threat modeling framework helps teams structure control coverage across agents, tools, and delegated actions.
Where regulated identity assurance applies, the right answer may be to require stronger identity proofing before recovery, not to relax evidence requirements for convenience. That is especially true where fraud losses, privacy harms, or downstream account takeover risk are material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Recovery flows hinge on strong identity assurance before privileged account changes. |
| NIST AI RMF | AI-assisted support needs governance, measurement, and monitoring for fraud risk. | |
| OWASP Agentic AI Top 10 | Agentic support tools can be manipulated into unsafe or over-privileged actions. | |
| MITRE ATLAS | Adversarial tactics map well to deception and manipulation in AI-enabled support flows. | |
| NIST SP 800-53 Rev 5 | IA-2 | Identity proofing and re-authentication are central to risky recovery actions. |
Require stronger assurance before approving resets, profile edits, or recovery destination changes.
Related resources from NHI Mgmt Group
- How should fraud teams handle AI-generated identity evidence in onboarding flows?
- Why do agentic commerce flows change identity risk for merchants and IAM teams?
- Should customer identity teams use fraud trends to prioritise controls?
- How should teams handle logout and token revocation in mobile identity flows?
