Why do classic fraud controls miss malicious or hijacked AI agents?

Why This Matters for Security Teams

Classic fraud tooling was designed to spot obvious automation, replay, or device anomaly patterns. Malicious or hijacked AI agents do not always look like bots at the point of authentication, because they may inherit a valid session, a trusted device posture, or an approved workflow. That makes them much harder to separate from legitimate activity using static signals alone.

The risk is not just impersonation. An agent can chain tools, call APIs, and continue operating after the original prompt, user, or operator intent has drifted. NHI Management Group research on AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have already acted beyond intended scope, while only 44% have implemented any policies to govern them. That gap shows why surface-level fraud checks are often too shallow for agentic workloads. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward context-aware controls instead of trust based only on a successful login.

In practice, many security teams discover the weakness only after an agent has already moved money, copied data, or triggered downstream actions that look legitimate in audit logs.

How It Works in Practice

Fraud controls miss these incidents when they assume the actor is either a human or a script with predictable patterns. A hijacked agent often enters through a valid identity path, then behaves dynamically enough to stay inside normal thresholds while still doing harmful work. That is why classic bot checks, risk scoring, and session reputation are useful but insufficient on their own.

Practitioner guidance is shifting toward runtime authorisation, workload identity, and short-lived access. Instead of asking only whether the session looks trusted, teams need to ask what the agent is trying to do right now, whether that action fits the task, and whether the agent should be allowed to continue at that moment. The operational pattern is:

• Issue identity to the workload, not just to the login session, using cryptographic workload identity where possible.
• Grant short-lived, task-specific credentials rather than static secrets that remain usable after compromise.
• Evaluate permissions at request time with policy-as-code, so the agent’s current tool call, data request, and destination all matter.
• Revoke access automatically when the task ends, the context changes, or the agent deviates from approved behaviour.

This is consistent with the direction of the CSA MAESTRO agentic AI threat modeling framework and with the runtime-risk emphasis in the MITRE ATLAS adversarial AI threat matrix. It also aligns with NHIMG coverage of compromise patterns in the AI LLM hijack breach, where stolen credentials and trusted execution paths enabled abuse that would not have been caught by simple fraud heuristics alone.

These controls tend to break down in environments where agents can silently inherit broad human permissions, because the fraud stack sees a legitimate session while the real risk sits in what the agent can reach next.

Common Variations and Edge Cases

Tighter runtime controls often increase friction, latency, and engineering overhead, requiring organisations to balance faster agent execution against stronger containment. That tradeoff is real, especially when agents operate across many APIs, vendors, or business units.

There is no universal standard for this yet, and current guidance suggests different levels of rigor depending on the autonomy of the workload. A customer support assistant that drafts replies is not the same as an agent that can approve payments, modify cloud resources, or open tickets that trigger production changes. The more autonomous the system, the less reliable it is to base fraud decisions on a single login event or device fingerprint.

Edge cases also matter. A valid human session can be taken over mid-stream, a delegated agent can receive broader access than intended, or a chain of tool calls can create damage even when each individual action looks normal. In those cases, static thresholds and bot scores often miss the attack because the agent is not behaving like a bursty fraud bot. NHIMG’s Moltbook AI agent keys breach underscores how exposed agent credentials can become the real control failure, not just a fraud signal.

For teams formalising governance, the practical answer is to combine fraud detection with NHI controls, agent policy review, and continuous verification. That is the direction reflected in the NIST AI Risk Management Framework and the OWASP NHI Top 10.

Related resources from NHI Mgmt Group

• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?