GhostLine · Traffic Integrity

Behavioral detection for automated abuse in production.

GhostLine observes real application traffic and exposes automated abuse patterns through behavioral signals and risk scoring. Phase 1 delivers a working behavioral decision core: a FastAPI evaluation API, Postgres-backed event storage, Alembic migrations, a scoring + decision engine, and explainable evidence output.

Phase 1 proves two real attacker behaviors: burst throttling (cadence attacks) and route enumeration (recon behavior), returning ALLOW or THROTTLE with reasons, TTL, and evidence you can inspect.

Observability Behavioral signals Risk scoring Explainable evidence Agent or managed
How to use Deployment options
Principle: GhostLine is observational. It does not “run attacks.” It evaluates real behavior and produces defensible signals.
Phase 1 status: Complete. GhostLine is operational as an observational decision engine that returns ALLOW or THROTTLE with explainable evidence (burst + traversal).

What Phase 1 proves: (1) burst throttling under tight cadence, (2) route traversal / enumeration suspicion, (3) evidence fields you can log, alert on, and integrate with enforcement.

What’s next: deployment packaging and integrations:
  • Agent (self-hosted): run inside your environment (middleware/edge/log ingestion), keep data local, emit standardized events.
  • Service (managed): dashboards, alerting, coordination across apps, and shared tuning without ops overhead.
  • Enforcement hooks: optional adapters to rate-limit, challenge, or step-up verify based on GhostLine signals.
Focus
Behavior over identity Signals-first
Output
Scores + evidence Explainable
Response
Alert / throttle / challenge Operator-led

How to use GhostLine (local proof)

This is the exact Phase 1 proof flow: run the API, run the demo script, watch ALLOW flip to THROTTLE under burst behavior and route enumeration, and inspect decision, score, reasons, ttl, and the evidence object returned.

Quick start
# Requirements
# - Python 3.11+ recommended
# - A virtual environment is recommended

# Install
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

# Run the API (Terminal A)
uvicorn ghostline.main:app --reload --port 8000

# Run the proof script (Terminal B)
python3 demo_ghostline.py
Expected behavior: requests begin as ALLOW, then burst behavior flips to THROTTLE around request ~10 (example: reason=burst_requests, ttl=9). Route enumeration increases enum_count and can flip to THROTTLE when the threshold is exceeded.
What to look for
  • Burst proof: decision flips around request ~10 during rapid calls
  • Evidence fields: decision, score, reasons, ttl, plus evidence counters
  • Enumeration proof: touching many distinct routes increases enum_count and can flip to THROTTLE
  • Evidence fields: burst counters, enumeration counters, sampled routes touched, TTL windows, anomaly flags
Design: GhostLine emits decisions + evidence. You wire actions (rate-limit, challenge, alert) into your own enforcement.
API endpoints
# Health
GET /health
# -> {"ok": true}

# Evaluate
POST /v1/evaluate
Content-Type: application/json
Body (minimal): {}

# Returns:
# - decision (ALLOW / THROTTLE)
# - score (risk score)
# - reasons (why it triggered)
# - ttl (how long the throttle should last)
# - evidence (explainable signal data)

# Recent events
GET /v1/recent?limit=50
# Useful params: decision=THROTTLE, client_key=127.0.0.1, route=/v1/evaluate

# Stats
GET /v1/stats?window_seconds=600
# window_seconds: 10..86400 (up to 24 hours)
Manual curl tests (optional)
# Set a realistic browser UA
UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120 Safari/537.36"

# Single evaluate
curl -s http://127.0.0.1:8000/v1/evaluate \
  -H "User-Agent: $UA" \
  -H "Content-Type: application/json" \
  -d '{}' | python3 -m json.tool

# Burst test (cadence throttling)
for i in $(seq 1 25); do
  curl -s http://127.0.0.1:8000/v1/evaluate \
    -H "User-Agent: $UA" \
    -H "Content-Type: application/json" \
    -d '{}' \
    | python3 -c 'import sys,json; d=json.load(sys.stdin); print(d["decision"], d["evidence"]["burst_count"], d["ttl"])'
done

# Enumeration test (route traversal)
curl -s http://127.0.0.1:8000/health -H "User-Agent: $UA" >/dev/null
curl -s "http://127.0.0.1:8000/v1/recent?limit=3" -H "User-Agent: $UA" >/dev/null
curl -s "http://127.0.0.1:8000/v1/stats?window_seconds=600" -H "User-Agent: $UA" >/dev/null

curl -s http://127.0.0.1:8000/x1 -H "User-Agent: $UA" >/dev/null
curl -s http://127.0.0.1:8000/x2 -H "User-Agent: $UA" >/dev/null
curl -s http://127.0.0.1:8000/x3 -H "User-Agent: $UA" >/dev/null

curl -s http://127.0.0.1:8000/v1/evaluate \
  -H "User-Agent: $UA" \
  -H "Content-Type: application/json" \
  -d '{}' | python3 -m json.tool

Signals GhostLine watches

GhostLine surfaces patterns that are hard to fake consistently over time. It can ingest from logs, middleware hooks, or edge integrations depending on your environment.

Cadence & bursts

Unnatural timing, burst profiles, retry loops, and backoff behavior that doesn’t match humans.

Traversal patterns

Machine-like endpoint sequences, improbable navigation paths, and step skipping across workflows.

Repetition & entropy

Reused payloads, identical parameter shapes, and low-diversity behaviors across sessions and accounts.

Client stability

Fingerprint drift, header volatility, and “rotating identity” behaviors over time windows.

Account pressure

Concentrated pressure against login, reset, verification, checkout, and other high-value surfaces.

AI-farmed automation

Automation that mimics users but behaves like infrastructure: repetitive structure, bursty sessions, improbable throughput.
Clarity over attribution: GhostLine doesn’t claim “who did it” by default. It provides evidence-based signals you can act on.

Common use cases

Start where abuse hurts the most. GhostLine is designed to support mitigation decisions without burying teams in raw logs.

Login protection

Identify scripted login loops, stuffing patterns, and suspicious retry behavior.

Scraping reduction

Surface harvesters probing inventory, pricing, and content with machine-like traversal.

Signup abuse detection

Catch automated account creation, referral farming, and verification pressure.

AI-assisted throughput

Flag interaction rates and repetition profiles inconsistent with individual manual use.

Campaign clustering

Group related sessions into campaigns so teams can respond to patterns, not individual IPs.

Exports & automation

Send structured events to SIEM, webhooks, alerting systems, or internal dashboards.

Deployment options

GhostLine is one system with two deployment modes. Run GhostLine Agent inside your environment, or use GhostLine Service for managed coordination and dashboards.

GhostLine Agent (self-hosted)
Ingest traffic where it lives. Keep data in your environment while producing standardized events, scores, and “why flagged” evidence.
# Conceptual example (placeholder)
ghostline agent \
  --source nginx \
  --input /var/log/nginx/access.log \
  --emit jsonl \
  --out /var/log/ghostline/events.jsonl
Agent architecture (coming soon) Request early access
Best for: teams that want full control over data residency and pipeline ownership.
GhostLine Service (managed)
Managed ingestion, alerts, and coordinated scoring across applications. Ideal for teams that want outcomes without running infrastructure.
# Conceptual event ingestion (placeholder)
POST /ghostline/events
{
  "app": "your-app",
  "surface": "login",
  "risk": 0.84,
  "signals": ["cadence_burst", "traversal_anomaly", "retry_loop"]
}
Demo (coming soon) Join waitlist
Best for: teams that want dashboards, alerting, and coordination without ops overhead.
Integration options: start with log-based ingestion for minimal footprint. Next (Phase 2) adds enforcement middleware (HTTP 429 / Retry-After), proxy-aware client identity (Cloudflare, X-Forwarded-For), integration into real web surfaces, and expanded signals and scoring depth.

What to look for in Phase 2

Phase 2 turns the Phase 1 decision core into something you can drop into a real web surface. The focus is integrations, proxy-aware identity, and enforcement hooks, while expanding the signal set and evaluation workflow.

Proxy-aware client identity

Correct client attribution behind CDNs and reverse proxies (e.g., Cloudflare / X-Forwarded-For), so the same actor is tracked consistently.

Enforcement middleware

Optional adapters to turn decisions into action (HTTP 429, Retry-After, step-up verification triggers) without changing your app’s business logic.

Batch ingest + log pipeline

A path to ingest traffic from logs/queues in batches (not only live requests), making GhostLine usable for analytics, SIEM export, and post-incident review.

Additional signals

Deeper behavioral coverage beyond bursts and traversal: repetition profiles, header volatility, and account pressure across high-value endpoints.

Backtest + tuning harness

A repeatable way to replay captured traffic, measure false positives/negatives, and tune thresholds with evidence, not guesswork.

Stable output contracts

Versioned event schemas and exports so you can wire GhostLine into dashboards, alerts, and automation with predictable fields.
Success criteria: you can put GhostLine behind a real endpoint, see proxy-correct identity, enforce throttles consistently, and export structured events for monitoring and investigation.

Outputs you can act on

GhostLine emits structured events and risk scores that plug into your workflow. You decide whether to alert, throttle, challenge, or investigate.

Event (example)
{
  "ts": "2026-01-17T12:19:46Z",
  "app": "calypso-labs",
  "surface": "login",
  "session_id": "abc123",
  "risk": 0.78,
  "signals": ["cadence_burst", "endpoint_traversal", "retry_loop"],
  "evidence": {
    "window_s": 120,
    "req_count": 96,
    "unique_accounts": 14
  }
}
Actions (examples)
  • Rate-limit suspicious sessions or surfaces
  • Step-up verification on high-risk workflows
  • Alert ops/security on spikes and campaigns
  • Export to SIEM / webhook / internal tooling
  • Review “why flagged” evidence and tune thresholds
Operator control: GhostLine recommends actions, but you set policy.

FAQ

Quick answers for security and engineering teams evaluating the concept.

Does GhostLine block traffic by itself?

By design, no. GhostLine is observational and emits signals, scores, and evidence. You can wire those outputs into rate limiting, step-up verification, WAF rules, or internal mitigation workflows.

What data does it need?

The smallest footprint is log-based ingestion (request path, method, status, timing, and a stable session identifier if available). Middleware or edge integrations can enrich events when you want deeper fidelity.

Is this about “bots” only?

It’s about automated abuse patterns, which can include classic bots, scripted workflows, and AI-assisted automation that still exhibits machine-like cadence, repetition, or impossible throughput.

Interested?

GhostLine is being shaped alongside real-world traffic patterns. If you want early access, we’ll do a short technical walkthrough and talk integration.

Request early access Back to Integrity Suite