Whatthisdefends,andwhatitdoesnot.

A deception system that overstates itself is worse than none, because someone will rely on it. This page is the honest boundary: the attacker behaviour SentinelX is built for, the behaviour it is not, the rules it will not break, and the places the design is genuinely weak.

In scope

Interactive post-access sessions

An attacker with a shell or an authenticated HTTP session, doing reconnaissance, enumeration, credential hunting and lateral movement. This is the case the whole architecture is shaped around.

Single-shot request exploitation

Injection, deserialisation, SSRF and path traversal that complete before any behavioural pattern forms. Handled by synchronous request-level checks rather than the cumulative score.

Credential and secret harvesting

Reading .env files, private keys, /etc/shadow and cloud metadata. Weighted heavily, and the reason /run/secrets is unmounted at conversion.

Persistence and outbound pivoting

cron, authorized_keys, systemd units, and attempts to reach third parties. Persistence is recorded; pivoting is stopped by default-deny egress.

Out of scope

Preventing the initial compromise

SentinelX does not patch software, fix a WAF misconfiguration, or stop credential theft that happens somewhere else entirely. It starts when a session arrives.

Attribution

Campaign correlation says sessions resemble each other. It does not say who ran them, and no part of the system produces a claim about a real-world identity.

Volumetric denial of service

This is not a rate limiter or a DDoS mitigation. Distributed request patterns defeat per-address limits anyway, which is part of why the design leans on behaviour instead.

Endpoint and supply-chain compromise

An attacker who is already inside a trusted build pipeline never presents as an inbound session at the gateway.

Non-negotiable invariants

These are the rules the implementation is not allowed to relax, each one written down because relaxing it would be locally convenient and globally wrong.

01The management network used to preserve the live session is never modified during conversion.
02backend_net is removed before deception_net is attached, never the other way around and never both at once.
03Real secrets are unmounted as part of the conversion sequence.
04The deception environment enforces default-deny egress and has no route out.
05The LLM is strictly downstream and can never trigger a containment action.
06Honeypot-derived rules never auto-promote to enforcement.
07Every session is sandboxed before any suspicious behaviour is established.
08A scorer outage leaves the session sandboxed, unconverted and flagged, never disconnected.
09L0 never rejects a connection on a passive fingerprint alone.
10Campaign correlation is never presented as attribution.

Where this is weak

Written down deliberately. A design document that only lists strengths is marketing.

01

Pre-handshake signals are weak, and that is not fixable

CGNAT, residential proxy networks and uTLS mimicry all break the link between a connection fingerprint and intent. The design responds by treating them as a prior, which limits the damage but does not create signal that was never there.

02

A false positive is worse here than a block

A legitimate user who is silently converted keeps working against fabricated data and has no way to tell. A visible block is at least legible. This is the single strongest argument for a conservative T, and it is why the threshold sits high rather than where detection rate would be optimal.

03

Deception fidelity is an empirical question

A synthetic MySQL is not indistinguishable from a real one because it answers on the right hostname. Fidelity has to be validated per protocol, against real client behaviour, and the design assumes nothing about it.

04

Request-level checks only catch known shapes

The synchronous path exists because cumulative scoring misses single-shot attacks. It catches payload classes it has rules for. A genuinely novel injection class falls through both paths.

05

Universal sandboxing has a real cost

A container per inbound session, including every benign one, is memory and startup latency spent on traffic that will never do anything wrong. That cost buys the conversion mechanism, and it is charged whether or not it is ever used.

06

Conversion is observable to a determined attacker

Local state is preserved, but the backends change. An attacker who fingerprinted the real MySQL before threshold and compares afterwards has something to compare. Continuity raises the cost of noticing; it does not make it impossible.

What SentinelX is not

A rate limiter
A static honeypot
A redirect to another host
An LLM-driven containment system
An attribution engine
An ML classifier
A patch for anything
Standing disclaimer

SentinelX is a research and demonstration system. The architecture described on this page is a design and build roadmap; components sit at varying stages of implementation and hardening, and nothing here should be read as a benchmark or a production guarantee. Figures describe properties of the design (layer counts, the conversion sequence, the one-LLM-call rule) rather than measured results. Deception fidelity is validated empirically per protocol rather than assumed. Behavioural clustering indicates that sessions look related; it is not attribution, and SentinelX makes no claim about the real-world identity behind a connection. MITRE ATT&CK is a trademark of The MITRE Corporation.