What breaks when merchants rely on human fraud models to classify AI agent traffic?

Why This Matters for Security Teams

Merchant fraud stacks were tuned around humans: a person logs in from a relatively stable device, moves through predictable journeys, and leaves behavior patterns that can be scored over time. AI agents break that assumption. They can act at machine speed, rotate infrastructure, chain tools, and generate traffic that looks abnormal by human standards even when it is fully authorized. That makes classification the hard problem, not just detection.

This is why AI agent traffic cannot be safely forced through the same rules used for card testing, credential stuffing, or bot mitigation. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to the same operational issue: autonomy changes the threat model. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations already report agent actions beyond intended scope, which is exactly the kind of ambiguity merchant fraud systems are not built to resolve.

In practice, many security teams discover this only after legitimate automation has already been declined, investigated, or charged back as fraud.

How It Works in Practice

The practical failure is that human fraud models infer intent from proxies: device fingerprint, geolocation, session rhythm, typing cadence, and historical user behavior. AI agents often lack those signals or produce them in unstable ways. A procurement agent may submit orders from cloud infrastructure, a support agent may trigger repeated API calls in seconds, and a browser-using agent may look like a scripted bot one moment and a trusted service the next.

Security teams need to classify the workload, not just the traffic. That usually means binding requests to a workload identity, then making runtime decisions based on purpose, scope, and trust context. Standards such as SPIFFE and policy engines aligned to the CSA MAESTRO agentic AI threat modeling framework are more useful than static consumer-style fraud rules because they identify what the agent is and what it is allowed to do right now.

• Use short-lived, task-scoped credentials instead of long-lived API keys.
• Evaluate policy at request time with context, not just at onboarding.
• Separate authorized automation from anonymous or undocumented bot traffic.
• Log tool calls, data access, and downstream actions for audit and response.

NHIMG’s OWASP NHI Top 10 and Ultimate Guide to NHIs both reinforce that identity and privilege controls must follow the workload, not the user persona. These controls tend to break down when merchants rely on shared service accounts or third-party automation that cannot be cleanly tied to a single workload identity because attribution becomes too coarse for real-time authorization.

Common Variations and Edge Cases

Tighter bot and fraud controls often increase false positives, so organisations have to balance transaction friction against the risk of letting undocumented automation operate unchecked. That tradeoff is especially painful in merchant environments where growth teams, fulfillment tools, and AI assistants all touch the same checkout or account flows.

Best practice is evolving, and there is no universal standard for this yet. Some merchants will need allowlisted agent identities with strict scope limits, while others will need separate lanes for human, delegated, and fully autonomous activity. The key is to avoid collapsing all non-human traffic into one fraud bucket. A support agent doing low-risk lookup work should not be scored the same way as a browser automation agent placing orders or changing payment details.

Current guidance suggests combining runtime policy, ephemeral secrets, and step-up controls for high-risk actions. This matters most where agents can chain tools across products, because a benign first action can rapidly become a high-impact downstream transaction. For that reason, merchant teams should treat agent traffic as a distinct class of behavior, then review it against MITRE ATLAS adversarial AI threat matrix and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research when secrets, tokens, or delegated privileges are in play.

These controls tend to break down in legacy commerce stacks that cannot support workload identity, per-request policy evaluation, or fine-grained audit logging because there is no reliable way to distinguish approved agent actions from fraud.

Related resources from NHI Mgmt Group

• How should security teams classify AI agent traffic in fraud prevention flows?
• What breaks when AI agents are forced into human-style RBAC models?
• What breaks when AI agents are governed with human IAM, IGA, and PAM models?
• What breaks when AI agents and service accounts are forced into human directory models?