In original answers to LDS, Jerome Segura clarifies the share of AI requests reaching login pages, the limits of homepage tests and the evidence developers need to evaluate bot defenses.
A login request from an AI agent might be part of an authorized task. It might also deserve investigation. Knowing that it is automated does not, by itself, tell a website operator which case they are dealing with.
In written answers to Lets Data Science, Jerome Segura, VP of Threat Research at DataDome, explains how to read the company's new bot-security findings without confusing traffic volume, bot detection and successful attacks. His answers also clarify a consequential percentage: login pages received just over half of the AI requests directed at a particular group of sensitive endpoints, not half of all AI traffic in the analysis.
DataDome's State of Bot & Agent Security Report, 2026 Edition combines customer traffic observed from July 2025 through June 2026 with a separate test of public websites. The company says the traffic study covers more than a trillion requests across over 75,000 customer sites. That is a substantial vendor dataset, but it is not a census of the internet.
The distinction between those datasets matters for developers deciding what to protect, what to allow and what evidence to collect.
The denominator changes the login-page story
LDS asked DataDome to reconcile wording in its supplied release with the endpoint analysis in the report. Segura confirmed three quantities for the first half of 2026:
- •29.02 billion AI requests had enough path-level information to be included in the endpoint analysis.
- •605.6 million requests , about2.1% of that total, reached endpoints DataDome classifies as high risk: login, forms, cart, payment and account creation.
- •313 million requests reached login pages. That is51.7% of the high-risk group , or about1.08% of all AI requests in this analysis .
Segura told LDS: "Worked through fully, login traffic is about 1.08% of total AI requests."
Both percentages can describe the same login traffic, but they answer different questions. One describes its share of a sensitive subset. The other describes its share of the full endpoint-classified dataset. Treating the first as the second would substantially overstate how much AI traffic reached login pages.
The report separately gives a broader first-half AI total of 29.65 billion requests. Segura said the smaller 29.02 billion figure includes only requests with enough path-level data for endpoint classification. The difference reflects scope, not an additional category of attacks.
Nor does reaching a login page establish malicious intent, use of stolen credentials or successful access to an account. The figures count requests. They do not count confirmed account compromises.
An open homepage is not a verdict on account security
In its separate June 2026 test, DataDome sent ten types of bot requests to the homepages of 21,491 websites. It classified 65.3% as "unprotected" because none of those requests produced an observable block or challenge.
LDS asked how that test distinguishes an absent defense from a deliberate decision to allow bots to read public content. Segura said it cannot. A site with no bot management, a site that intentionally permits crawling and a site that silently logs bots without blocking them can produce the same result.
Segura said: "This test also only covers homepages, not login pages or APIs, so it can't establish anything about the security of those surfaces for the 21,491 sites tested."
That answer places a clear limit on the statistic. It measures the response to specified requests at a public entrance. It does not show that 65.3% of the tested sites have insecure account systems.
The login-page findings come from DataDome's customer-traffic dataset, not from this homepage scan. Combining them into a claim about the login security of the scanned websites would join observations that the research did not make together.
Growth needs a comparable baseline
DataDome reports approximately 124% growth in traffic it classified as bad bots during the 12-month study period. LDS asked whether that comparison held customer sites and upstream filtering consistent.
Segura replied: "For the 124% bad-bot figure: no same-customer, filtering-controlled comparison exists, and we don't disclose whether the customer base and their sites were stable or changed over the 12 months."
The reported growth is therefore an observation in the vendor's dataset. The supplied evidence does not separate changing activity at the same sites from changes in the sites represented or the filtering applied before requests reached DataDome.
The annual homepage comparisons also use different samples. Segura said the tested population grew from roughly 14,000 websites in 2024 to 17,000 in 2025 and 21,000 in 2026. The latest test added spoofed AI agents and more advanced bot types. A harder test applied to a different set of sites cannot establish a precise deterioration at the same sites over time.
For an operator, the useful comparison is closer to home: the same sensitive endpoints, consistent definitions, and a record of policy or measurement changes alongside the traffic numbers.
Verify the agent, then check what it may do
Segura described public IP ranges, reverse DNS and signed requests using Web Bot Auth as ways to verify an agent's claimed identity. He also said its behavior must fit an approved user journey. Repeated attempts, unverifiable identity claims and activity involving stolen credentials warrant scrutiny.
These are descriptions of signals to investigate. The interview did not supply a worked incident with an independently verifiable classification or outcome.
The distinction between identity and permission remains essential. Cloudflare's Web Bot Auth documentation describes verifying signed requests against an agent's public key. Establishing which agent sent a request does not, by itself, establish that a particular user authorized it to access an account or complete a transaction. Those permissions still need to be enforced by the application.
Segura recommends that legitimate agents identify themselves verifiably and respect a site's stated crawling rules. When denied access, he said, they should back off rather than repeatedly retry. A site's crawling policy and its account permissions address different decisions; one should not be treated as a substitute for the other.
Three checks a small team can use
Segura recommends beginning with detection-only observation, introducing enforcement gradually and reviewing both legitimate traffic blocked by mistake and abusive traffic allowed through. He did not provide measured results showing how much this sequence reduces abuse or false positives.
For a team applying that advice, the following is an LDS practical checklist, not a tested outcome from the report:
- •Separate public reading from sensitive actions. Inventory login, account creation, payment and API routes alongside public pages. Record which actions need an authenticated user and what an agent is permitted to do. A homepage crawl should not stand in for a test of account access.
- •Record decisions as well as request counts. In controlled tests on systems you operate, check known legitimate sessions and clearly labeled abusive test cases. Record whether each was allowed, challenged, throttled or blocked, and whether the intended task completed. Keep sensitive credentials out of the evidence you retain.
- •Change a limited part of the policy, then compare. Track errors affecting legitimate users, successful authorized tasks and the specific abuse being tested. Record the endpoints, period and policy version so a later comparison has a meaningful baseline. Traffic volume alone is not a measure of protection.
The interview gives operators reasons to ask more precise questions of security reports and their own dashboards. The decision is not simply whether a request comes from a bot. It is whether the caller is who it claims to be, whether the requested action is permitted, and what the system actually observed.
Reporting note
This LDS Exclusive is based on six written answers supplied directly to Lets Data Science by Jerome Segura through DataDome's communications representative, together with the company's report and release provided under embargo. The DataDome report supplies the research figures; Cloudflare's documentation provides technical background on signed agent requests. LDS checked the reported arithmetic and the distinctions between the datasets. We did not independently inspect DataDome's underlying traffic, test its product or verify attack outcomes. The practical checklist is LDS analysis derived from the interview's measurement and access-control issues.
Key Points #
- 1Login pages received 51.7% of requests to high-risk endpoints, equivalent to about 1.08% of all AI requests in the endpoint analysis.
- 2DataDome says its homepage test cannot establish the security of login pages or APIs, or distinguish permitted crawling from absent defenses.
- 3The company has no same-customer, filtering-controlled comparison for its reported 124% growth in bad-bot traffic.
Scoring Rationale #
Original interview clarifies the AI-login denominator, limits of homepage testing and unmatched growth comparisons, with a practical measurement checklist explicitly labeled as LDS analysis.
Sources #
Original reporting, with the public references used alongside it.
LDS Exclusive
Reporting based on written answers given directly to Let's Data Science by Jerome Segura, VP of Threat Research, DataDome.
View 1 more source #
Practice with real Ad Tech data
90 SQL & Python problems · 15 industry datasets
[Active Search Campaigns by BudgetEasy](https://letsdatascience.com/problems/sql/active-search-campaigns-by-budget)
[High CPC Clicks & Poor Landing PagesMedium](https://letsdatascience.com/problems/sql/high-cpc-clicks-poor-landing-page)
[Campaign ROAS by Attribution ModelHard](https://letsdatascience.com/problems/sql/campaign-roas-by-attribution-model)
250 free problems · No credit card