AI agent identity is reshaping customer traffic and fraud control

At a glance

What this is: This is an analysis of customer-facing AI agent traffic and its key finding that identity and intent, not simple automation, now determine whether the interaction should be allowed.

Why it matters: It matters because IAM, fraud, and digital experience teams must govern delegated machine-to-business interactions without collapsing legitimate customer journeys into generic bot blocking.

By the numbers:

• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Transmit Security's analysis of AI agent identity and customer traffic governance

Context

AI agent identity now sits at the intersection of customer experience, fraud control, and access governance. These systems act on behalf of real users, but they are not the same as human users and they are not ordinary bots, which means legacy edge controls often fail to describe what they are seeing or why the traffic matters.

For identity teams, the challenge is not simply to detect automation. It is to establish whether an agent is acting for a legitimate customer, whether its behaviour is consistent with the customer’s intent, and whether policy can be applied without damaging conversion or creating a blind spot for abuse.

That makes this a governance problem as much as a security problem. The article's starting position is increasingly typical for consumer-facing digital businesses, but the operational consequences are especially acute in retail, travel, financial services, and insurance.

Key questions

Q: How should security teams govern customer-facing AI without blocking useful interactions?

A: Put governance in the request and response path so the system can inspect prompts, classify intent, and apply policy before anything reaches the customer. Use graduated actions such as warn, route, block, or allow, and keep a clear audit trail so Legal, Security, and operations can review what the AI did and why.

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

A: Traditional bot controls assume automated traffic is inherently suspicious, so they optimise for blocking. Customer AI agents break that assumption because they can be automated, legitimate, and aligned to a real user’s intent. When identity and intent are not visible, the organisation either blocks revenue-generating journeys or misses abusive behaviour that looks superficially normal.

Q: What should IAM and fraud teams measure for agent-driven traffic?

A: They should measure the share of traffic driven by agents, the journeys those agents concentrate on, and whether the same interactions are beneficial, unknown, or malicious. Those three signals show whether the organisation is dealing with a niche phenomenon or a material shift in customer access patterns. They also tell teams where policy tuning will matter most.

Q: Who should own governance for customer AI agents?

A: Ownership should be shared across IAM, fraud, digital experience, and application security, because the problem spans identity, trust, conversion, and abuse prevention. A single control team will miss part of the risk. The accountable group should define policy states, evidence standards, and escalation paths for delegated machine activity.

Technical breakdown

Why customer AI agents break traditional bot management

Traditional bot management was built around a binary model. Traffic was either human or automated, and automation was usually treated as undesirable. Customer AI agents break that model because they are automated but can still be legitimate, authorised by a real person, and aligned to a purchase or comparison task. That means automation alone is no longer a reliable indicator of risk. The identity question shifts from "is it a bot?" to "who does it represent, and what is it trying to do?" In practice, this requires a richer trust signal than fingerprinting or rate limiting can provide.

Practical implication: teams need identity-aware traffic classification, not just automation detection, before they can write meaningful policy.

Identity and intent as the new control surface

The control surface moves upstream from edge blocking to decisioning on identity, purpose, and behaviour. An agent that is researching products for a genuine customer may deserve a different policy path than one attempting account abuse, scraping, or fraudulent checkout automation. That means intent becomes an operational signal, not a marketing concept. The governance model must be able to classify whether the interaction is beneficial, unknown, or malicious, then decide what friction is appropriate. Without that distinction, every control becomes a blunt instrument and every exception becomes a risk.

Practical implication: define policy states for legitimate, unknown, and abusive agent traffic, then map each state to a different response.

Why visibility is a prerequisite for policy

You cannot govern a population you cannot see. Visibility into which agents are accessing applications, how much traffic is agent-driven, and which journeys agents prefer is the prerequisite for any policy that is more precise than blanket allow or deny. That visibility is also what lets teams separate customer-driven delegation from adversarial automation. Once the organisation can identify the agent population, policy can move from reactive blocking to measured governance that protects revenue and reduces abuse. This is the difference between managing anonymous automation and managing a new identity class.

Practical implication: instrument agent discovery, journey-level analytics, and intent classification before attempting fine-grained controls.

Threat narrative

Attacker objective: The objective is to use delegated automation to gain transaction advantage, abuse customer journeys, or extract value faster than human-paced controls can respond.

1. Entry occurs when an AI agent legitimately reaches customer-facing applications through approved channels and behaves like a delegated user rather than a conventional bot.
2. Escalation follows when the organisation cannot distinguish customer intent from abusive automation, allowing machine-speed activity to continue without a reliable policy boundary.
3. Impact is revenue loss, fraud exposure, and a degraded customer journey, because the business either blocks legitimate demand or accepts unauthorized automation at scale.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Customer AI agents create an identity class, not just a traffic class. Treating them as generic automation misses the core governance shift. These agents act on behalf of real people, but their runtime behaviour, provenance, and intent can diverge sharply from the human they represent. The practical conclusion is that identity programmes must classify delegated machine activity as a distinct governance population, not as an edge-case variant of bots.

Bot management assumptions fail when automation can be legitimate. Traditional controls assume automated traffic is unwanted by default. That assumption collapses when a customer’s assistant is expected to price, compare, and transact on the customer’s behalf. The implication is not to abandon bot controls, but to stop using binary automation logic as the primary trust decision for customer-facing journeys.

Identity and intent are now inseparable in digital commerce. If an organisation cannot determine who an agent represents and what it is trying to achieve, every policy decision becomes either overblocking or underprotection. That is why governance for AI agents belongs alongside fraud, IAM, and customer access policy, rather than in a standalone niche team.

Visibility is the named concept that governs the whole problem. Without agent visibility, organisations cannot size the traffic, identify the journeys under pressure, or separate legitimate delegation from abuse. This is the same failure mode that appears across non-human identity programmes: you cannot govern what you cannot name, inventory, or classify. Practitioners should treat visibility as the first control boundary, not a reporting metric.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface.
• That gap is why practitioners should also review OWASP Agentic AI Top 10 for the control failures most likely to surface as delegated machine traffic scales.

What this signals

Identity-aware traffic governance will become a core part of customer access strategy. As delegated agents move from edge-case to routine, teams that only think in terms of human versus bot will misclassify legitimate demand and miss abusive automation. The practical shift is toward policy engines that can reason over intent, provenance, and journey context, not just request volume.

Many programmes still lack the observability needed to govern this class at all. With only 52% of companies able to track and audit the data their AI agents access, the other half cannot reliably answer basic compliance or incident questions. That makes agent visibility a prerequisite for both fraud investigation and access governance, not a nice-to-have reporting layer.

If this topic is entering your roadmap, use it to tighten the boundaries between IAM, fraud, and digital experience teams. The organisations that move first will define the operating model for delegated machine-to-business interactions rather than inheriting one by accident.

For practitioners

• Define a customer agent identity category Create a distinct classification for delegated AI agents in IAM and fraud workflows, separate from human users and conventional bots. Use that category to drive policy, monitoring, and escalation logic instead of collapsing everything into automated traffic.
• Map policy to intent states Build three explicit response paths for legitimate, unknown, and abusive agent behaviour. That lets teams preserve conversion for valid customer assistance while tightening controls when behaviour drifts toward scraping, fraud, or unauthorized automation.
• Instrument agent visibility across key journeys Track which AI agents are accessing the application, what share of traffic they represent, and which customer journeys they concentrate on. Start with pricing, availability, and checkout because those are the highest-value decision points.
• Review edge controls for overblocking Test whether current bot and anti-abuse controls are rejecting legitimate customer delegation. Where they are, add identity-aware exceptions or secondary policy signals so security controls do not suppress valid business demand.

Key takeaways

• Customer AI agents are forcing identity teams to govern delegated machine activity as a distinct access population, not as ordinary bot traffic.
• The practical risk is not just abuse, but also overblocking legitimate customer journeys when identity and intent are invisible.
• Teams need visibility, intent classification, and policy states before they can manage agent-driven traffic without breaking conversion.

Key terms

• Customer AI agent: A customer AI agent is a software entity acting on behalf of a person to research, compare, or transact with a business. In identity terms, it behaves like a delegated non-human identity and therefore needs classification, policy, and visibility, not just bot blocking.
• Delegated Machine Action: Delegated machine action is work performed by an AI agent under authority inherited from a human or system sponsor. The identity remains non-human, but the accountability path still traces back to the original delegate. In practice, this makes runtime behaviour, not just issuance, the governance concern.
• Identity-aware traffic classification: Identity-aware traffic classification is the practice of deciding whether a request is human, benign automation, delegated assistance, or abuse. It adds identity and intent signals to basic traffic analysis so teams can make policy decisions that protect security without suppressing valid business journeys.
• Agent visibility: Agent visibility is the ability to identify which AI agents are interacting with applications, how much traffic they generate, and what they are trying to do. It is the minimum prerequisite for governing delegated machine access because policy cannot be applied safely to an unknown population.

What's in the full article

Transmit Security's full article covers the operational detail this post intentionally leaves for the source:

• How the vendor distinguishes beneficial, unknown, and malicious agent behaviour in practice
• Operational questions for sizing agent-driven traffic across customer journeys
• Examples of how policy can allow legitimate customer assistants without opening abuse paths
• The specific intelligence layer the vendor says is needed to govern agent interactions

👉 The full Transmit Security article covers the visibility model, intent questions, and control balance for customer-facing AI agents.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.