Skip to main content

Overview

By default, protect() uses fire-and-forget auditing (zero latency). For high-risk scenarios where safety > speed, use blocking mode to wait for audit results before returning the response.

Quick Start

Risk Level Thresholds

Specify the minimum risk level that should block the request:
Risk level hierarchy:
If blockOn: 'HIGH', then HIGH and CRITICAL violations will block, but MEDIUM and LOW will not.

Global Configuration

Configure blocking mode globally:

Per-Call Override

Override global configuration for specific calls:

Error Handling

ContinumBlockedError

When a request is blocked, ContinumBlockedError is thrown:

Signal Properties

The AuditSignal object contains:

Use Cases

Financial Transactions

Block HIGH/CRITICAL violations for financial operations:

Healthcare Data

Block any violations when handling protected health information:
Block HIGH/CRITICAL violations for legal consultations:

Performance Impact

Blocking mode adds latency because it waits for the audit to complete: Typical blocking mode latency:
  • Simple checks: 500-800ms
  • Complex checks: 1000-1500ms
  • Full spectrum: 1500-2000ms

Combining with Alerts

Use blocking mode with alerts for comprehensive protection:
When a request is blocked:
  1. Request is blocked immediately
  2. Alert is sent to configured channels
  3. Signal is stored in dashboard
  4. ContinumBlockedError is thrown

Best Practices

1. Use Blocking Mode Selectively

Only use blocking mode for high-risk operations:

2. Handle Errors Gracefully

Always provide user-friendly error messages:

3. Log Blocked Requests

Track blocked requests for security monitoring:

4. Use Appropriate Thresholds

Choose the right threshold for your use case:

Testing Blocking Mode

Test your blocking mode configuration:

Next Steps

Violation Handlers

React to specific violations in code

Alerts

Set up real-time alerts

Presets

Explore presets and compliance frameworks

Configuration

Advanced SDK configuration