Fraud Detection

Bulwark evaluates each authentication and agent action against a risk model. When risk exceeds a configurable threshold, Bulwark can block the action, challenge the user, or flag it for review — without requiring you to build or maintain detection logic.

Risk Scoring

Every login attempt and sensitive agent action receives a risk score between 0 and 100. The score is computed from a combination of signals:

| Signal | Description | |--------|-------------| | Login velocity | Number of login attempts for a user in a rolling window | | IP velocity | Number of unique users logging in from the same IP | | New device | First time this user agent / fingerprint has been seen | | Geographic anomaly | Login from a country not previously associated with the user | | Credential stuffing pattern | Rapid sequential attempts with different emails from the same IP | | Bot signals | Headless browser indicators, missing JS, abnormal timing | | Known malicious IP | IP appears in Bulwark's threat intelligence feeds |

Scores are not fixed — weights are tuned continuously based on global signal data.

Per-User and Per-IP Counters

Bulwark maintains sliding-window counters for:

  • Per-user login attempts — reset on successful authentication
  • Per-user failed attempts — used for lockout decisions
  • Per-IP login attempts — across all users for credential stuffing detection
  • Per-IP unique users — a high ratio of unique users per IP suggests automation

Counters are maintained in-memory with periodic persistence. They survive server restarts.

Decision Outcomes

When a risk score is computed, Bulwark maps it to one of three outcomes based on your configured thresholds:

| Outcome | Default Threshold | Behavior | |---------|------------------|----------| | allow | Score < 40 | Authentication proceeds normally | | challenge | 40 ≤ Score < 75 | User is prompted for MFA or CAPTCHA | | block | Score ≥ 75 | Authentication is rejected with 403 |

Outcomes can also be triggered by specific signals regardless of score (e.g., always block known malicious IPs).

Configuring Thresholds

Adjust thresholds from the Bulwark dashboard under Settings → Security → Fraud Detection, or via the Admin API:

{
  "fraud_detection": {
    "enabled": true,
    "thresholds": {
      "challenge": 50,
      "block": 80
    },
    "rules": [
      {
        "signal": "known_malicious_ip",
        "outcome": "block"
      },
      {
        "signal": "new_device",
        "outcome": "challenge"
      }
    ]
  }
}

Rules are evaluated before the score threshold. A matching rule outcome takes precedence.

Login Velocity Detection

Velocity detection fires when the rate of login attempts — successful or failed — for a given user or IP exceeds a configured rate:

| Counter | Default Limit | Window | |---------|--------------|--------| | Failed attempts per user | 10 | 15 minutes | | Total attempts per IP | 100 | 5 minutes | | Unique users per IP | 20 | 5 minutes |

When a counter limit is reached:

  • The triggering request receives the block or challenge outcome
  • An audit event is written with signal velocity_exceeded
  • Subsequent requests from the same user or IP continue to be evaluated until the window expires

Challenge Flow

When the outcome is challenge, Bulwark inserts an MFA step into the authentication flow. If the user has no MFA configured, they are prompted to set one up before proceeding. If MFA is unavailable or times out, the attempt is blocked.

For agent sessions, challenges are handled via CIBA — the agent's action is paused until the owning user completes the challenge out-of-band.

Webhooks

Risk events can be streamed to your webhook endpoint:

{
  "event": "auth.risk_detected",
  "data": {
    "user_id": "usr_01j...",
    "ip": "203.0.113.42",
    "risk_score": 78,
    "outcome": "block",
    "signals": ["known_malicious_ip", "velocity_exceeded"],
    "attempted_at": "2026-03-30T13:00:00Z"
  }
}

Use risk webhooks to feed your own SIEM, alert on spikes, or trigger additional in-product lockdown workflows.

Allowlisting

Trusted IPs, user agents, or ASNs can be allowlisted to bypass fraud scoring entirely. This is useful for:

  • Internal tooling IP ranges that trigger velocity limits
  • Automated test accounts in staging environments
  • Service accounts that authenticate non-interactively

Configure allowlists under Settings → Security → Allowlists.