Last updated: 2026-06-01 17:22 UTC

StyloBot Gateway Mode Lifecycle

StyloBot Gateway Mode places StyloBot in front of your web application as the traffic decision point.

The gateway receives every inbound request first, builds or updates a behavioural view of the client, runs the minimum detection needed for that request, applies policy, and then either forwards the request upstream or takes a protective action.

The important idea is simple:

The web app stays focused on serving the application. StyloBot owns behavioural inference, bot classification, policy enforcement, and visibility.

1. Gateway topology

In gateway mode, traffic flows through StyloBot before it reaches the application.

flowchart LR
    Client[Client / Browser / Bot] --> Gateway[StyloBot Gateway]
    Gateway --> VerdictGate[Verdict Gate]
    VerdictGate --> Pipeline[Detection Pipeline]
    Pipeline --> Policy[Action Policy]
    Policy --> Upstream[Your Web App]
    Gateway --> Dashboard[Dashboard / API / Audit Trail]

The gateway can run as:

  • a reverse proxy in front of the app
  • a sidecar next to the app
  • an edge-adjacent service behind Caddy, Nginx, Cloudflare Tunnel, or another ingress layer
  • a local gateway during development or demo mode

The upstream application does not need to know how bot detection works. It receives normal HTTP traffic, optionally with StyloBot headers that explain the verdict and action.

2. What StyloBot owns in gateway mode

StyloBot Gateway Mode is responsible for:

Area Responsibility
Request observation Reads headers, transport traits, route shape, timing, identity hints, cookies, and request context
Behavioural identity Builds an anonymous behavioural signature for the client
Fast-path decisions Reuses high-confidence recent verdicts without rerunning the full pipeline
Detection pipeline Runs detectors in ordered waves when a fresh decision is needed
Policy enforcement Maps verdicts to Allow, Throttle, Challenge, Block, Honeypot, or other configured actions
Audit trail Records the signals, contributors, reasons, verdict, and policy result
Dashboard/API Exposes live and historical detection state for inspection and tuning

The application remains responsible for its own business logic, authentication, content, and normal application security.

StyloBot is not replacing the app. It is acting as a behavioural control layer in front of it.

3. Request lifecycle

Every request goes through the same high-level lifecycle.

sequenceDiagram
    participant C as Client
    participant G as StyloBot Gateway
    participant V as Verdict Gate
    participant P as Detection Pipeline
    participant A as Aggregator
    participant R as Policy
    participant U as Upstream App
    participant D as Dashboard/API

    C->>G: HTTP request
    G->>V: Build fingerprint + lookup recent verdict

    alt Skip
        V-->>G: Use cached high-confidence verdict
    else Bias
        V->>P: Run pipeline with prior verdict
        P->>A: Contributions + signals
        A-->>G: Updated verdict
    else Miss
        V->>P: Run full pipeline
        P->>A: Contributions + signals
        A-->>G: New verdict
    end

    G->>R: Apply action policy

    alt Allow
        R->>U: Forward request upstream
        U-->>G: Response
        G-->>C: Response
    else Throttle / Challenge / Block / Honeypot
        R-->>G: Protective action
        G-->>C: Policy response
    end

    G->>D: Record trace, verdict, timing, evidence

This gives StyloBot three important properties:

  1. Repeat traffic is cheap.
  2. Ambiguous traffic gets more analysis.
  3. Every decision remains explainable.

4. Gateway startup lifecycle

When StyloBot starts in gateway mode, it prepares the detection engine before accepting traffic.

flowchart TD
    Start[Start StyloBot Gateway] --> Config[Load configuration]
    Config --> Routes[Load upstream routes]
    Routes --> Policies[Load action policies]
    Policies --> Manifests[Load detector manifests]
    Manifests --> Archetypes[Load identity archetypes and centroids]
    Archetypes --> Reputation[Load reputation / verdict cache if available]
    Reputation --> Dashboard[Start dashboard and API surfaces]
    Dashboard --> Listen[Begin accepting traffic]

Startup typically includes:

Step What happens
Configuration load Reads gateway, upstream, detector, policy, dashboard, and storage settings
Route setup Defines how requests are forwarded to the upstream app
Detector manifest load Enables contributors and assigns them to waves
Policy load Defines what happens at each risk/confidence level
Identity archetype load Loads known browser, bot, privacy-browser, and tool centroids
Reputation/cache warmup Restores recent behavioural knowledge where available
Dashboard/API start Makes observations visible for inspection and tuning

Once startup completes, the gateway begins processing live traffic.

5. The hot path

The hot path is the part of StyloBot that runs inline while the request is waiting.

The design goal is:

Do the cheapest reliable thing first. Only pay for heavier analysis when the request needs it.

flowchart LR
    Request[Request] --> Fingerprint[Build fingerprint]
    Fingerprint --> Cache{Recent confident verdict?}

    Cache -->|Yes| Skip[Skip pipeline]
    Cache -->|Maybe| Bias[Run pipeline with prior]
    Cache -->|No| Miss[Run full pipeline]

    Skip --> Policy[Apply policy]
    Bias --> Pipeline[Wave pipeline]
    Miss --> Pipeline

    Pipeline --> Aggregate[Aggregate verdict]
    Aggregate --> Policy
    Policy --> Result[Allow / Throttle / Challenge / Block]

The verdict gate has three outcomes:

Gate result Meaning
Skip A recent high-confidence verdict exists. The pipeline is not run.
Bias A usable verdict exists, but not strong enough to skip. The pipeline runs with that verdict as a prior.
Miss No usable verdict exists. The full pipeline runs.

This is what keeps repeat traffic cheap while still allowing StyloBot to adapt when behaviour changes.

6. Detection waves

When the pipeline runs, detectors are grouped into waves.

Contributors inside the same wave run concurrently. Later waves can consume signals produced by earlier waves.

flowchart TD
    W0[Wave 0<br/>Raw request + fast exits]
    W1[Wave 1<br/>Cheap synchronous signals]
    W2[Wave 2<br/>Correlation and behaviour]
    W3[Wave 3<br/>Models, clusters, reputation]
    W4[Wave 4<br/>Escalation and final amendments]
    Agg[Aggregation]
    Policy[Policy]

    W0 --> W1 --> W2 --> W3 --> W4 --> Agg --> Policy

Typical wave structure:

Wave Purpose Examples
Wave 0 Sub-millisecond fast checks and early exits Signature, whitelist, honeypot, fast-path reputation
Wave 1 Cheap direct request analysis User-Agent, headers, IP/network, transport, identity seed
Wave 2 Cross-signal correlation Fingerprint match, behavioural shape, content sequence, inconsistency detection
Wave 3 Higher-level intelligence Heuristic model, cluster lookup, reputation bias, verified bot DNS
Wave 4 Escalation and final checks Late heuristic, challenge verification, optional client-side or AI escalation

A contributor can emit an early-exit verdict such as VerifiedGoodBot, Whitelisted, VerifiedBadBot, or Blacklisted. When that happens, the orchestrator can stop the remaining waves and move directly to policy.

7. Aggregation

The pipeline does not produce a simple yes/no answer.

It produces a verdict made from probability, confidence, risk, threat, and narrative evidence.

Field Meaning
botProbability How bot-like the request appears
confidence How strong and consistent the evidence is
riskBand Per-request operational risk
threatBand Cross-request threat level for the fingerprint or behavioural identity
riskProfile Human-readable explanation of the observed behaviour
botType / botName Optional classification where the evidence supports it
reasons Detector and signal-level explanation

Probability and confidence are intentionally separate.

A high bot probability with low confidence should usually lead to caution: throttle, observe, or challenge.

A high bot probability with high confidence can justify stronger action.

8. Policy lifecycle

The policy layer turns a verdict into behaviour.

flowchart TD
    Verdict[Aggregated verdict] --> Policy[Action policy]
    Policy --> Allow[Allow]
    Policy --> Throttle[Throttle]
    Policy --> Challenge[Challenge]
    Policy --> Block[Block]
    Policy --> Honeypot[Redirect Honeypot]
    Policy --> Mask[Mask or degrade response]

Example policy intent:

Verdict shape Typical action
Low probability, high confidence Allow
Medium probability, low confidence Allow or light throttle
Medium probability, rising confidence Throttle or challenge
High probability, low confidence Throttle or challenge
High probability, high confidence Block, challenge, or honeypot
Verified good bot Allow with bot classification
Verified bad bot or manual block Block or honeypot

This makes StyloBot safer than a simple "bot score equals block" system.

The system can respond differently to different kinds of traffic: browsers, search engines, AI bots, scrapers, scanners, suspicious clients, and known hostile automation.

9. Upstream forwarding

If policy allows the request, the gateway forwards it to the upstream application.

flowchart LR
    StyloBot[StyloBot Gateway] --> Headers[Attach optional verdict headers]
    Headers --> App[Upstream Web App]
    App --> Response[Application response]
    Response --> Gateway[Gateway observes response]
    Gateway --> Client[Return response to client]

StyloBot may add headers such as:

Header Purpose
X-StyloBot-VerdictSource Shows whether the verdict came from cache, identity cache, or pipeline
X-StyloBot-WatchdogTrip Indicates whether cached trust was invalidated by suspicious drift
X-StyloBot-Risk Optional risk band
X-StyloBot-Action Optional policy action
X-StyloBot-Bot-Type Optional classification

The exact headers can be controlled by configuration, especially if the upstream app should not see internal detection detail.

10. Dashboard and API lifecycle

Gateway mode produces a live stream of detection evidence.

The dashboard and /api/v1 read from the same trace generated by the gateway.

flowchart TD
    Request[Request handled by gateway] --> Trace[Trace created]
    Trace --> Signals[Raw + derived signals]
    Trace --> Contributors[Contributor results]
    Trace --> Verdict[Final verdict]
    Trace --> Policy[Policy action]
    Trace --> Timing[Processing time]

    Signals --> Dashboard[Dashboard]
    Contributors --> Dashboard
    Verdict --> Dashboard
    Policy --> Dashboard
    Timing --> Dashboard

    Signals --> API[/api/v1]
    Contributors --> API
    Verdict --> API
    Policy --> API

The dashboard is not a separate truth source.

It is a view over the same evidence used by the gateway. This matters because an operator can inspect why a request was allowed, throttled, challenged, or blocked.

Typical dashboard questions:

  • What traffic is currently being classified as bot-like?
  • Which detectors are contributing most?
  • Are privacy-focused browsers being treated as human?
  • Which endpoints are under automation pressure?
  • Are false positives coming from one signal family?
  • How much latency is StyloBot adding?
  • Which policies are firing most often?

11. Cross-request lifecycle

A single request is weak evidence.

StyloBot becomes more accurate as it observes behaviour across requests.

flowchart TD
    R1[Request 1] --> Sig[Behavioural signature]
    R2[Request 2] --> Sig
    R3[Request 3] --> Sig

    Sig --> Reputation[Reputation state]
    Sig --> Vectors[Behaviour vectors]
    Sig --> Clusters[Bot product / network clusters]
    Sig --> Cache[Verdict cache]

    Reputation --> Future[Future request priors]
    Vectors --> Future
    Clusters --> Future
    Cache --> Future

The cross-request layer allows StyloBot to detect patterns that are invisible from one request:

Pattern Why it matters
Bursty request cadence Common in scrapers and automation
Endpoint sweeping Indicates discovery or harvesting
Missing browser phases Resource/API requests without normal page navigation
Identity drift Client claims one thing but behaves like another
Repeated tool shape Same automation stack across different IPs
Coordinated timing Bot networks or cron-driven campaigns
Behaviour switching Human-looking warmup followed by automation

This is where gateway mode is especially useful. Because all traffic passes through the gateway, StyloBot can observe the shape of behaviour across the whole application.

12. Privacy and identity model

StyloBot does not need to know who the user is.

Gateway mode works with anonymous behavioural identity.

It can compare:

  • request headers
  • transport traits
  • timing
  • navigation shape
  • content sequence
  • cookie behaviour
  • client hints
  • privacy headers
  • detector outputs
  • prior behavioural state

This allows StyloBot to ask:

What kind of client could have produced this behaviour?

That is different from asking:

Who is this user?

The distinction is important. StyloBot is behaviour-based, not identity-based.

13. Gateway deployment lifecycle

A practical gateway rollout should be staged.

flowchart TD
    Observe[Observe only] --> Headers[Forward verdict headers]
    Headers --> Throttle[Enable throttling]
    Throttle --> Challenge[Enable challenges]
    Challenge --> Block[Enable blocking for trusted bands]
    Block --> Tune[Ongoing tuning]

Recommended rollout:

Phase Behaviour
Observe StyloBot classifies traffic but does not interfere
Explain Dashboard and headers show verdicts and reasons
Soft control Low-risk throttling on obvious automation
Challenge Ambiguous high-risk traffic is challenged
Block Only high-confidence hostile traffic is blocked
Tune Adjust detector weights, thresholds, and route policies

This avoids the common failure mode of bot systems: turning on blocking before the operator understands the local traffic shape.

14. Per-route policy lifecycle

Not all routes should behave the same way.

A login endpoint, checkout page, search endpoint, admin route, static asset, API endpoint, and webhook all have different risk profiles.

flowchart LR
    Request[Request] --> Route[Route classifier]
    Route --> Page[Page policy]
    Route --> API[API policy]
    Route --> Static[Static asset policy]
    Route --> Admin[Admin policy]
    Route --> Checkout[Checkout policy]
    Route --> Webhook[Webhook policy]

Examples:

Route type Typical policy
Static assets Usually allow, but detect abnormal waterfalls
Product/search pages Throttle aggressive scraping
Login/register Challenge suspicious automation earlier
Checkout Prefer progressive friction over blunt blocking
Admin Stronger challenge/block thresholds
Webhooks Use strict allowlists or known signatures
Health checks Allow known internal callers, but do not create global exclusions

The gateway should protect the whole application, but not every path needs the same response.

15. Internal API and dashboard traffic

Gateway mode often needs the application, dashboard, and gateway to talk to each other.

Internal traffic should be explicitly classified rather than globally ignored.

The goal is:

No magic holes. Internal traffic is recognised, bounded, and policy-controlled.

For example, dashboard polling or gateway API calls may receive a different internal policy budget so they do not throttle themselves, while still being visible and protected.

This avoids the dangerous pattern where security tools create broad bypass paths that later become blind spots.

16. Heavier analysis lifecycle

Not everything belongs on the request hot path.

Gateway mode separates inline detection from scheduled or out-of-band analysis.

Inline hot path Scheduled / out-of-band
Fingerprint lookup Cluster rebuilds
Fast reputation FFT timing correlation
Header/UA/transport checks Reputation recomputation
Behavioural deltas Bot product/network discovery
Policy decision Optional model or LLM escalation
Trace recording Long-term compaction

This keeps request latency low while still allowing richer behavioural intelligence to accumulate over time.

17. What a healthy gateway-mode system looks like

A healthy StyloBot gateway should show:

  • most repeat traffic taking the skip or bias path
  • expensive detectors running only when needed
  • low added latency on the hot path
  • clear evidence trails for policy decisions
  • privacy browsers pulling toward human archetypes, not bot clusters
  • strong actions reserved for high-confidence cases
  • route-specific policies instead of global blunt rules
  • dashboard/API traffic classified as internal, not ignored
  • ongoing tuning based on observed false-positive and false-negative shapes

18. Summary

In gateway mode, StyloBot is the behavioural control layer in front of the web application.

The lifecycle is:

  1. Receive the request.
  2. Build or retrieve the anonymous behavioural fingerprint.
  3. Check the verdict gate.
  4. Skip, bias, or run the detection pipeline.
  5. Aggregate probability, confidence, risk, threat, and reasons.
  6. Apply route-aware policy.
  7. Forward, throttle, challenge, block, or redirect.
  8. Record the full trace.
  9. Feed the dashboard, API, reputation layer, and future request priors.

The core value is that StyloBot does not rely on one brittle identity signal.

It watches the shape of behaviour over time, decides how much evidence is enough, and applies policy in a way that is fast, inspectable, and tunable.