What lockdown protects
Lockdown puts the platform into a read-only mode: every open session is ended, and mutating requests are refused, while reads keep working. It can be engaged by hand at any time by an operator, and it is designed to be non-destructive and fully reversible — nothing is deleted, and turning lockdown off restores normal operation. A correlated signal strong enough to justify locking the platform down on its own is evaluated on every detection pass. That automatic trigger is disarmed by default and starts in a shadow mode — it records what it would have done and pages a human, without engaging the lock — and the operator arms it only after its shadow firings have been reviewed against real signals. The manual switch an operator controls is separate from this and unaffected by whether the automatic trigger is armed.
The inline filter
Requests to the platform pass through a filter of deterministic pattern rules and targeted virtual patches before they reach the application — never a model. A rule matching a request means the request matched a pattern, not that an exploitation attempt is confirmed: a block is recorded as a match, never asserted as a prevented breach. The filter defaults to observing rather than blocking, because a filter that blocks legitimate traffic gets switched off, and a switched-off filter catches nothing; blocking a specific pattern is an explicit, deliberate decision, not the default state. A virtual patch aimed at one parameter of one endpoint that testing actually found vulnerable is preferred over a broad pattern applied to every request, because its blast radius — the chance of blocking something legitimate — is far smaller.
The reasoning is architectural, not incidental: a model cannot evaluate every incoming request inside a request's own time budget, and putting one in that path would also mean that a hacked or manipulated model becomes a hacked protection layer sitting directly in front of the platform — the worst version of this failure mode. So the request path stays deterministic rules only; any AI reasoning the platform does runs afterward, over what the deterministic layer already decided, never synchronously in front of it.
What it means for you during a lockdown
If Sentinelleai's own platform is in lockdown, some routes return a 503 rather than completing a write — new scans will not start, and settings will not save, for example. Reads keep working. Nothing is silently lost: a billing webhook that arrives during a lockdown is refused the same way, and the sending provider retries it for days, so it is delivered once the lockdown lifts rather than dropped.
The API token for scripts
A script or another service calling a mutating API endpoint from outside the browser needs a bearer token on the request; an ordinary browser request from the platform's own pages is recognized and exempted without one, since a script running elsewhere cannot forge that same signal. See the API reference for the endpoints this applies to.
What it stops short of
- None of this defends your own servers, applications, or traffic — it defends the Sentinelleai platform only.
- A blocked request is a pattern match, not a confirmed exploitation attempt, and an unblocked request is not proof nothing was wrong with it — only that nothing matched a rule that exists today.
- Rate limiting, volumetric defense, and bot defense are in observation: they judge and log, but do not yet refuse traffic on their own.
- The automatic lockdown trigger is disarmed by default: until the operator arms it, it pages a human rather than acting on its own.