Notifications
Clear all
Topic starter
01/08/2026 8:53 pm
TL;DR: AI agents are increasingly acting on behalf of customers to research, compare, and transact, creating a governance problem that sits between fraud prevention and conversion, according to Transmit Security. The real issue is not whether to block automation, but whether organisations can identify agents, understand intent, and apply policy without breaking legitimate journeys.
NHIMG editorial — based on content published by Transmit Security: analysis of AI agents acting on behalf of customers and the governance gap they create
By the numbers:
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Map policy to intent states Build three explicit response paths for legitimate, unknown, and abusive agent behaviour.
- 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.
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
👉 Read Transmit Security's analysis of AI agent identity and customer traffic governance →
AI agent identity and customer traffic control: what teams need now?
Explore further
01/08/2026 9:02 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity is reshaping customer traffic and fraud control
