Bots are now more than half of web traffic, and most defenses moved to the cloud
Automated traffic now matches or exceeds human traffic on most public-facing sites. Scrapers harvest content and pricing; credential-stuffing bots test stolen passwords against login endpoints; carding bots validate stolen card numbers at checkout; AI scrapers crawl APIs to train language models. The traffic looks plausible: real-browser fingerprints, residential IP ranges, human-like request timing. And the cost of running these campaigns drops every year.
The industry's answer has been bot management platforms; almost all of them cloud SaaS. To work, they need your traffic, your fingerprints and your decisions to live on their network. For regulated industries or sovereign deployments, that's a structural problem. And most of these platforms work as black boxes: a score arrives, an action is taken, but the operator cannot inspect what the model actually weighed.
TR7 takes a different position. Bot defense runs on your platform; the scoring engine evaluates 46 named factors; the operator sees which signal weighed how much. The same content-aware rule engine that powers WAAP and API security applies here too — a bot rule can act on a value inside a JSON body without a single line of script.
Five things that set TR7 Bot Management apart
Each of these is valuable alone. Together, they redefine what bot defense looks like when it does not depend on someone else's cloud and does not hide its logic from the operator.
On-prem first — bot decisions stay on your platform
Most modern bot management platforms are SaaS — your fingerprints, your traffic and the resulting decisions live on their network. TR7 runs on your hardware. The bots arriving at your edge are scored and acted on inside your perimeter.
Transparent 46-factor scoring — not a black box
The bot score combines 46 named factors with named weights — TLS fingerprints, IP reputation across 25 categories, request rhythm, request shape, behavioral baseline and more. An operator can see which factors contributed to a decision, tune individual weights and explain a block in a security review. No opaque model output you cannot interrogate.
Content-aware rules — including JSON body values
The same content-aware rule engine used for WAAP and API security applies to bot policy. Rate-limit, challenge or block on header values, cookie contents, URL parameters and even values parsed from JSON request bodies. Example: a rule that throttles when the body's 'action' field is 'add_to_cart' and the source IP behavior matches scraper patterns. All configured visually; no scripting.
Per-vService sensitivity — login is not the same as static
The login endpoint of a site needs a different bot policy than the public-assets endpoint of the same site. Bot policy attaches to the vService, so each application surface gets the sensitivity it actually needs. One ruleset for /login, another for /api/v1/search, another for /assets/*.
Blocked bot traffic never counts toward your bill
Challenged requests, throttled scrapers, dropped credential-stuffing attempts and silent-dropped carding bots are all excluded from the bandwidth meter. The harder your bot defense works, the bigger the gap between throughput and billable bandwidth.
What TR7 Bot Management includes
Every capability below ships as part of the platform and attaches to your existing vServices.
Being a real, signed-in customer lowers your bot score
Most platforms only add suspicion. TR7 also subtracts it: a customer who has signed in through the access layer has 40 points taken off their bot score, and one who has solved a challenge has 20 taken off. This matters most on the worst day. When an attack starts and you tighten every threshold, the people you least want to catch — your logged-in customers — are the ones now furthest from the blocking line. Identity and protection share one engine here, which is the only way one can lower the other's score.
46-factor weighted bot scoring
Named signals combined with an exponential scoring curve tuned for low false positives — TLS fingerprints, IP reputation across 25 categories, request rhythm, request shape, behavioral patterns, recent error rates, session-creation rate, and more. Operator can see, tune and explain.
Being a real, signed-in person lowers your bot score
A verified AAM session subtracts 40 points from the score and a solved challenge subtracts 20. This is the concrete output of identity and protection running on the same engine, over the same session: when you tighten protections during an attack, your logged-in customers are not the ones who get caught. Platforms that keep access management and web protection in separate products cannot share that signal at all.
Seven of the signals come from the browser — and are judged on the appliance
Seven of the 46 factors describe the client's own environment: whether it declares automation, whether automation can be inferred from inconsistencies it did not think to hide, whether the rendering engine matches the browser it claims to be, how fast a form was filled compared with what a human hand can do, whether there was real interaction at all, how the session behaved, and whether it walked into a trap. Competing products collect this in the browser and send it to their cloud to be scored. Here it is collected in the browser and scored on your own appliance — no page content and no visitor telemetry leaves the building, which is what makes this usable in a closed network.
You can see why a request scored what it scored
Scores land in four classes — clean, suspicious, bot, bad bot — and each class has its own graduated action. Behind them is a chart that splits the score range into twenty bands, so one glance answers the real question: is my traffic gathered at the clean end, or is there a build-up near the top? And for any single request, the panel lists which factors pushed the score up and by how much. This is the difference between a verdict you have to trust and a verdict you can check — and it is what makes tuning possible, because you can see which factor is producing the false positive before you touch a threshold.
Network type as a bot signal — a datacenter is not a phone
Every source arrives already classified into one of 21 network types — major clouds, general hosting, CDN, verified bots, Tor exits, residential, mobile/CGNAT — and that classification is one of the factors the bot score is built from. A login attempt from a hosting range and the same attempt from a mobile carrier are not the same event, and the score says so before anyone writes a rule. The same vocabulary appears in the report, so an analyst reads why a session scored as it did, not merely that it did.
25 IP reputation categories
Source IPs classified across 25 categories — known scrapers, residential proxy pools, datacenter ranges, Tor exits, known bot operators and others. Categorisation feeds the score and can be acted on directly in policy.
Behavioral baseline adaptation
The scoring engine learns your application's normal traffic patterns over time. Anomalies stand out against the baseline rather than against an arbitrary global threshold.
Signature + behavior dual detection
Signature-based detection for known bot families with characteristic fingerprints. Behavioral detection for unknown bots, evasive scrapers and slow attempts. Both feed the same scoring decision.
Content-aware traffic rules
Rate-limit, challenge or block on any traffic attribute — header values, cookie contents, URL parameters, parsed JSON body values. Visual configuration; no proprietary scripting.
Mitigation actions — block, challenge, throttle, silent drop
Choice of action per policy. Block obvious malicious automation. Challenge ambiguous traffic with CAPTCHA. Throttle suspected scrapers without blocking outright. Silently drop credential-stuffing traffic so the attacker doesn't receive useful feedback.
Account takeover (ATO) defense
Credential-stuffing patterns on login endpoints recognised as distinct from generic abusive automation. Distributed low-and-slow attempts, impossible travel and abnormal session-creation rates surface here, not just under generic bot scoring.
Per-vService scoping with sensitivity tiers
Each vService can run a different bot policy. License capacity scopes to deployment size (1, 10, 100 vServices or unlimited).
Bot defense on access flows too — not only public web
The same scoring engine and rule logic run inside TR7's access management layer. SSO portals, login flows, identity-aware proxies and clientless gateway sessions get the same bot defense as public WAAP-protected applications — without standing up a separate bot engine for each surface.
Endpoint security signal integration
For B2B and corporate-access scenarios where users connect from devices managed by TR7's endpoint security layer, device-trust signals — known device, current posture, compliance state — feed the bot scoring engine as an additional weighted factor.
AI scraper and agent traffic handling
AI scrapers crawling for training data have characteristic patterns — high-volume sequential traversal, atypical user-agent strings, unusual API call shapes. The behavioral engine recognises these patterns; policy decides whether to allow, throttle or block per use case.
Integration with WAAP, DDoS and API security
Bot signals feed WAAP rules and L7 DDoS thresholds; WAAP and DDoS signals feed bot scoring. A source seen abusing one application surface raises the score on every other surface immediately.
Managed signature and reputation updates
Bot signature library and IP reputation feeds update continuously — no manual download cycle, no version skew between sites.
CWE, CAPEC and MITRE ATT&CK mapping
Bot detections map to the same security taxonomy as the rest of WAAP — CWE codes, CAPEC patterns, MITRE ATT&CK techniques. SIEM correlation and incident response use the same language.
Full visibility and audit
Every bot decision logs with the contributing signal breakdown — which factor weighed how much, why the score landed where it did. Investigations and tuning happen in the same console as WAAP and delivery.
Bot types defended
Bot traffic is not one thing. TR7 Bot Management covers the modern spectrum of automation that targets web applications and APIs.
Web scrapers
Bots harvesting content, pricing, product catalogs, listings or other public data at scale. Detected by request rhythm, IP reputation, behavioral baseline drift and characteristic request shapes.
Credential stuffing
Bots testing stolen username/password pairs against login endpoints. ATO detection plus per-endpoint policy identify and stop distributed credential-stuffing campaigns that single-IP rate limits miss.
Carding bots
Bots validating stolen card numbers at checkout endpoints. Recognised by characteristic request rhythm against payment APIs and abnormal failure-to-success ratios.
Content theft and inventory scrapers
Automated competitors copying product listings, descriptions, reviews and pricing data. Behavioral baseline catches scrapers that mimic human pace by alternating fast and slow request rates.
AI scrapers and unauthorised training crawlers
Crawlers harvesting content to train language models without permission. Recognised by high-volume sequential traversal patterns and atypical client signatures; policy decides allow / throttle / block per use case.
Spam and form-abuse bots
Bots submitting fake registrations, comment spam, fake reviews and abusive form submissions. Combined detection through bot scoring and content-aware rules on form-body shape.
DDoS-class bot floods
High-volume bot traffic acting as application-layer DDoS — credential-stuffing waves, scraper farms, coordinated IoT botnet floods. Bot signals feed the L7 DDoS layer for combined mitigation.
Vulnerability scanners
Bots probing the application for known CVEs, exposed admin endpoints, default credentials and misconfigured services. Combined detection through bot signals and WAAP signature engine.
Where this outcome shows up
E-commerce — flash sales and carding
Real shoppers spike during flash sales; carding bots try to hide in the spike. Per-vService policy, behavioral baseline and content-aware rules separate real customers from credential-stuffers and carding bots without blocking actual buyers.
Banking — credential stuffing on login
Login endpoints under constant credential-stuffing pressure. ATO detection recognises distributed low-and-slow attempts that single-IP rate limits miss; CAPTCHA challenge is applied selectively, not to every legitimate user.
Publishers and media — content scraping at scale
Articles, videos and image libraries crawled by competitors and AI training scrapers. Behavioral baseline catches scrapers that mimic human pace; policy decides whether scrapers get blocked, throttled or allowed under licensing.
Public APIs under abuse
API endpoints subject to scraping, credential testing and resource abuse. Per-endpoint bot policy plus the content-aware rule engine handle abuse without affecting legitimate API consumers.
Government portals — bot-driven fraud attempts
Public-sector services targeted by automated form-abuse and bot-driven fraud. On-prem deployment keeps citizen-data flows inside the perimeter; audit logging supports investigation.
B2B SaaS — managed-device traffic with elevated trust
When B2B users access from devices managed by your endpoint security layer, device-trust signals feed the bot score — known managed device + good posture lowers suspicion. Bots arriving from unmanaged endpoints still get full inspection.
Features that implement this solution
Capabilities referenced by this solution — the technical pieces that compose the controls described above.
Continuous Trust Evaluation
Trust earned at login doesn't carry forever. Every session stays under evaluation, every step of the way.
Traffic Quarantine
Observe behavior instead of blocking instantly — isolate sources that exceed a threshold and release them automatically.
WAAP Attack Reporting
3000+ rules, OWASP / API Top 10 / CWE taxonomy, 14 correlation axes, per-host-group + cross-group rollups.
Self-Hosted CAPTCHA
Generation, delivery and verification — all inside the ADC. Zero calls to any third-party cloud service.
Account Takeover Protection
Stop credential stuffing, brute-force and session hijacking attempts based on combined risk decision — not a single signal.
Rate Limiting
One IP, one account, one API key — you decide which dimension to limit.
Login Attack Protection
Three tiers of graduated friction — warn, challenge, lock — across IP, username, or both. Self-hosted CAPTCHA, no external cloud.
Session Protection
From session ID generation to cookie security, IP+UA binding to idle and absolute timeout — protect every session under one policy graph.
Common questions
How is this different from a generic WAAP?
Will this block legitimate customers?
Do I need a client-side SDK in my consumer mobile app?
Can a bot rule act on the contents of a JSON request body?
What mitigation actions are available?
Does the bandwidth model exclude blocked bot traffic?
How is the bot scoring different from competitors' machine learning?
Does TR7 do bot management only on public web traffic?
Bot defense that explains itself — on your platform
Request a live demo of TR7 Bot Management. We will run scoring on real traffic, walk through the 46 factors and show how content-aware rules act on JSON body values without scripting.