Which controls should organisations prioritise when AI-driven fraud starts increasing across user journeys?

Start with controls that reduce both entry-point fraud and downstream abuse. That means stronger liveness checks, risk-based authentication, transaction monitoring, and escalation paths for suspicious activity. Organisations should also watch for new fraud patterns by region and channel, then adjust thresholds and review workflows so controls stay effective as attack methods evolve.

Why This Matters for Security Teams

When AI-driven fraud starts rising across user journeys, the issue is usually broader than a single weak control. Attackers probe onboarding, login, step-up verification, payment confirmation, and support workflows as one connected path. That means liveness checks, fraud scoring, and escalation rules must work together rather than as isolated point fixes. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as an integrated control problem, not a single tool problem.

For NHI Management Group, the core risk is that fraud often rides on compromised identities, abused secrets, or automation that can move faster than manual review. In the LLMjacking research, exposed AWS credentials were targeted within an average of 17 minutes, which shows how quickly adversaries can operationalise stolen access. In practice, many security teams encounter fraud only after abuse has already spread across multiple journeys, rather than through intentional detection design.

How It Works in Practice

The best response is to prioritise controls that interrupt both initial account abuse and downstream transaction fraud. Start with stronger identity proofing at the highest-risk entry points, then layer adaptive authentication so step-up checks trigger when device, geolocation, velocity, or behavioural signals change. From there, add transaction monitoring that treats each action as part of a campaign, not an isolated event.

A practical sequence usually looks like this:

• Strengthen liveness and anti-spoofing checks on onboarding, recovery, and high-value changes.
• Use risk-based authentication for login, password reset, payout changes, and beneficiary edits.
• Correlate device fingerprinting, IP reputation, session anomalies, and payment velocity in one review flow.
• Route suspicious cases into human escalation paths with clear hold, verify, and release decisions.
• Continuously tune thresholds by region, channel, and product line so controls adapt to local fraud patterns.

This is also where secrets governance matters. If fraud actors gain access to backend APIs, support tooling, or agent workflows, they can bypass the user-facing controls entirely. The State of Secrets in AppSec research shows how long remediation can lag once secrets are exposed, which is a warning sign for fraud response as well. For control mapping, the strongest alignment is with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access, monitoring, and incident response families. These controls tend to break down when multiple fraud channels share weak recovery flows because attackers can pivot from one journey to another faster than analysts can reconcile alerts.

Common Variations and Edge Cases

Tighter fraud controls often increase friction, requiring organisations to balance conversion against loss reduction. That tradeoff is especially important in markets with high mobile usage, shared devices, low-bandwidth conditions, or customers who routinely change phones and locations. Current guidance suggests that step-up checks should be risk-based rather than universal, because blanket friction can push legitimate users into abandonment or support queues.

Some environments also need different thresholds by channel. For example, account takeover patterns may dominate in one region while authorised payment fraud or mule activity dominates in another. In those cases, static rules age quickly and should be supplemented with review queues that can be tuned by channel, merchant type, and customer segment. The DeepSeek breach is a reminder that exposure can cascade from one weak control into broader operational risk, especially where support systems, secrets, and user journeys intersect.

Best practice is evolving, but the practical rule is simple: prioritise controls that reduce entry-point compromise, limit session abuse, and give analysts a fast path to verify suspicious activity. If that linkage is missing, even strong detection can fail at the last mile.

Related resources from NHI Mgmt Group

• Should organisations prioritise AI agent access controls before broader NHI cleanup?
• When should organisations prioritise workload identity controls over more user-focused IAM work?
• When should organisations prioritise runtime guardrails over model-focused AI controls?
• How can teams tell whether AI-driven fraud controls are keeping up?