What should organisations do when AI agents become part of the fraud problem?

Why This Matters for Security Teams

When AI agents enter fraud workflows, the problem changes from isolated bad transactions to machine-speed abuse that can probe, adapt, and repeat across channels. Static thresholds and human-tuned review queues struggle because an agent can vary amount, timing, device signals, and narrative faster than analysts can tune rules. That is why current guidance suggests treating agent activity as a distinct risk class, not just a faster version of user behaviour. The AI Agents: The New Attack Surface report found that 80% of organisations reported agent actions beyond intended scope, including unauthorised system access and credential exposure.

Fraud teams also need to account for the fact that agents can chain tools, reuse context, and trigger downstream actions that look legitimate in isolation. The relevant security question is not only whether the account is trusted, but whether the action is justified at that moment. That is where machine-time reviews, context-aware controls, and stronger provenance become more effective than legacy case management. In practice, many security teams encounter agent-driven fraud only after the loss pattern has already become too noisy for human triage to separate signal from automation.

How It Works in Practice

The practical response is to move from static approval logic to layered, runtime decisioning. A fraud control plane should evaluate the request, the agent identity, the tool being invoked, the data being touched, and the transaction context before allowing completion. Best practice is evolving toward intent-based authorisation and short-lived credentialing, because an agent’s access should exist only for the task it is performing. That means using workload identity as the trust anchor, then issuing just-in-time secrets or scoped tokens that expire quickly after use.

Security teams should also separate detection from authorization. Detection can still flag patterns such as rapid retries, unusual decision paths, or tool chaining, but the response should not depend on a single static threshold. Instead, policies should be evaluated at request time using policy-as-code and a risk score that incorporates identity, device, transaction semantics, and historical behaviour. The logic is consistent with the direction set by the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

• Bind each agent to a distinct workload identity rather than a shared service account.
• Issue per-task tokens with tight TTLs and automatic revocation.
• Require step-up checks when the agent attempts high-risk actions such as payments, beneficiary changes, or account recovery.
• Log every tool call and decision input so investigators can reconstruct the chain of actions.

NHIMG’s research on the OWASP NHI Top 10 reinforces that compromised non-human identities often become the shortest path from initial access to repeated abuse. These controls tend to break down when agents share credentials across workflows because one compromise can instantly inherit the trust of many downstream actions.

Common Variations and Edge Cases

Tighter fraud controls often increase friction, so organisations have to balance abuse prevention against customer experience and operational overhead. That tradeoff is especially visible when legitimate agents handle customer service, reimbursements, or exception processing, where too many prompts can slow throughput. There is no universal standard for this yet, but current guidance suggests reserving the strongest controls for actions with irreversible impact, financial value, or account recovery power.

Edge cases matter because not every agent is fully autonomous. Some agents only draft decisions, while others execute transactions directly, and the control posture should reflect that difference. Human-in-the-loop review remains useful for high-value or ambiguous cases, but it should be backed by machine-speed telemetry and replayable audit trails. Teams should also watch for fraud rings that use multiple agents with narrow roles, since compartmentalised automation can look benign until the pieces are combined. NHIMG’s AI LLM hijack breach analysis shows how quickly compromised identities can be turned into repeated abuse paths once the attacker reaches a working execution loop. Where agents operate across vendors, jurisdictions, or payment rails, controls often fragment because no single team owns the full action chain.

Related resources from NHI Mgmt Group

• When does an AI agent become a privileged access problem?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• When is it crucial to implement least-privilege access for AI agents?