Adaptive Bot Intelligence Without Vanilla AI Theater
StyloBot turns lots of small traffic signals into behavior memory: protocol quirks, session vectors, cross-request signatures, reputation, and policy feedback. LLMs can help at the edge, but the core intelligence comes from the runtime accumulating evidence about your traffic over time.
runs in your VPC, your data stays there
signals, deltas, action, policy
layered protocol + behavior signals
HMACed IDs + stripped UAs
What The Runtime Is Optimized For
Mechanism first. Claims second.
Low-Latency Decisions
Fast-path detectors run inline and stay cheap enough for hot traffic. Heavier analysis only happens when the request is ambiguous enough to justify it.
Behavior Across Time
Sessions are compressed into behavioral vectors and compared across time windows. That is how the system catches rotation, replay, and coordinated campaigns that look harmless one request at a time.
Evidence on Every Verdict
Raw and derived signals, detector contributions, confidence deltas, aggregation output, and recommended action remain attached to the request. Operators can review the actual pipeline trace instead of trusting a magic score.
Private by Default
The core system runs inside your infrastructure. You do not need to ship raw request traffic to a hosted scoring platform just to detect bots.
Per-Path Enforcement
Checkout, login, docs, and health probes should not share one blunt global policy. StyloBot lets you map risk to action where it matters.
Built for Growth
Start as a simple embedded control, then move to shared persistence, fleet reporting, and live config without changing the core operating model.
Start Simple. Tighten Where It Matters.
The system should be usable on day one and still reward teams that want precision later.
Fast Adoption
Install the middleware, start in observe mode, and inspect scores and reasons before you enforce anything aggressive.
Low-friction install
The OSS core is designed to get useful evidence into your app quickly.
Default-safe rollout
Throttle or challenge before you block. Let real traffic teach you where enforcement should land.
Immediate observability
Use the dashboard and API output to see what the runtime is actually noticing.
Contextual help everywhere
Every dashboard section has a ? icon that opens inline docs rendered from Markdown. No hunting through wikis.
System status at a glance
A status strip shows compliance pack, active services, guardian state, and LLM provider health in one row.
builder.Services.AddBotDetection();
app.UseBotDetection();
Precision Tuning
When certain paths, tenants, or machine clients need special treatment, tighten the policy exactly there instead of turning the whole site into a bunker.
Per-path policies
Keep `/api/checkout` strict and `/sitemap.xml` permissive without hacks.
Risk-to-action control
Map suspicion to throttle, challenge, or block according to your tolerance for friction.
Custom detectors and overrides
Extend the pipeline when your traffic has its own failure modes.
Fingerprint naming
Label detected signatures with human-readable names so operators can tell "Ahrefs crawler" from "sig:7f3a2b" at a glance.
"PathPolicies": {
"/api/login": "strict",
"/api/checkout": "strict",
"/health": "allowAll"
}
Why It Feels Smarter Than a Rule List
Good bot defense is not one trick. It is many boring signals becoming interesting when they are remembered, compared, and fed back into the next decision.
Monitoring packs
A pack is a stack-specific bundle of detectors, policies, and live-management UI calibrated for one technology stack.
The ASP.NET pack is the taster: its read half is already in FOSS, so the paid half (live hot-reload of endpoint and policy config) ships as a name-your-price subscription starting at 99c/mo.
Roadmap: WordPress pack (Q3 2026): plugin signatures, REST/XML-RPC abuse, login-page rate gates. Magento pack (Q4 2026): cart fraud, checkout protection, and storefront abuse detection.
See pack pricing →Featured detections (live data)
Google's web crawler. Honest user-agent, datacenter origin, no Sec-Fetch headers, predictable timing. We route it through the friendly-bot throttle-status policy -- never blocked.
Puppeteer, Playwright, and chrome --headless sessions. Looks like Chrome at the UA level but diverges from a real browser's protocol fingerprint. Watch-level by default.
Command-line HTTP clients (curl, wget, http). Honest Accept: */* and tiny header set. Useful in scripts, expected in many CI pipelines -- info-level until the request shape suggests scanning.
Python's requests library, the default HTTP client for the entire data-science world. Same observational stance as curl: not inherently hostile, but a strong signal when paired with a hostile path or rate.
Mastodon link-unfurl traffic and federated fetches. Looks bot-like by traditional rules but is legitimate inbound social-graph activity -- routed through friendly-bot policy.
Compliance & Governance
Active enforcement and audit trails. Not a checkbox.
Compliance Packs
One-click compliance presets for GDPR, CCPA/CPRA, CNIL (France), PCI-DSS, SOC2, and Financial Services. Each pack configures retention, anonymization, DSAR support, and audit logging to support your compliance programme.
Compliance Guardians
Scheduled enforcers that actively verify your compliance posture. Retention Guardian deletes data on schedule. DSAR Deadline Guardian alerts on approaching deadlines. Drift Guardian catches configuration drift.
Vector-Based Investigation
Search your detection data by behavioural similarity using pgvector HNSW. Each detection has a 16-dimension radar profile. Adjust sliders to describe the traffic you are looking for, or pick from presets like "Python Requests" or "Headless Chrome".
Adaptive Autotune
Capture a window of real traffic, replay it against a candidate config, and get a statistical breakdown of what every detector is actually costing versus contributing. One click applies the recommended change as a policy draft.
Arm, Capture, Analyse
Set a trigger (a bot-probability threshold, a named detector firing, or a manual arm) and the runtime records the N requests before and after. No synthetic load. You get the actual traffic that made the detector fire.
-
Pre-trigger ring buffer: captures N requests before the trigger fires, so you see what the session looked like before it hit the threshold
-
Gateway dry-run replay: candidate config changes are tested against the captured batch on a live gateway without taking action on any request
-
Five trigger types: manual arm, probability threshold, named detector, new fingerprint seen, or false positive signal
-
Operator always in the loop: every suggested change is presented as a yes/no policy draft, never applied automatically
Detector Cost vs. Value Analysis
Example analysis output after a 100-request capture
| Detector | Cost P95 | Value | Direction |
|---|---|---|---|
| TlsFingerprint | 0.4ms | 0.31 | keep |
| HeaderAnomaly | 8.2ms | 0.02 | prune |
| BehavioralRate | 2.1ms | 0.18 | keep |
| UserAgent | 0.3ms | 0.04 | lower threshold |
| IpReputation | 1.1ms | 0.09 | recalibrate |
Ad Intelligence
CHEQ-comparable ad fraud protection, self-hosted inside your gateway. Because StyloBot sits in the request path, you get per-endpoint IVT breakdown. CDN-side tools cannot offer that.
See Exactly Where Your Ad Budget Is Going
Ad traffic is tagged with UTM parameters. StyloBot classifies each click as valid, GIVT (General Invalid Traffic), or SIVT (Sophisticated Invalid Traffic) using the IAB taxonomy, then reports which campaign, which endpoint, and how much spend was wasted.
This Month
Request Flow
The product advantage is adaptive memory, not an AI label.
From Request to Action
-
1
Fast detectors score first
User-agent, header, protocol, and reputation checks establish the first cut quickly.
-
2
Behavioral context raises or lowers confidence
Session vectors, request transitions, and cross-signal consistency refine the result.
-
3
Aggregation maps risk to action
Probability and confidence become allow, throttle, challenge, or block according to your policy.
-
4
Telemetry feeds the next decision
Observed outcomes update reputation, reshape confidence, and make repeated patterns easier to classify.
Hot-Path Priorities
Fast-Path Reputation
When a signature is repeatedly confirmed as bad, the runtime promotes it into the cheap path. Known hostile patterns stop wasting expensive analysis cycles.
The Runtime Should Adapt Under Pressure
A serious bot event should not force the system into its heaviest path for every request. StyloBot uses reputation and evidence carry-forward so repeated patterns become easier to act on.
Operator consequence
The system preserves headroom during bad traffic instead of spending all of it trying to be clever.
Response Actions
Not every suspicious request deserves the same penalty.
Allow
Pass through when evidence is weak or clearly human.
Throttle
Slow the request stream and raise the cost of automation.
Challenge
Require proof that the client can behave like a real browser or user.
Block
Reject when the evidence is strong enough that debate is over.
Recent additions
- Friendly-bot throttle-status policy: legitimate crawlers (Googlebot, Bingbot) routed through a rate-limit lane instead of blocked.
- Deceptive-bot
(!)marker: bots claiming to be browsers but failing protocol checks get an explicit deception flag in the dashboard. - Drift-gated naming: bot display names only update when behaviour drifts, preventing flicker in the dashboard.
- Ambiguity-persistence: repeat boundary-probing requests are tracked as a signal in their own right.
- Slow-path coordinator: expensive identity verification is admission-controlled so it cannot DoS the fast path.