Why do traditional bot controls fail for AI agents acting on behalf of customers?

Why This Matters for Security Teams

Traditional bot controls were built to detect automation that is unwanted, high-volume, or clearly machine-like. Customer AI agents break that model because they can be legitimate, user-directed, and operationally valuable while still behaving like automation. That makes simple velocity checks, browser fingerprinting, and static reputation rules unreliable indicators of risk.

The practical issue is not whether the traffic is “bot” or “human,” but whether the request is authorised, bounded, and attributable at runtime. NHI Management Group’s research on OWASP NHI Top 10 shows how agentic systems expand the attack surface when identity, intent, and tool access are not jointly controlled. This aligns with the OWASP Agentic AI Top 10, which treats tool abuse and over-permissioning as core design risks rather than edge cases.

For security and fraud teams, the failure mode is often overcorrection: block the agent and lose conversion, or permit it and lose visibility into abuse, scraping, account takeover, or policy evasion. In practice, many security teams encounter customer-agent misuse only after abuse has already blended into normal customer journeys.

How It Works in Practice

Effective controls for customer AI agents shift from blocking automation to verifying workload identity, intent, and context at the moment of access. That means the organisation should not treat the agent as a generic browser or a static API client. Instead, it should bind the agent to a specific customer session, a declared purpose, and a narrow set of allowed actions.

Current guidance suggests a layered approach:

• Use workload identity as the primary identity primitive, so the agent can prove what it is before it receives access.
• Issue just-in-time, short-lived credentials for a single task, then revoke them automatically when the task ends.
• Evaluate policy at request time, not only at enrollment time, so access can change if the agent’s behaviour changes.
• Separate customer intent from device reputation, because legitimate agents may run from cloud infrastructure, serverless jobs, or hosted browsers.

Frameworks such as the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework both support runtime governance, bounded autonomy, and explicit accountability. NHI Management Group’s analysis of the CoPhish OAuth Token Theft via Copilot Studio illustrates why static allowlists are weak when an agent can chain actions across tools and approvals. The key control question becomes: is this agent acting within the exact customer intent that was authorised for this session?

These controls tend to break down when the customer journey depends on long-lived sessions, shared accounts, or legacy web workflows that cannot expose machine-readable intent and per-action policy checks.

Common Variations and Edge Cases

Tighter runtime controls often increase latency and integration overhead, requiring organisations to balance fraud resistance against customer experience and engineering complexity. That tradeoff is especially visible when customer AI agents interact with marketplaces, travel platforms, financial workflows, or support portals that were never designed for delegated autonomy.

There is no universal standard for this yet, but best practice is evolving toward intent-aware authorisation, step-up verification for sensitive actions, and explicit user consent for high-impact operations. In some environments, a customer agent should be allowed to browse and compare while being blocked from purchasing, transferring, or changing account settings without additional confirmation.

This is also where traditional bot signals become misleading. A low-friction agent may look benign because it mirrors ordinary usage patterns, while a malicious agent may look normal because it operates at human-like pace. NHI Management Group’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs research reinforces that credential abuse can move very quickly once an automated identity is exposed, and customer-facing AI systems should assume that abuse can adapt faster than static detection rules.

For that reason, the most durable approach is to govern the agent as an accountable workload, not as a suspicious bot. Where identity, intent, and privilege cannot be cleanly separated, organisations should limit the agent to read-only or low-impact actions until those controls exist.

Related resources from NHI Mgmt Group

• Why do AI agents create a different access-risk profile than traditional applications?
• 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?