Most fraud detection systems are tested by external red teams on a scheduled basis — periodic adversarial exercises that produce a point-in-time assessment of resilience. QUORUM takes a fundamentally different approach: it is a continuously self-adversarial system. An autonomous AI agent, running on the same infrastructure as the production fraud engine, operates as an internal red team every hour without human intervention.

The internal red team uses QUORUM's own ARBITRATOR tier — the same LLM that resolves disagreements between the behavioral, financial, and adversarial analysis tiers — to synthesize novel protocol verification vectors. These vectors are not replays of known attacks; they are AI-generated scenarios designed to probe the specific rules and thresholds that are currently active in the fraud engine. When a gap is identified — a vector that passes through the engine without triggering a rule — the ARBITRATOR proposes a shadow hardening rule that would have caught it. This rule enters the review queue for human approval before promotion to active blocking mode.

This document describes both the static detection architecture — the WAF, the JA3 fingerprint database, the Sentinel Edge worker, and the fraud pattern library — and the dynamic self-testing infrastructure that ensures those defenses remain current against evolving adversarial techniques. All throughput figures in this document are derived from QUORUM's production benchmark suite, using threshold values validated by the automated test harness.

QUORUM's WAF is not a signature-matching system — it is a semantic analysis engine. While conventional WAFs rely on regular expression patterns to identify attack payloads, regular expressions can be bypassed by encoding, obfuscation, or novel syntax variations that are semantically equivalent but syntactically different from known patterns. QUORUM's WAF parses all request payloads into Abstract Syntax Trees, analyzing the semantic structure of the content rather than its surface form.

The WAF operates on two distinct parsing pipelines running in parallel: the Acorn JavaScript parser for XSS detection and the node-sql-parser for SQL injection detection. Both pipelines are preceded by a multi-layer decoding stage that normalizes encoded payloads before semantic analysis begins.

The Acorn parser produces a full ECMAScript-compliant Abstract Syntax Tree from any input suspected of containing JavaScript. QUORUM scans the resulting AST for node types that indicate script execution intent: CallExpression nodes where the callee is a known dangerous method (eval, innerHTML, document.write, setTimeout with string argument), MemberExpression nodes targeting sensitive DOM properties, and Literal nodes containing inline event handler strings.

Because Acorn parses the actual JavaScript AST rather than pattern-matching the string, attack payloads that use unusual whitespace, Unicode escapes, semicolon injection, or template literal obfuscation are all parsed identically to their canonical equivalents. A document.write call is a document.write call regardless of whether it is encoded as document['wr'+'ite'], document.write(, or any other obfuscated form — the AST reveals the semantic intent in every case.

SQL injection payloads submitted in request bodies, query parameters, or headers are analyzed by node-sql-parser, which supports standard SQL dialects including MySQL, PostgreSQL, and SQLite. The parser produces a structured query representation from the input, allowing the WAF to detect syntactically valid SQL even when it is embedded within what appears to be application data.

The WAF detects SQL injection by parsing any string that appears to contain SQL syntax and checking for the presence of DML or DDL statements (SELECT, INSERT, UPDATE, DELETE, DROP, UNION) in a context where only data was expected. UNION-based injection, stacked query injection, comment-based bypass attempts, and time-based blind injection payloads all produce parseable AST output that the WAF identifies as out-of-context SQL.

Attack payloads are frequently encoded to bypass inspection at the network layer. QUORUM's WAF applies up to three rounds of recursive decoding before semantic analysis — ensuring that multi-encoded payloads cannot evade detection by wrapping the attack in successive encoding layers. Each round attempts URL decoding, Base64 decoding, and hexadecimal unescaping. If any decoding produces a result that differs from the input, the process repeats on the decoded output.

For each attack category, the WAF computes a severity level (low, medium, high, critical) based on the payload type and context. A single high-severity detection triggers immediate request rejection and a security event log entry. A critical-severity detection (headless browser confirmed, active SQL injection, confirmed XSS) triggers immediate rejection and increments the IP's event counter toward the autoban threshold.

QUORUM implements an autonomous IP ban mechanism that activates without human intervention when a persistent attacker is identified. The trigger condition is 5 or more high or critical severity security events from the same IP address within a 1-hour sliding window. When this threshold is crossed, the IP is immediately and permanently blocked — all subsequent requests from that IP are rejected at the WAF layer before reaching any application logic.

The autoban state is stored persistently in the database (isBlocked = true in the security infrastructure), not in ephemeral Redis cache. This means the ban survives process restarts, failovers, and infrastructure changes. Manual review is required to remove an autoban, creating a governance checkpoint that prevents systematic unbanning without human accountability.

QUORUM's WAF throughput is measured using a synchronized benchmark suite that runs both clean and attack payload scenarios. All benchmarks are executed synchronously (no async overhead) to measure pure WAF throughput at the CPU instruction level. Results represent minimum thresholds validated by the automated test suite on every release.

The WAF's attack detection overhead relative to clean payload throughput (a ratio of approximately 5:1 measured) reflects the additional AST parsing work required for attack payloads — clean payloads typically fail the quick pre-scan checks and exit early, while attack payloads proceed to full AST analysis. No regex-based WAF implementation achieves semantic accuracy at this throughput level; QUORUM's early-exit optimization for clean payloads recovers the overhead cost of AST parsing entirely for legitimate traffic.

Automation tools and attack frameworks leave distinctive fingerprints in the TLS handshake that are independent of the HTTP-layer User-Agent string. JA3 fingerprints encode the TLS client's supported cipher suites, extensions, elliptic curves, and elliptic curve point formats into a 32-character MD5 hash. JA4 fingerprints provide a more structured encoding that is more stable across minor library version changes. Both are passed to QUORUM via HTTP headers injected by a Nginx JA3/JA4 module at the network edge.

QUORUM's TLS fingerprint middleware loads a curated database of known-bad JA3 hashes and JA4 prefixes at startup. On every request, the middleware checks the provided fingerprint against this database in O(1) time (hash lookup for JA3, prefix-scan for JA4). A match triggers a risk contribution and a warning log entry identifying the specific tool associated with that fingerprint.

A critical detection occurs when the TLS fingerprint indicates an automation tool but the User-Agent header claims to be a legitimate browser (Mozilla, Chrome, Safari). This JA3/UA masquerade pattern — attempting to bypass User-Agent-based bot detection by spoofing the UA string — carries a higher risk contribution of +60 points, as it indicates a deliberate attempt to deceive the inspection layer rather than an incidental automation match.

QUORUM includes a Sentinel Edge Worker — a Cloudflare Workers-compatible interceptor that can be deployed at the CDN layer to reject clearly malicious requests before they consume any Node.js backend resources. The edge worker is a pure TypeScript module that operates as a standard Fetch API handler, compatible with any edge runtime that supports the Fetch API specification (Cloudflare Workers, Deno Deploy, Fastly Compute, or any WHATWG Fetch-compatible environment).

The edge worker performs high-speed regex-based pre-screening across five attack categories — a deliberate design choice distinct from the full AST-based WAF on the backend. At the CDN layer, computational budget is severely constrained, and AST parsing is not feasible within the sub-millisecond execution budget. The regex pre-screen is designed to catch obvious, high-confidence attacks only — sophisticated evasion attempts that pass the edge screen proceed to the full AST-based WAF on the backend.

The two failure modes serve different deployment contexts. Fail-closed is appropriate for production environments where any ambiguity should result in rejection — a 403 for a legitimate user is recoverable; a passed attack payload is not. Fail-degraded is appropriate for environments requiring maximum availability, where edge threats are forwarded with a header annotation for backend processing rather than rejected outright. The failure mode is configured per deployment via the AI_FAILURE_POLICY environment variable.

QUORUM deploys a WebAssembly fingerprinting module compiled from Rust via wasm-bindgen that runs client-side in the browser during session initialization. Rust-compiled WASM is chosen for this role because it is substantially harder to inspect, patch, or bypass than equivalent JavaScript — the WASM binary is not human-readable without decompilation, and modifying the fingerprinting logic requires rebuilding the Rust source rather than editing JavaScript in browser DevTools.

The fingerprinting module exposes three detection functions. generate_fingerprint hashes the canvas rendering output, hardware concurrency, and device memory into a stable identifier using a deterministic hash function. verify_environment_integrity performs automated environment detection through side-channel analysis. detect_automation_artifacts checks explicit automation indicators and computes a numeric risk score from the results.

// Rust (wasm_fingerprint) — automation artifact detection
pub fn detect_automation_artifacts(
    navigator_webdriver: bool,
    screen_width: u32,
    screen_height: u32
) -> f64 {
    let mut risk_score = 0.0;

    if navigator_webdriver {
        risk_score += 50.0;  // webdriver present → automated
    }

    if screen_width == 0 || screen_height == 0 {
        risk_score += 30.0;  // no display → headless environment
    }

    risk_score
}

The navigator.webdriver property — which Selenium, Puppeteer, and Playwright set to true in automated browser sessions — contributes 50 risk points. A screen resolution of 0×0 (indicating a headless environment with no physical display) contributes 30 risk points. These two signals together produce an 80-point score, well above the threshold for the challenge verdict and sufficient to trigger the block path when combined with other behavioral signals.

In addition to the WASM module, the backend FingerprintAnalyzer performs cross-validation of reported hardware characteristics: device memory below 2GB on a non-mobile User-Agent triggers a SUSPICIOUS_LOW_MEMORY flag (+15), reported hardware concurrency above 64 cores triggers IMPLAUSIBLE_CORE_COUNT (+20), and a Chrome User-Agent paired with a non-Google/Intel/NVIDIA WebGL vendor string triggers UA_VENDOR_MISMATCH (+25). Each of these signals catches a different category of automation tool attempting to spoof a legitimate browser environment.

QUORUM's fraud pattern library implements seven behavioral fraud detection patterns, each evaluating a distinct dimension of account and transaction behavior. Patterns run autonomously against user activity data and emit structured events when a match is detected. Each pattern has a severity level, a confidence score calculation, and a minimum evidence threshold below which no match is reported — preventing false positives from sparse data.

Pattern matches are recorded in the fraud_pattern_hits table with a confidence score (0–100) and a timestamp. Each match also emits an event through the event bus, allowing real-time downstream consumers — the watchdog, the Gemini fraud monitor, and the security event dashboard — to react immediately to detected patterns without polling the database.

The card testing pattern computes a composite Card Testing Score from three weighted sub-signals over a 30-day trailing window. The failure rate signal contributes up to 40 points (failure rate × 40). The distinct BINs signal contributes up to 30 points (5+ distinct BINs = max score). The recent failures signal contributes up to 30 points (3+ failures in the last hour = max score). A card testing score above 60 triggers the pattern at the resulting confidence level, ensuring that a combination of moderate signals (rather than a single extreme signal) can still produce a high-confidence match.

The temporary_identity pattern uses an embedded database of over 60 known disposable email domains — including mailinator.com, guerrillamail.com, 10minutemail.com, tempmail.com, and dozens of others — as well as a list of suspicious top-level domains (.top, .xyz, .monster, .icu, .cyou, .bond, .quest, .click, .buzz). The detection also includes a heuristic rule: domains with more than 40% numeric characters are classified as disposable, catching dynamically generated throwaway domains that aren't yet in the static list.

QUORUM's velocity analytics engine detects automated activity through sliding window event rate analysis. The engine maintains velocity event records for each user and computes burst scores by scanning those records across four distinct time windows simultaneously. The multi-window approach is essential: a sophisticated attacker who knows the rate limit for any single window can stay below that threshold while still executing at a rate that is implausible for legitimate human behavior across multiple windows simultaneously.

The burst score is computed as: min(100, exceededWindowCount × 15 + avgExcessPercentage × 0.5). This formula rewards consistent excess across multiple windows — exceeding four windows simultaneously produces a base score of 60 before any excess percentage contribution, ensuring that sustained high-velocity behavior scores near or at maximum. The velocity_abuse pattern triggers when the burst score exceeds 70.

The velocity event log includes action type, IP address, amount (for financial events), and timestamp. This allows the burst score calculation to be further refined by action type in future iterations — a burst of read-only API calls carries different risk implications than a burst of card addition or withdrawal attempts.

QUORUM maintains a persistent geolocation history for each authenticated user, recording the IP-derived geographic position (country, region, city, latitude, longitude) for each session using the ip-api.com geolocation service. This history enables detection of impossible travel — the appearance of the same account in geographically separated locations within a timeframe that would be physically impossible or implausible for legitimate travel.

The detection uses the Haversine formula to compute the great-circle distance between consecutive geopoints, accounting for Earth's spherical geometry. The formula operates on latitude/longitude pairs and returns the shortest-path distance in kilometers — a physically meaningful measure that does not require knowledge of transport routes or infrastructure.

// Haversine formula — great-circle distance between two geopoints
const R = 6371; // Earth's radius (km)
const dLat = ((lat2 - lat1) * Math.PI) / 180;
const dLon = ((lon2 - lon1) * Math.PI) / 180;
const a = Math.sin(dLat/2) * Math.sin(dLat/2) +
           Math.cos(lat1Rad) * Math.cos(lat2Rad) *
           Math.sin(dLon/2) * Math.sin(dLon/2);
return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-a));

The required travel speed is computed as the Haversine distance divided by the time elapsed between the two geopoints. The risk classification uses two thresholds:

• Impossible travel (>1,000 km/h): Exceeds the speed of commercial aircraft. Any legitimate account activity pattern that implies supersonic ground travel is definitively impossible. Risk contribution: +35 points, pattern confidence: 95%.
• Suspicious velocity (500–1,000 km/h): Possible via commercial aircraft but unusual for most user sessions. Risk contribution: +20 points, pattern confidence: 70%.

The geo-consistency engine also computes a Location Drift analysis for each user over the trailing 7 days, computing the count of distinct countries visited, the maximum distance between any two geopoints in the window, and the total number of distinct location entries. High drift across multiple countries with large distances is a secondary signal that can be combined with other behavioral indicators in the composite risk score.

Private and RFC 1918 addresses (127.x.x.x, 10.x.x.x, 172.16–31.x.x, 192.168.x.x, ::1) are explicitly excluded from geolocation recording. This prevents development and testing environments from polluting the geolocation history of accounts under test.

QUORUM's most architecturally distinctive feature from a resilience standpoint is its Autonomous Internal Red Team — an AI agent that continuously probes the fraud engine's own defenses, identifies gaps, and proposes hardening rules, all without human scheduling or intervention. This system runs as a BullMQ worker in the quorum-logic-verification queue, triggered every 60 minutes by the AI orchestration system.

Each hourly cycle begins with a prompt to the ARBITRATOR LLM — the same AI tier used to resolve disagreements between the behavioral, financial, and adversarial analysis tiers in the normal scoring pipeline. The ARBITRATOR is instructed to synthesize a novel protocol verification vector as a structured JSON object:

{
  "vector":         "describe the specific attack or bypass being tested",
  "target":         "the rule, threshold, or detection mechanism being probed",
  "expectedEffect": "what should happen when this vector is run correctly"
}

The vector is not a replay of a known attack from a fixed corpus — it is generated fresh by the AI each cycle, informed by its understanding of the current rule set and detection thresholds. This prevents the internal red team from becoming a static regression test suite; instead, it generates novel scenarios that probe the boundaries of current detection logic.

The synthesized vector is executed against the live fraud engine by calling computeRiskScore with parameters derived from the vector specification. The resulting risk score and verdict are compared against the vector's expectedEffect. If a gap is detected — the engine did not respond as the ARBITRATOR expected, typically indicating the attack passed without triggering the appropriate detection — the ARBITRATOR is called again to propose a shadow hardening rule.

The shadow rule is proposed in the quorum_proposed_rules table with status pending_review. It runs in pre-flight (shadow) mode — evaluated against live traffic but not blocking — until a human reviewer promotes it to active mode. The AI reasoning behind the rule proposal is stored in the aiReasoning column alongside the proposed conditions and actions, giving the human reviewer full context for the decision.

Alongside the hourly red team cycle, QUORUM runs a reinforcement learning loop every 5 minutes. This loop computes true positive and false positive rates from the 500 most recent security events, then queries the ARBITRATOR with the current detection performance metrics. The ARBITRATOR responds with a suggested newThreshold multiplier, which is written directly to Redis at key quorum:config:risk_sensitivity and applied immediately to subsequent risk evaluations — without requiring a deployment or restart.

The following table summarizes all validated performance thresholds from QUORUM's production benchmark suite. All figures represent minimums — the system is required to meet or exceed these thresholds on every release before a build is considered eligible for production deployment.

Minimum release thresholds are enforced test assertions — the build fails if any component drops below its floor value. Threshold values represent conservative minimums calibrated well below observed measured performance; the actual margin varies from 2.7× (WAF clean) to 47× (SHA-256 hash) above threshold. Note that risk scoring benchmarks reflect mocked LLM inference; production throughput on the LLM path is bounded by Ollama inference capacity at 1–5 requests per tier per second — the architecture parallelizes the three tiers to maximize effective throughput within that bound.

The following JA3 hashes and JA4 prefixes are included in QUORUM's default fingerprint intelligence database. All hashes are sourced from the Salesforce JA3 repository and community threat feeds, and represent stable fingerprints across minor library version changes.