How should security teams stop agentic AI fraud without blocking real users?

Why This Matters for Security Teams

agentic ai fraud is not just a stronger form of bot abuse. The risk changes because an agent can adapt, retry, chain tools, and vary its behaviour faster than static rules can keep up. That means account age, device reputation, and simple velocity checks are useful, but they are not sufficient on their own. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points toward runtime governance, not just perimeter screening.

For NHI Management Group, the practical issue is balancing fraud resistance with user experience. Security teams need to catch machine-paced campaigns without turning every high-intent customer into a suspect. That is why behaviour inside the session matters: how requests are sequenced, whether the transaction intent changes mid-flow, and whether retries look human or automated. The same lens is visible in NHIMG research on AI LLM hijack breach, where compromised identities are used for rapid abuse rather than slow, obvious misuse.

In practice, many security teams encounter agentic fraud only after funds are moved, accounts are drained, or trust scores have already been manipulated, rather than through intentional detection design.

How It Works in Practice

The most reliable pattern is layered, context-aware decisioning. Start with onboarding risk, but do not stop there. At login and during the session, score the request stream for properties that humans rarely sustain: perfect retry timing, unusually fast form completion, repeated navigation loops, and tool-like behaviour that changes in response to friction. This is especially important when agents are operating through real customer accounts, because the account itself may be legitimate even while the behaviour is not.

Security teams are increasingly combining session telemetry with transaction intent checks. Intent-based review asks whether the user is trying to do something consistent with prior behaviour, current context, and account history. If the intent suddenly shifts from browsing to bulk checkout, from normal transfer sizes to maximum-value transfers, or from one destination to many, the system can trigger step-up verification, out-of-band confirmation, or temporary hold. The same logic applies to autonomous assistants and workflow agents, where request-time policy evaluation is more effective than static RBAC alone. As the CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix both suggest, the attack surface is behavioural and adaptive.

• Use onboarding signals to separate obviously high-risk traffic from normal customers.
• Evaluate session pacing, retry shape, and step transitions in real time.
• Compare transaction intent against historical behaviour and current context.
• Apply step-up review only when risk crosses a defined threshold, not on every anomaly.
• Log every decision so fraud analysts can tune false positives and policy drift.

NHIMG research on the OWASP NHI Top 10 reinforces the broader point: identity signals alone do not explain intent, so they must be combined with live behaviour. These controls tend to break down in highly automated customer journeys, where normal users also complete actions in bursts and can resemble scripted activity.

Common Variations and Edge Cases

Tighter fraud controls often increase friction, requiring organisations to balance customer conversion against false-positive risk. That tradeoff becomes harder in environments with power users, API-first customers, or accessibility tooling, because legitimate behaviour can look machine-paced. Current guidance suggests using adaptive thresholds rather than universal blocks, but there is no universal standard for this yet.

One common edge case is delegated action. A human may authorise a workflow agent, browser assistant, or payment helper to act on their behalf, which means the system must distinguish between authorised automation and unauthorised fraud. Another is device sharing, where multiple people or roles use the same endpoint and session fingerprints lose value quickly. In these cases, policy should weight transaction context, step-up challenge results, and recent approval history more heavily than a single risk score. For deeper threat context, NHIMG’s LLMjacking research and the vendor’s first AI-orchestrated cyber espionage campaign report show how quickly automated abuse can pivot once a session is trusted.

The best operating model is not to block real users by default, but to reserve hard blocks for repeated abuse, impossible intent shifts, or confirmed automation that bypasses step-up controls. That keeps the experience usable while still shrinking the window for agentic fraud.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams use AI in secret scanning without creating new blind spots?
• How should security teams monitor AI agent activity without disrupting developers?
• How should security teams stop AI agents from using approved tools to exfiltrate data?