Defence has to move beyond static detection and into runtime friction. Teams should instrument the client, monitor repeated UI probing, and challenge suspicious navigation, permission loops and emulated device behaviour. The goal is to make abuse expensive to repeat, even when an attacker can regenerate the workflow after each app change.
What changes when the fraud workflow is agentic rather than scripted?
Agentic fraud changes the defender’s problem from blocking a fixed sequence to disrupting a workflow that can adapt after each failure. A mobile app may be probed through many navigation paths, repeated permission prompts, or device-emulation attempts until the attacker finds one that works. Defence therefore needs to raise the cost of repetition, not just spot a single bad request.
That is why the app should be treated as an active part of the control plane, with client-side telemetry and challenge paths that can react to suspicious state transitions. The important question is not whether one workflow instance looks malicious, but whether the same actor can keep iterating cheaply enough to learn the app’s behaviour.
Which signals matter inside the app?
Mobile fraud workflows often leave behavioural traces before they trigger a classic security alert. Repeated UI probing, rapid back-and-forth navigation, scripted permission churn, and device signals that do not match human interaction patterns are all useful because they reveal an adaptive test cycle rather than a one-off action. Teams should watch for sequences, timing, and consistency across sessions, not just isolated events.
Instrumenting the client helps because the app can observe context that backend controls often miss, such as screen flow, focus changes, permission loops, and whether the device appears to be genuinely rendering and interacting. The goal is to distinguish ordinary user friction from repetitive automation that is searching for a weak path.
How should the app respond without breaking legitimate users?
Defence works best when it adds friction selectively. Suspicious sessions can be challenged with step-up verification, harder navigation paths, tighter rate limits, or temporary containment while the risk signal is re-evaluated. The response should slow iteration enough that regeneration becomes expensive, but it should not turn every unusual interaction into a hard block.
That balance matters because agentic fraud will often reuse the same intent with slightly different execution. If the control only blocks one exact pattern, the attacker can retry with a new workflow. If the control is too aggressive, legitimate users inherit the friction. The right design is adaptive, targeted, and measurable.
Risk and Threat Considerations
Agentic fraud workflows create a repeatable abuse path: once the attacker learns which UI actions, device traits, or permission sequences get through, they can regenerate the workflow and keep testing until the app yields. That makes brittle, one-shot detection especially weak, because the adversary is not dependent on one stable signature.
Failure mechanism: The app treats each attempt as independent, so it misses the cumulative pattern of probing, adapts too slowly to repeated navigation and permission loops, and leaves emulated device behaviour insufficiently challenged.
Impact: Attackers can scale account abuse, automate conversion fraud, or refine their workflow after every app change, which increases both direct loss and the defender’s operational burden.
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 ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agentic fraud workflows exploit app flows and actions as abuse tools. |
| ASI03 — Identity & Privilege Abuse | Fraud workflows often exploit over-permissive action paths and session misuse. | |
| ASI10 — Rogue Agents | The defender faces autonomous or semi-autonomous abuse loops that regenerate after failure. | |
| Recommendation — Instrument and constrain app actions that can be repeatedly abused in automated workflows. Enforce per-action checks and step-up controls when a session shows abnormal privilege use. Design detections to persist across retries and sessions, not just single workflow instances. | ||
| MITRE ATT&CK | T1621 — Multi-Factor Authentication Request Generation | Permission loops and repeated prompts resemble adversary abuse of interactive approval flows. |
| Recommendation — Monitor for repeated approval or prompt cycles that indicate automated abuse of interactive trust. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Behavioural detection depends on analysing app and session telemetry for repeated probing patterns. |
| Recommendation — Review session telemetry for repeated navigation, permission churn, and emulated-device indicators. | ||
Practitioner Guidance
What to prioritise: Build controls that observe session behaviour over time, not just request validity at a single endpoint. The most useful signals are repeated flow exploration, inconsistent device traits, and challenge bypass attempts that recur across sessions.
What to verify: Confirm that suspicious sessions can be stepped up, slowed, or redirected without breaking the core user journey. The control is working if the attacker’s iteration cost rises while legitimate users still complete essential tasks.
Practitioner takeaway: Treat mobile fraud defence as an adaptive control problem, not a signature problem, because the attacker’s advantage comes from being able to regenerate the workflow faster than your static detections can be updated.
Related resources from NHI Mgmt Group
- How should security teams defend against deepfake fraud in executive approval workflows?
- How should security teams protect mobile apps against AI-assisted reverse engineering?
- How should security teams defend browser-based identities against account takeover in SaaS and AI workflows?
- How should security teams defend AI coding workflows against poisoned instruction files?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org