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: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
TheAuditSignal object contains:
Use Cases
Financial Transactions
Block HIGH/CRITICAL violations for financial operations:Healthcare Data
Block any violations when handling protected health information:Legal Advice
Block HIGH/CRITICAL violations for legal consultations:Performance Impact
Blocking mode adds latency because it waits for the audit to complete:| Mode | Latency | Use Case |
|---|---|---|
| Fire-and-forget (default) | 0ms | Most applications |
| Blocking mode | 500-2000ms | High-risk operations |
- Simple checks: 500-800ms
- Complex checks: 1000-1500ms
- Full spectrum: 1500-2000ms
Combining with Alerts
Use blocking mode with alerts for comprehensive protection:- Request is blocked immediately
- Alert is sent to configured channels
- Signal is stored in dashboard
ContinumBlockedErroris 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

