TL;DR: Agentic traffic now shows up as both legitimate customer automation and malicious fraud operations, and the same login flows must distinguish population and intent in real time, according to Arkose Labs. The old bot-or-human model is collapsing under shared tooling, behavioural similarity, and the growth of AI-driven sessions, so classification is becoming the control plane, not just detection.
At a glance
What this is: This analysis argues that login protection now has to classify agentic traffic by population and intent, because the old bot-versus-human model no longer cleanly separates legitimate AI use from fraud.
Why it matters: IAM, fraud, and identity security teams need a control model that can govern human users, consumer agents, and malicious automation without shutting down legitimate AI-assisted journeys.
By the numbers:
- Traffic from AI sources to US retail sites grew 393% year over year in the first quarter of 2026.
- Salesforce put the number at roughly $262 billion of online spend influenced by AI and agents over the 2025 holiday season.
👉 Read Arkose Labs' analysis of agentic traffic, intent classification, and login trust
Context
Agentic traffic is what happens when software acting for a user, or against a platform, reaches login, signup, checkout, or account-recovery flows with browser-like behaviour. The security problem is not whether the session is automated. It is whether the session should be trusted, because legitimate AI assistants and malicious fraud tooling now share the same delivery infrastructure and often the same observable signals.
That shift matters for identity governance because the control question is no longer just authentication, but classification and authorization at session time. Existing bot management, device fingerprinting, and threshold-based blocking were built for a simpler world in which the main decision was whether to stop a bot. The current problem is deciding how to treat an agent that may be acting on behalf of a real customer, a fraud ring, or both.
Key questions
Q: How should security teams classify agentic traffic at login without blocking legitimate users?
A: Treat classification as a trust decision based on population, intent, and workflow sensitivity. Distinguish self-disclosing agents, non-disclosing agents, and malicious automation, then apply different responses per endpoint. That approach preserves legitimate AI-assisted journeys while making abuse more expensive and easier to contain.
Q: Why do agentic sessions create more risk than ordinary automation?
A: Agentic sessions can represent either a real customer acting through software or a fraud operation using the same browser and cloud stack. That ambiguity breaks binary bot controls, because the same observable session may be legitimate in one context and harmful in another. The risk is not automation itself, but indistinguishable intent.
Q: What signals help identify malicious agents when fingerprints look clean?
A: Behavioural patterns are the most reliable signals in the hardest cases. Look for machine-paced timing, repeated screenshot-to-click loops, unusual answer bursts, and interaction rhythms that do not match human cognition. Those patterns often reveal local agents running on real devices even when the network footprint appears normal.
Q: Who should own policy decisions for agentic access to login and recovery flows?
A: Identity and fraud teams should share ownership, but the policy belongs inside identity operations because it is fundamentally an access decision. The question is not just whether to block traffic, but what type of actor may use a protected workflow and under what conditions. That makes governance, not only detection, the core issue.
How it works in practice
Why bot-versus-human detection breaks down for agentic traffic
Traditional bot management assumes the platform can separate human from automation with a score, a fingerprint, or a single decision threshold. Agentic traffic breaks that assumption because the same browser stack, cloud execution, and APIs can power both helpful consumer agents and malicious automation. The meaningful distinction is no longer just whether software is present, but what population it belongs to and what intent it is pursuing. That makes classification a runtime identity problem, not a pure anti-bot problem.
Practical implication: teams should stop treating bot scoring as the final decision and add intent-aware session classification.
How agent population and intent create a new identity layer
The article separates three agent populations: self-disclosing good agents, non-disclosing good agents, and malicious agents. Self-disclosing agents can identify themselves through standards and signatures, but many legitimate agents cannot or will not do so. Non-disclosing local agents are the hardest case because they run on a real user’s machine and look like ordinary browser activity until behaviour gives them away. This is why the identity layer now extends beyond the user to the acting software and its declared or inferred purpose.
Practical implication: build policies that vary by agent population, declared identity, and endpoint sensitivity instead of one global allow-or-block rule.
What behavioural fingerprints reveal about local and cloud agents
Cloud-hosted agents often expose data-center network traits and fail device checks, while local browser forks can reveal static rendering quirks. Local OS-level agents are harder because they drive a real browser, but their vision-reasoning-action loop creates timing and interaction patterns that humans do not produce. That loop is the key technical fingerprint: screenshot, reason, click, repeat. It is a behavioural signature of how the agent operates, and it can be measured inline even when network identity looks clean.
Practical implication: augment network and device checks with behavioural telemetry that can spot machine-paced interaction loops.
NHI Mgmt Group analysis
Classification is replacing detection as the primary control plane for agentic traffic. The article shows that bot-or-human scoring is too coarse for sessions that may be legitimate, malicious, or both at once. Once the same infrastructure can support consumer assistants and fraud automation, identity teams need population and intent as first-class decision inputs. The implication is that session control must move from a binary gate to a contextual trust decision.
Agentic traffic creates an intent problem that traditional IAM controls were never designed to answer. Access policy assumes the system knows who the subject is and why it is acting. Here, the same agentic path can represent a real customer, a credential attacker, or a fraud workflow, which means trust is no longer inferred from user presence alone. Teams must treat the login page as an identity decision point, not just an authentication checkpoint.
Behavioural telemetry is now part of identity assurance for consumer automation. The article’s emphasis on vision-reasoning-action loops shows why real-time behaviour matters more than static fingerprinting in the hardest cases. Where local agents run on real machines, the evidence shifts into timing, sequencing, and interaction rhythm. Practitioners should see that as a governance signal: machine-paced behaviour needs explicit policy, not retrospective suspicion.
Agent trust is becoming an access governance problem, not just a fraud tooling problem. When an organisation decides to allow, challenge, throttle, or block an agent, it is making an access decision about who or what may act in a protected workflow. That aligns this topic with identity governance, PAM-style policy, and session-level authorisation. The practitioner conclusion is that trust policy for agents belongs inside identity operations, not only in fraud operations.
Two populations can share one interface, but they cannot share one trust rule. The article’s central insight is that legitimate and malicious agents arrive through the same login page and often through the same technical stack. That breaks any governance model built on a single universal threshold. The practical conclusion is that identity programmes need differentiated controls per population and per workflow.
From our research:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, showing that scope control materially changes outcome.
- For a practical governance baseline, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that can be adapted to agentic access.
What this signals
Agentic traffic will force identity teams to own a new trust layer. The operational question is no longer whether automation exists, but how quickly a programme can classify it and route the right response. That is why policy design, not just detection tuning, becomes the decisive control for customer-facing flows.
With 70% of organisations already granting AI systems more access than they would give a human employee doing the same job, per the 2026 Infrastructure Identity Survey, the governance gap is already visible in entitlement practice. Teams that keep access rules static will keep discovering that their identity model is too human-centric for agentic behaviour.
For practitioners
- Map agentic exposure by workflow first Inventory login, signup, checkout, and account-recovery flows to determine where agentic sessions are already present and where they would cause the most harm. Use the agent-versus-human composition as a baseline before changing enforcement.
- Separate self-disclosing from non-disclosing agents Create different policy paths for agents that identify themselves and agents that do not, because declared identity is not the same as trustworthy identity. Apply lighter handling to cooperating agents and stricter verification to hidden automation.
- Add behavioural signals to your trust decision Use interaction timing, sequence patterns, and machine-paced loops alongside fingerprints and device checks, especially for local OS-level agents. The most revealing signals often appear in how the session moves, not in what it claims to be.
- Tune response by endpoint sensitivity Do not use one enforcement rule for all workflows. A content endpoint may tolerate a verified agent, while account recovery or money movement should face challenge or tighter review when agentic behaviour drifts from expectations.
Key takeaways
- Agentic traffic collapses the old bot-versus-human split because legitimate AI assistance and malicious automation now share the same technical paths.
- The operational distinction that matters is population and intent, not simply whether a session is automated.
- Identity teams should move from a single threshold model to workflow-specific trust policies that combine behavioural signals, endpoint sensitivity, and differentiated enforcement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic sessions and intent-based classification map directly to agent identity and tool-use risk. | |
| NIST AI RMF | AI governance is needed where autonomous-like behaviour affects access decisions and trust. | |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and session-level trust decisions are central to this article's governance model. |
Treat agent trust decisions as runtime controls and verify what the agent can do per workflow.
Key terms
- Agentic Traffic: Traffic generated by software acting on behalf of a user or purpose, often through browser automation, cloud execution, or AI-assisted workflows. In identity terms, the key issue is not automation itself but whether the actor should be trusted in a given workflow and under what policy.
- Non-Disclosing Agent: An agent that behaves like legitimate user activity but does not identify itself to the platform. These sessions are difficult because they often run on real devices and inherit normal browser characteristics, so the trust decision must rely on behaviour, context, and workflow sensitivity rather than declaration.
- Intent Classification: The process of inferring what an agent is trying to do, not just what it is. For identity teams, this matters because the same session can be acceptable for content retrieval and unacceptable for account recovery, credential stuffing, or payment abuse.
- Behavioural Fingerprint: A pattern of timing, sequencing, and interaction rhythm that reveals how a session operates. Unlike static device checks, behavioural fingerprints can distinguish machine-paced loops from human activity, especially when the agent runs locally on a real browser and network signals look normal.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.
This post draws on content published by Arkose Labs: Agent trust classification is becoming the new login control. Read the original.
Published by the NHIMG editorial team on 2026-05-11.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org