Inside Enravo Trust's automatic threat response — signature failures, nonce replays, and brute force attacks contained in real-time.
Security systems that only log threats are useless. By the time someone reads the log, the damage is done. Enravo Core's guard pipeline doesn't just detect threats — it responds to them automatically, in real-time, with configurable escalation thresholds.
Every failed security check in the guard pipeline is not just rejected — it's counted. The system maintains per-device and per-IP counters for different types of failures. When a counter exceeds its threshold, automatic enforcement kicks in. No human intervention required.
A nonce replay is when someone sends a request with a nonce that has already been used. This is a strong signal of an attack — either a man-in-the-middle captured the request and is replaying it, or someone is systematically probing the API. There's no legitimate scenario where a nonce should appear twice.
That's why nonce replay triggers an instant ban, not a warning. The device is immediately flagged as compromised, its sessions are revoked, and all future requests from that device are rejected until an administrator manually reviews and reinstates it.
{
"threat_type": "nonce_replay",
"device_id": "dev_f4e3d2c1",
"action": "instant_ban",
"details": {
"original_request": "POST /v1/orders at 12:31:04.221",
"replay_attempt": "POST /v1/orders at 12:31:04.847",
"nonce": "n_8k2mNx4pQ7",
"time_delta_ms": 626
},
"enforcement": {
"device_status": "banned",
"sessions_revoked": 1,
"active_tokens_invalidated": 2
}
}PoP signature failures are more nuanced. A single failure might be a clock skew issue or a temporary bug. But 5 failures from the same device indicate either a stolen token being used without the private key, or a compromised app trying to forge signatures. The threshold is configurable per client — critical endpoints can use lower thresholds.
Device-level enforcement handles compromised apps. But some attacks come from outside the app entirely — brute force login attempts, credential stuffing, or API scraping. For these, Enravo Core maintains IP-level counters with automatic lockout.
The IP lockout is temporary (default: 15 minutes) and rate-based. It doesn't affect other users on the same network unless they're also triggering failures. After the lockout period, the IP is automatically released. Persistent offenders can be permanently blocked via the admin dashboard.
Auto-banned devices aren't permanently locked out. An administrator can review the ban, examine the audit trail, and choose to reinstate the device if the ban was triggered by legitimate usage (e.g., a buggy app version). The reinstatement resets all counters for that device.
This creates a clear workflow: detect → contain → investigate → resolve. The automatic part (detect and contain) happens in milliseconds. The human part (investigate and resolve) happens at the administrator's pace, after the threat is already neutralized.
Automatic threat response is not optional security — it's table stakes. If your API can detect an attack but requires a human to respond, you're not protecting your users. You're logging their exposure. Enravo Core responds before the second request arrives.