SENTINEL: An Autonomous, Quantum-Safe Defense Platform

Articles · August 2026 · Ioannis (John) Konstas

SENTINEL is a security platform I designed, built, and operate myself. It isn't a proof of concept — it's a live, autonomous defense stack sitting in front of production infrastructure I run, watching real traffic and containing real attackers around the clock. This piece covers the architecture, the reasoning behind it, and the testing regimen I use to keep proving it holds up.

It's a working implementation of Zero Trust, active defense, and post-quantum cryptography built as one system rather than three separate initiatives. The differentiator isn't any single layer — it's marrying forward-looking cryptographic standards (FIPS 203/204) with automated active deception, so security monitoring behaves as a closed-loop, self-correcting system instead of a passive alert stream.

The problem with reactive security

Industry figures put the average time to detect a breach at around 207 days — meaning most organizations discover an intrusion months after the attacker already extracted whatever they came for. Three habits get most defenses there: perimeter-only thinking (firewalls and antivirus stop known threats, but modern intrusions ride in on legitimate tools and trusted protocols), alert fatigue (security teams drowning in low-quality alerts until the real one gets lost in the noise), and no forensic trail once a breach is finally noticed. SENTINEL is built to be wrong about none of those three: it decides without waiting on a human, it manufactures its own forensic trail, and it assumes the classical cryptography protecting all of this has an expiration date.

Topology

The architecture is layered — each layer assumes the one in front of it eventually gets bypassed, and exists to catch what gets through:

Internet / attackers
      │
      ▼
Edge filtering  ── challenges and mitigates known-bad traffic before it lands
      │
      ├──────────────┬───────────────────┐
      ▼               ▼                   ▼
Deception grid   Production services   Behavioral threat engine
11 decoy nodes,  never exposed         scores every request,
canary-tokened   directly to raw scan  auto-contains in <1s
      │                                    │
      └───────────────┬────────────────────┘
                       ▼
              Security operations dashboard
              loopback-bound, authenticated
                       │
                       ▼
          Quantum-safe cryptographic layer
          ML-KEM-768 + X25519 hybrid, ML-DSA-65 signing
                       │
                       ▼
          Encrypted reporting & backup
          scheduled digests, signed pentest reports,
          encrypted at rest, keys rotated on schedule

Nothing that touches raw internet traffic talks directly to a production service — every path either terminates in a decoy, gets scored by the behavioral engine, or both. The dashboard that shows all of this is not internet-reachable; it's loopback-bound and authenticated, because a monitoring console is itself an attack surface.

Eight layers, working in concert

Behavioral threat intelligence engine

An always-running analysis engine reads every inbound request, classifies intent from behavioral signatures, assigns a threat severity score, and acts autonomously — no human approval in the loop. Decisions happen in milliseconds.

Multi-node deception grid

Eleven invisible traps — fake admin panels, credential portals, database consoles, environment files — wait silently for attackers. The moment one engages, every action is logged with a unique forensic canary token. They leave believing they succeeded.

Autonomous containment

Hostile sources are blocked at the network layer within about a second of first contact, no human decision required, and the block is reported outward to global threat-intelligence feeds automatically.

Continuous file integrity verification

Several hundred critical configuration files, binaries, and credentials are cryptographically hashed and watched in real time. Any unauthorized change — even a single byte, which flips the hash entirely — triggers an immediate alert, regardless of how the change happened.

Self-healing deployment

A hash mismatch doesn't just alert — it rebuilds. On a fixed cycle, web-facing infrastructure is purged and rebuilt from its authorized master copy unconditionally, whether or not anything was flagged, on the assumption that something could slip past detection. Outside that cycle, a hash deviation caught at any other moment triggers the same restoration immediately, before I've opened an alert. Either way, the system repairs itself faster than I could respond to a notification.

Security operations dashboard

An authenticated, loopback-only command view shows every threat, block, alert, and service health status — filterable live logs, one-click emergency purge, all in one screen, never exposed to the open internet.

Zero-trust management tunnel

All administrative access routes through a cryptographically authenticated, zero-trust tunnel. No exposed management ports, no cleartext credentials.

Forensic evidence chain

Every attacker who touches the deception grid leaves carrying a unique canary token embedded in whatever they extracted. If that token ever surfaces elsewhere — another breach, a dark-web leak, a future attack — it traces back to the exact moment it was planted.

What happens the second an attacker finds it

A typical organization might not know it's been probed for days. In SENTINEL, the whole sequence — detection to global reporting — runs in about a second:

1. T+0ms — probe detected. The behavioral engine receives the first request and starts building a threat profile; recon attempts and known scanner fingerprints are recognized instantly.
2. T+1ms — deception engaged. If the probe targets a sensitive path, the source is silently redirected into the deception grid and served convincing fake responses, each carrying its own forensic token.
3. T+800ms — blocked permanently. The source is blocked at the firewall layer; all future connections from it are dropped silently.
4. T+1s — reported outward. The attack is pushed to threat-intelligence infrastructure, so other systems using the same feeds are now protected from the same source.
5. T+1s — visible on the dashboard. Source, attack type, severity, which decoy nodes were touched, and the forensic canary IDs involved, all logged in real time.

Quantum-safe cryptography

Google's March 2026 warning — later echoed by Cloudflare and backed by a $2B U.S. government emergency program — put a working estimate on the table: large-scale quantum computers capable of breaking today's public-key cryptography could arrive by 2029. That matters today because of "harvest now, decrypt later": encrypted traffic captured now can be stored and broken retroactively once the hardware exists. Waiting until 2029 to migrate means everything captured between now and then is already compromised in advance.

SENTINEL's internal cryptographic layer implements NIST FIPS 203/204 directly:

• ML-KEM-768 — post-quantum key encapsulation (Module-LWE based), replacing pure X25519 for key exchange.
• ML-DSA-65 — post-quantum digital signatures, replacing Ed25519/RSA for signing.
• Hybrid mode — ML-KEM-768 and X25519 combined through HKDF-SHA3-256 into an AES-256-GCM session key, so an attacker has to break both the classical and post-quantum primitives at once to compromise anything, even if one falls first.

Classical elliptic-curve exchange and RSA/Ed25519 signatures are vulnerable to Shor's algorithm once a sufficiently large quantum computer exists; AES-256 is not, which is why it stays as the symmetric workhorse underneath the hybrid handshake.

The signature side, ML-DSA-65 (FIPS 204), sits at the equivalent NIST security category and replaces RSA/Ed25519 for every signed artifact SENTINEL produces — pentest reports, configuration attestations, canary-token provenance. A one-bit tamper anywhere in a signed payload invalidates the signature; there's no partial-credit verification.

Compliance mapping

The architecture wasn't retrofitted to a framework — it maps directly onto controls from the standards that matter most:

• NIST SP 800-53 — CA-8 (penetration testing), SC-26 (honeypots), SI-4 (system monitoring), AU-2 (audit events), IR-4 (incident handling).
• DoD DoDI 8500.01 — government-standard warning banners and access-control notices on every deception node.
• CFAA — Computer Fraud and Abuse Act notices embedded in every honeypot response, so the deception layer is legally defensible, not just technically clever.
• AES-256 — all reports, configuration, and sensitive data encrypted at rest and in transit.

Vulnerability and penetration testing — what I run, and how often

A defense platform that hasn't been attacked by its own operator is just a hope. SENTINEL gets tested continuously, not audited once a year, and the results feed back into the behavioral engine's scoring. The categories I run on a standing basis:

• Reconnaissance & service enumeration — port and service scans against the platform's own edge, to confirm the deception grid is what's actually being fingerprinted, not production.
• Credential attacks — brute-force and credential-stuffing attempts against every exposed authentication surface.
• Injection testing — SQL injection, path traversal, remote code execution, and command injection against application inputs.
• Web application fuzzing — including cross-site scripting and input-validation edge cases across every user-facing form.
• Replay and man-in-the-middle attempts — including downgrade attacks trying to force a session back to classical-only crypto.
• Denial-of-service simulation — flood and resource-exhaustion testing against the edge layer.
• Quantum cryptanalysis simulation — a dedicated harness that runs six vectors against the crypto layer on every pass: brute-force against ML-KEM-768 (computationally infeasible at current estimates), a simulated break of the classical side alone (the hybrid holds because ML-KEM-768 is still required), harvest-now-decrypt-later replay with an incorrect post-quantum key (fails at AES-GCM authentication), ML-DSA-65 signature forgery and single-bit tampering (detected immediately), nonce replay (blocked by per-message randomness), and a legitimate-owner decrypt path run every time as a control.

An authorized external penetration test against the live installation, using the same tools and techniques real attackers use, validated nine security domains: every deception node active and issuing canary tokens; security headers present and enforced externally; admin paths blocked or redirected into traps; injection and RCE attempts blocked; TLS enforced with no version leakage; file-integrity monitoring confirmed across every watched target; every background service healthy; and an encrypted PDF report generated and archived for the audit trail. The latest full pass came back 65 checks passed, 2 warnings, 0 failures — and it doesn't stay at that number by accident, because the same battery gets re-run on a fixed cadence, not once a year. A regression shows up at the next pass, not at the next annual audit.

Production numbers

These aren't lab figures — they're pulled from a live installation running continuously:

• 2,000+ hostile sources permanently blocked
• 11 active deception nodes
• <1s average containment time from first contact to block
• 700+ critical files under continuous integrity watch
• 65 / 2 / 0 — pass / warn / fail on the latest independent pentest pass

Live signal

A cached, sanitized dashboard pulled periodically from the running installation — not a real-time stream, and not sample data. Every number and every log line reflects a real event, reduced to an aggregate or a generic category; no IPs, ports, paths, or service names ever leave the platform for this.

What the security team sees, all day

The live signal above is a public sliver of a private view. Day to day, everything about SENTINEL is watched through one authenticated, loopback-only dashboard, organized into five views:

Notification status runs on two tracks that never depend on someone watching the screen. In-dashboard, an event is visible within about a second of happening, as covered above. In parallel, everything also rolls up into a scheduled encrypted digest on a fixed interval, so a standing record exists whether or not I was looking at the moment it mattered.

Why publish this

I'm deliberately not publishing exact ports, file paths, or credentials here — that would just be handing a map to the same scanners the deception grid is built to catch. What I am publishing is the architecture and the discipline behind it, because the discipline is the actual differentiator: a platform that tests itself against real attack classes on a real schedule, built on cryptography that's already ahead of a deadline most of the industry hasn't started planning for.

← All articles

Research and direction by Ioannis (John) Konstas; compiled and finalized with AI assistance.