AgeisQ

A post-quantum migration engine: it finds the servers that are still classical, shows which ones matter most, and fixes them safely with a human in the loop.

Comment

Inspiration

Encrypted traffic recorded today can be decrypted once a large enough quantum computer exists. This is called "harvest now, decrypt later", and it makes the quantum threat a problem today for any data that has to stay secret for years: health records, financial data, government data. NIST finalized the post-quantum key-exchange standard ML-KEM in 2024, and Chrome, Firefox and Cloudflare already use hybrid ML-KEM. But most company web servers, internal services and SSH endpoints are still classical, and nobody knows which of their servers those are, which ones matter most, or how to upgrade them without breaking production.

I wanted a tool that answers all three: find the servers that are still classical, rank them by real risk, and fix them safely, with an AI agent doing the work and a human approving every change.

What it does

AegisQ is a post-quantum migration engine with a React web app and a command line:

  1. Scans: every TLS and SSH server is probed with a real post-quantum handshake. AegisQ builds its own TLS 1.3 ClientHello with a genuine ML-KEM-768 + X25519 key share and offers only that, so a server either completes a quantum-safe key exchange or it doesn't. It also reads SSH key-exchange offers, TLS versions and certificates, and flags plaintext.
  2. Inventories: writes a Cryptographic Bill of Materials (CBOM) in CycloneDX 1.6, validated against the official schema.
  3. Ranks: uses Mosca's inequality. A server is at risk when its data must stay secret ($X$ years) plus the time to migrate it ($Y$) exceeds the time until a quantum computer can break it ($Z$):

$$X + Y > Z$$

Nobody knows $Z$, so it is a slider in the dashboard, and the ranking updates live.

  1. Fixes with agentic AI: Gemma 4 (or Claude, or a deterministic rules planner) is given a goal and eight tools. It decides which server to fix next, reads its config, proposes a one-line change (adding the hybrid group X25519MLKEM768), waits for a named human to click Approve, applies it, runs nginx -t, reloads, and verifies with a live post-quantum handshake. If anything fails, the old config is restored automatically. When a server can't be fixed (our demo includes an nginx built on OpenSSL 3.0), the agent reads the error, explains the root cause, and recommends an upgrade instead of retrying.
  2. Quantum randomness: runs a job on real IBM quantum hardware (100 qubits × 10,000 shots = 1,000,000 bits), measures each qubit's bias and correlations, bounds the true randomness with NIST SP 800-90B, and extracts provably uniform bits with a Toeplitz hash before deriving a 256-bit key.
  3. Measures: the cost of going post-quantum (handshake time and the extra ~2.3 KB per handshake), and the real-world adoption gap between the top websites and the long tail.
  4. Reports: every action goes into a tamper-evident, hash-chained (optionally HMAC) audit log, which the migration report is built from.

Everything can be driven from the web app: type in servers, click Scan, pick Gemma 4, click Start migration, approve each change, and watch the output stream live.

How I built it

  • Python 3.10–3.13, asyncio for 50 concurrent probes, and FastAPI + uvicorn for the REST API.
  • A React dashboard built with Vite into a single bundle that FastAPI serves, under a strict Content Security Policy (no inline scripts, nothing loaded from other sites). It includes the live Mosca slider and ranking, streaming job output, a diff view for approvals, and SVG/canvas charts for the quantum data. The built bundle is committed, so running AegisQ doesn't require Node.
  • Our own TLS 1.3 ClientHello builder and parser and an SSH KEXINIT parser, so the scan doesn't depend on the scanning machine having OpenSSL 3.5. A cross-check mode compares the results against openssl s_client and OpenSSH 10.
  • The agent: a tool-use loop where the model only chooses the next tool. Every safety rule lives in Python, not in the prompt:
    • a strict diff parser that only allows two nginx directives with allowlisted values;
    • approvals bound to the SHA-256 of the exact diff;
    • nginx -t before every reload;
    • automatic rollback.

Gemma 4 runs through Google's OpenAI-compatible Gemini API; the same planner also works with Ollama or LM Studio on a laptop.

  • Quantum module: Qiskit, Qiskit Aer and Qiskit IBM Runtime. I picked the 100 qubits with the lowest readout error and calibrate in the same job. Min-entropy $h$ is the most-common-value estimate at 99% confidence, and the Toeplitz extractor output length is

$$m = \lfloor n \cdot h \rfloor - 2\log_2!\left(\tfrac{1}{\varepsilon}\right)$$

so with $n = 10{,}000$, $h = 0.94$ and $\varepsilon = 2^{-64}$ I keep $m = 9{,}272$ bits per block. The final key is $\mathrm{HKDF}$(quantum bits ‖ local randomness), so it is never weaker than a normal key.

  • A real demo fleet in Docker: nginx 1.29 on OpenSSL 3.5, nginx 1.25 on OpenSSL 3.0, a TLS-1.2-only server, an already-ready server, a plaintext server, and two OpenSSH 10.2 servers.
  • Testing:
    • 226 automated tests, including fake TLS/SSH servers, a fake nginx and a 4,000-case mutation fuzzer for the patch guardrails;
    • scripted "malicious" Claude and Gemma models that try to bypass the rules;
    • k6 load tests;
    • CI on Linux, Windows and macOS, plus integration tests against the real Docker fleet.

Challenges I ran into

  • False negatives are worse than no answer. An old openssl client "fails" a post-quantum handshake even against a server that supports it. So I wrote our own handshake and made the reference tools refuse to run if they are too old.
  • Networks that lie. On networks that intercept TLS (some school and office Wi-Fi), even Cloudflare looks classical. I learned to treat that as a property of the network, not of the server.
  • Some servers can't be fixed by config. ML-KEM needs OpenSSL 3.5+. Instead of hiding that, I made it a planned failure in the demo, and the agent has to diagnose it and roll back safely.
  • Free-tier AI limits. Gemma 4 on the Gemini free tier allows 16,000 input tokens per minute, and our first full run hit it halfway. I fixed it by honouring Google's own retry hint and not resending the model's thinking text each turn. After that, a full fleet migration completed end to end.
  • Making it work for everyone. The first version only ran on Linux (fcntl file locks). I ported locking and process management to Windows, made the CLI read the same .env file Docker uses, and made every API key optional.
  • React under a strict security policy. Moving the dashboard to React meant keeping the same locked-down Content Security Policy: no inline scripts and no CDN. I bundled React and the app into one self-hosted file so the policy didn't need loosening.
  • Being honest about quantum. Quantum-generated bits are not secret from the cloud provider and not device-independent. I had to design the key derivation, and the dashboard's "what is and isn't guaranteed" table, around that.

Accomplishments that I'm proud of

  • A real post-quantum handshake probe written from scratch, verified against OpenSSL 3.5 and OpenSSH 10.
  • An agentic AI that is safe by construction: the model has autonomy but not authority. In our live run, Gemma 4 fixed two servers, correctly diagnosed the unfixable one, rolled it back, and wrote a summary, with a human approving each step and every action in a verifiable audit log.
  • Real quantum hardware in a security tool, with the noise measured and reported rather than hidden.
  • A React web app where a non-expert can type in servers, see which are at risk and why, and fix them with a few clicks.
  • Runs natively on Windows, macOS and Linux, or entirely in Docker, with green CI on all three.

What I learned

  • How post-quantum TLS actually works on the wire: hybrid key shares, HelloRetryRequest, and why key exchange is more urgent than certificates.
  • How to put guardrails in code instead of prompts, and why that matters more as models get more capable.
  • How to quantify randomness from noisy hardware (min-entropy, randomness extractors, statistical tests) and how to communicate the limits honestly.
  • That risk is about time: Mosca's inequality turns "quantum is coming" into a ranked to-do list.
  • Building a React front end that works under a strict Content Security Policy.
  • Cross-platform engineering and testing: file locking, process groups, CI matrices and load testing.

What's next for AegisQ

  • More servers and protocols: Apache, HAProxy, Caddy and cloud load balancers, plus SSH server config fixes, mail (SMTP/IMAP STARTTLS) and VPNs.
  • Post-quantum certificates (ML-DSA) once browsers and CAs support them.
  • Continuous monitoring: scheduled scans, alerts when a server regresses, and a CI gate (aegisq scan --fail-on at-risk) for every deploy.
  • Using the quantum key for real work, such as signing the audit log with a key derived from IBM quantum hardware.
  • Team features: roles, multi-approver rules for critical servers, and a hosted dashboard.

Built With

Share this project:

Updates

Submission history