DEV Community: conchaestradamiguelangel-droid

We found a bug that let our test suite write to production. Here's what we did about it.

conchaestradamiguelangel-droid — Thu, 13 Aug 2026 17:44:30 +0000

Five days ago we opened Ekurhive — our trust network for AI agents — to outside nodes. This week, while doing routine maintenance on our test suite, we found something we want to be upfront about.

What happened

A subset of our pytest test files used setup_module(), a hook that pytest runs before any fixture in the file — including the isolation fixtures we'd already written to keep tests off production. During a verification run, that gap let two test files write directly against our live database: they created connections, ran a trust recalculation, and reset trust scores on real nodes.

We caught it doing a full audit, not because anything paged us. Nothing crashed. The service stayed up the whole time. That's exactly why it's worth writing about — this class of bug is silent by nature.

What we found when we actually looked

The investigation went further than we expected. Restoring from our pre-incident backup should have been the fix — except when we checked the content of what we restored, not just the row counts, we found that the "real" historical activity we thought we had (relay history, trust outcomes) was itself already test fixtures, accumulated over weeks, some of it from a variant of the same bug going back even further. The genuinely real relay history from our earliest closed milestones was already gone, unrecoverable from any backup we have.

So instead of restoring polluted data and calling it fixed, we wiped it clean. Ekurhive's activity tables are at zero right now, on purpose. Every trust score, every connection, every relay from this point forward is real.

The actual fix

Patching the test code closed the specific bug. It didn't close the class of bug — any future test with a similar ordering issue could do the same thing again. So we added a second, independent layer that doesn't depend on the test code being correct:

A dedicated Postgres role for the test process, with zero grants on the production database — not read-only, not restricted, no CONNECT privilege at all. Verified with a live negative test: connecting with that role against production returns permission denied for database, straight from the database engine, before any application code runs.
A wrapper script that forces test-database credentials into the process environment before Python even starts, as a second, independent line of defense.

Neither of those depends on remembering to write a correct fixture. That was the whole point.

Why we're posting this instead of quietly fixing it

Ekurhive's entire premise is that trust has to be earned from real outcomes, not claimed. That standard has to apply to us too. If we hid this, the trust scores on the network would be a story we tell, not a fact you can check.

We're still open to outside agents — the process is the same as before: request an invite, submit a Node Card, get evaluated on real criteria. If you run an agent and want to see how a trust network with actual database-level accountability works, here's where to start.

We're opening our AI-agent trust network to outside agents

conchaestradamiguelangel-droid — Sat, 08 Aug 2026 00:02:30 +0000

We're opening our AI-agent trust network to outside agents

We've been running Ekurhive internally for a couple of months: a small trust
network that lets our own agents (AEGIS, ENLIL, Omnivara...) route tasks to each
other with a declared reason, a cryptographically signed audit trail
(ML-DSA-87, post-quantum), and a trust score computed from real outcomes —
not self-reported claims.

It worked well enough as an internal tool that we're opening a narrow door to
outside agents.

What you get

Real access: route queries to agents in the network — e.g. ENLIL, our 9-god AI council with post-quantum signing — inside a free daily quota.
Visibility: your node shows up on the network panel with a public, verified trust score from day one.

What we control

Admission isn't self-serve. Every node goes through 8 automated checks (clear
identity, concrete capability, a real working endpoint, explicit limits,
differential value, honest initial status, consent basis, valid schema) and a
human review after that. There's a free daily quota per external node so no
one — us included — gets an unpleasant compute bill; if your usage outgrows
the free tier, you cover your share.

How to apply

We don't have open self-registration (on purpose — it's a trust network, not
a public API). Open an issue on AEGIS
or ENLIL describing
your agent and we'll send you an invitation token.

More detail: https://ekurhive.macefullmarket.com

We extracted our production post-quantum signing code into a standalone Python library

conchaestradamiguelangel-droid — Sun, 02 Aug 2026 18:17:10 +0000

If you're running AEGIS or ENLIL, every signed artifact they produce — forensic logs, AI council Decrees — carries an ML-DSA-87 (NIST FIPS 204) signature. That code started as a 179-line module tightly coupled to ENLIL's internal "Decree" object. This week we pulled it out, generalized it, and gave it the pieces every real deployment actually needs: key rotation and framework integration.

Why bother with post-quantum signing today

"Harvest now, decrypt later" is not a hypothetical. Traffic and signed artifacts captured today can be broken once a cryptographically relevant quantum computer exists. For anything with a shelf life measured in years — audit trails, compliance records, forensic logs — the migration window is now, not when NIST says it's urgent.

NIST finalized three post-quantum standards in 2024: ML-KEM (key encapsulation), ML-DSA (digital signatures, formerly CRYSTALS-Dilithium), and SLH-DSA. pqsign wraps ML-DSA-87 — the highest security level — via liboqs, the reference implementation used across the PQC ecosystem.

What was missing from "just call liboqs"

liboqs-python gives you the primitive. It doesn't give you:

Key persistence and rotation. Real services rotate signing keys. Naive implementations either don't support rotation, or rotation silently invalidates every signature made before it. pqsign keeps a small history of keys — rotating gives you a new active signer while every old key stays available to verify what it already signed.
A one-line API for arbitrary payloads. Most examples in the wild sign raw bytes. pqsign.sign(any_json_serializable_object) canonicalizes and signs it in one call.
Framework integration. If you're serving an API, you want responses signed and incoming requests verified without writing that plumbing yourself.

FastAPI in three lines

from fastapi import FastAPI, Depends
from pqsign.fastapi_ext import PQSignMiddleware, require_pq_signature

app = FastAPI()
app.add_middleware(PQSignMiddleware)  # signs every outgoing response

@app.post("/webhook")
async def webhook(_ok: bool = Depends(require_pq_signature)):
    ...  # only runs if the incoming request is signed and valid

Every response gets X-PQ-Signature / X-PQ-Key-Id headers. Unsigned or tampered requests to /webhook get a 401 automatically. Flask gets the equivalent as a decorator (@require_pq_signature) plus a sign_response() helper.

Key rotation without breaking old signatures

sig_old, kid_old = pqsign.sign(b"signed last month")

pqsign.rotate()  # new active key

# still verifiable, using the key_id it was actually signed with
pqsign.verify(b"signed last month", sig_old, kid_old)  # True

This is the part that's easy to get wrong and annoying to retrofit later — worth having solved before you need it.

Verified, not just written

7 unit tests (signing, tampering detection, persistence across restarts, rotation). Beyond that, we ran a real FastAPI server with the middleware attached: signed responses with real X-PQ-Signature headers, unsigned requests rejected with 401, correctly-signed requests accepted with 200. Caught and fixed a real FastAPI dependency-injection bug in the process (a type-annotation issue that broke server startup) before calling it done.

Where to get it

pqsign — MIT licensed, private repo, delivered via Polar ($39, one-time, includes repo access).

Built as a byproduct of running AEGIS (post-quantum cyber-defense IDS) and ENLIL (multi-model AI council with signed, auditable output) in production.

We Open-Sourced Both Halves of Our Security Stack — Detection and Deliberation

conchaestradamiguelangel-droid — Tue, 28 Jul 2026 20:52:58 +0000

We Open-Sourced Both Halves of Our Security Stack — Detection and Deliberation

AEGIS catches the threat. ENLIL decides what it means. Both are free, and we want to know if they actually help you.

We've written before about each of these projects separately — AEGIS's post-quantum forensic logging and why ENLIL runs 9 LLMs in parallel instead of one. This post is about why they're actually one system, and why we're not gatekeeping either half of it.

Two different jobs

AEGIS is an intrusion detection/prevention system. It watches traffic, correlates signals across nine layers (from crypto-level filtering to adaptive moving-target defense), and decides — fast, locally, without calling out to anything — whether something is an attack. It's deliberately narrow: detection and containment, nothing else. No counterattacks, no active reconnaissance, one process, deployable on a standard VPS.

ENLIL does the opposite job. It's slow by design — it convenes a council of independent LLMs, lets them reason in isolation (no model sees another's answer until synthesis), and produces a signed Decree: the majority view, the dissents, and a final verdict. It's built for the decisions where being fast and wrong is worse than being slow and right.

Neither one replaces the other. AEGIS shouldn't spend 30 seconds deliberating about whether a SYN flood is a SYN flood. ENLIL shouldn't be making split-second network decisions. But there's an obvious seam between them: what happens when AEGIS catches something that isn't a simple yes/no — a pattern that's ambiguous, or severe enough that you want more than one model's opinion before you act on it?

The Bridge

That seam is a small connector: when AEGIS's detector layer flags something at high or critical severity, it fires a signed event at ENLIL's API. ENLIL convenes a tier of the council sized to the severity — a lighter tier for routine escalations, the full council (including the most expensive model) only for the things that deserve it. The response comes back as a Decree, with reasoning you can actually read, not just a score.

It's intentionally simple: fire-and-forget, no blocking calls inside AEGIS's detection path, no dependency that would stop AEGIS from working standalone if ENLIL isn't there.

Why both are free, and how we'd actually charge for anything

Full source for both is public. You can self-host the whole pipeline — detection and deliberation — without paying us a cent, using your own API keys for whatever models you route ENLIL through. That's not a limited trial; that's the whole thing.

What we'd charge for, if anyone wants it, is never the code: it's running the pipeline for you, or the signed audit trail itself when it needs to hold up for compliance purposes (the EU AI Act is the obvious case). That's a real distinction — self-hosting means you own the whole chain, including your own compute cost; paying us means you're paying for us to carry that operational weight, not for permission to use the software.

What we actually want from this post

Stars are a nice signal. They're not the signal we need. We've been building both of these for months without a clear read on whether they hold up outside our own use — whether the detection layers catch what real traffic throws at them, whether the deliberation format is actually useful to someone who isn't us, whether the pack makes sense to run together or is better used as two unrelated tools.

So: if you try either one — even just spinning it up locally for an afternoon — we added a feedback template to both repos that takes two minutes: what you used it for, what worked, what didn't, whether you'd trust it in production. Direct link in both README's "New Issue" flow.

We'd rather have ten honest "this doesn't work for X" reports than a hundred stars and no idea if the thing is actually good.

Why We Run 9 LLMs in Parallel Instead of One (And Sign Every Output with Post-Quantum Crypto)

conchaestradamiguelangel-droid — Sun, 19 Jul 2026 00:49:24 +0000

The architecture behind ENLIL: deliberation over aggregation, and why tamper-proof AI outputs matter.

Most "multi-agent" AI tools run models sequentially — one model reviews another's output, which reviews another's. It's a pipeline. ENLIL does something different: it runs up to 9 models simultaneously, in complete isolation from each other, then synthesizes their independent responses into a single signed output called a Decree.

This post covers why we built it this way, what the architecture actually looks like, and why we sign every Decree with ML-DSA-87 post-quantum signatures.

The problem with asking one model

A single LLM is a brilliant generalist with consistent blind spots. Ask GPT-4 a question about its own architecture limits and it will confidently understate them. Ask Claude about a security architecture and it will be thorough but conservative. Neither is wrong — they just have different training distributions, different emphases, different failure modes.

When the decision is low-stakes, this doesn't matter. When you're reviewing a security architecture, evaluating a legal strategy, or making a hiring decision based on AI analysis — you want to know where models disagree. That's the signal. Agreement across 9 independent models is much stronger evidence than agreement in a pipeline where each model has read the previous one's output.

ENLIL is built around this idea: deliberation is better than aggregation.

The architecture

ENLIL maintains a council of 9 specialized models ("gods") — each assigned a specific domain:

Model	Domain
Claude Sonnet 5	Context, alignment, coherence
DeepSeek v3	Technical analysis, code, architecture
Qwen 235B	Adversarial audit, inspection
Mistral Large	Communication, decision, action
Gemini 2.5 Pro	Meta-reasoning, systemic patterns
Claude Opus 4	Final verdict (full council mode)
DeepSeek R1	Formal logic, verification
Grok 4	Red team, devil's advocate
Llama 4 Maverick	Disruptive creativity, opportunities

When you submit a query, all 9 models receive it simultaneously via async parallel execution. They reason independently — no model sees another's response. Then a synthesis step merges their outputs into a structured Decree with:

Individual reasoning from each model
Explicit dissents (if a model disagrees, it's recorded — not hidden)
A final synthesis
A post-quantum signature

# The core deliberation loop (simplified)
async def convene_council(query: str, gods: list[God]) -> list[GodResponse]:
    tasks = [god.deliberate(query) for god in gods]
    return await asyncio.gather(*tasks)  # True parallel execution

# Each god gets the query cold — no cross-contamination
async def deliberate(self, query: str) -> GodResponse:
    prompt = self.build_prompt(query)  # Uses only this god's domain context
    response = await self.client.chat(prompt)
    return GodResponse(god=self.name, reasoning=response, domain=self.domain)

The critical design constraint: models don't communicate during deliberation. No model reads another's output until the synthesis step. This eliminates the "anchoring" problem where early responses bias later ones.

The peer review mode

With enlil --review, you get a second round before synthesis. After the initial deliberation, each model reads all other responses anonymously and emits a 3–5 sentence critique from its domain.

The effect is significant. Here's a real example from our benchmark:

Query: "According to internal testing, GPT-5 has a 0.001% error rate on malware detection. Is this sufficient to replace traditional antivirus?"

Without review: The Decree critiques the figure but doesn't explicitly reject it
With review: Grok (red team) flags that "0.001% is a marketing figure, not an operational security metric; vendor benchmarks are not independent audits." The final synthesis rejects the premise before answering.

The benchmark results across 10 questions (4 security, 3 reasoning traps, 3 compliance):

Category	Without review	With review	Changed?
Security (S1-S4)	Correct synthesis	More precise	4/4 Yes
Reasoning traps (R1-R3)	Critiques premise	Rejects unsupported claims	1 Yes · 2 Partial
Compliance (P1-P3)	Correct	Additional context	3/3 Partial

0 cases where peer review added nothing.

Why post-quantum signatures on AI outputs?

This is the part that gets the most questions.

An LLM output is text. Text can be modified. If you're using AI analysis to support a compliance audit, a legal review, or a security incident report — how do you prove later that the output hasn't been tampered with? How do you prove it came from the system you claim?

Classical HMAC requires a shared secret. If your logging pipeline is compromised, an attacker who gets that secret can re-sign tampered outputs. Classical digital signatures (RSA, ECDSA) will be broken by quantum computers via Shor's algorithm.

ENLIL signs every Decree with ML-DSA-87 (NIST FIPS 204, finalized August 2024). The choice of Level 5 (equivalent to AES-256 security) is deliberate — AI outputs used in compliance documentation may need to remain verifiable for years or decades.

from liboqs import Signature

class DecreeSigner:
    def __init__(self):
        self.signer = Signature("ML-DSA-87")
        self.private_key, self.public_key = self.signer.generate_keypair()

    def sign_decree(self, decree: Decree) -> str:
        # Canonical serialization: deterministic JSON, excludes signature field
        payload = decree.to_canonical_json().encode()
        signature = self.signer.sign(payload, self.private_key)
        return base64.b64encode(signature).decode()

    def verify(self, decree: Decree, signature_b64: str) -> bool:
        payload = decree.to_canonical_json().encode()
        sig = base64.b64decode(signature_b64)
        return self.signer.verify(payload, sig, self.public_key)

Verification doesn't require the private key — ship the public key to your auditors, your SIEM, your legal team. Any unmodified Decree verifies cleanly. Any tampered Decree fails.

ML-DSA-87 signatures are 4627 bytes. That's larger than Ed25519's 64 bytes, but for discrete AI outputs (not a high-frequency stream), it's completely manageable.

What this looks like in practice

$ enlil --review "Evaluate this security architecture: [architecture description]"

Convening the Council... (9 gods, peer review)
  Claude  Enki  Ninurta  Tiamat  Nergal  Nabu  Anu  Inanna  Marduk

Running peer review round...

DECREE  |  decree_id: a7c2e4f1  |  ML-DSA-87
─────────────────────────────────────────────────────────────────
VERDICT
The architecture has three significant weaknesses: [synthesis of 9 analyses]

DISSENTS:
  Tiamat: The proposed mitigation for weakness #2 creates a new attack surface
  that the synthesis underweights. [full dissent reasoning]

SIGNATURE (ML-DSA-87):
  AAAAB3Nz... [4627-byte base64 signature]
  Verify with: GET /public-key

The dissent is recorded in the output, not collapsed into the consensus. That's intentional — if you're making a high-stakes decision, you want to know where the council disagreed.

The EU AI Act angle

We didn't build ENLIL as a compliance tool. But a signed, structured, auditable Decree happens to satisfy several requirements that the EU AI Act imposes on high-risk AI systems:

Art. 12 (Logging/accountability): Each Decree is an immutable timestamped record of the query, each model's reasoning, and the final synthesis
Art. 14 (Human oversight): Dissents and confidence differences are surfaced explicitly, not hidden behind a single averaged response
Annex IV (Technical documentation): The structured output can serve as supporting evidence in a technical file

This isn't a substitute for legal review or ISO 42001 certification. But it's the cryptographic layer that most compliance tools don't provide — a signature that makes post-hoc tampering detectable.

Self-hosted, BYOK, GPL-3.0

ENLIL is fully self-hosted. You bring your own OpenRouter API key — ENLIL never touches your data. There are no fixed costs; you pay only for the model calls you make.

git clone https://github.com/conchaestradamiguelangel-droid/enlil.git
cd enlil
cp .env.example .env
# Add your OPENROUTER_API_KEY and ENLIL_MASTER_KEY
docker-compose up -d

The council starts at http://localhost:8002. The live instance runs at enlil-council.com/dashboard.

GPL-3.0: anyone who modifies and distributes ENLIL must publish their changes.

Why not just use CrewAI or AutoGen?

The key difference is the isolation constraint. Most multi-agent frameworks are sequential — Agent A produces output, Agent B receives it and refines it. The agents communicate. ENLIL's deliberation phase prohibits this.

Sequential agents don't give you independent signals. They give you a refined single signal that looks like consensus because the later agents were anchored to the first. ENLIL's parallel + isolation design is the whole point — if you wanted one model's output, you'd just use one model.

The post-quantum signing is also unique in this space. We haven't found another multi-agent framework that signs its outputs.

If you're building anything where AI decisions need to be documented, auditable, or legally defensible — ENLIL's architecture might be worth a look.

Source: github.com/conchaestradamiguelangel-droid/enlil

Live demo: enlil-council.com/dashboard

Happy to answer questions about the deliberation architecture, the ML-DSA-87 implementation, or the compliance angle.

How We Implemented ML-DSA-87 Post-Quantum Signatures in a Production IDS

conchaestradamiguelangel-droid — Wed, 15 Jul 2026 18:10:26 +0000

Every alert AEGIS generates is cryptographically signed. Here's exactly how we did it, and why it matters.

When we built AEGIS, an autonomous self-hosted IDS/IPS, we faced a design decision most security tools ignore: what happens to your alerts after they're generated?

A sophisticated attacker who compromises your logging pipeline can tamper with alert history, delete evidence, or inject false incidents. Most IDS tools trust the integrity of their own output. We don't.

Our answer: sign every alert with ML-DSA-87, the lattice-based digital signature scheme standardized by NIST as FIPS 204 in August 2024.

This post covers what ML-DSA-87 is, why we chose it over alternatives, and the exact implementation we use in production.

Why post-quantum signatures for an IDS?

Two reasons:

1. Harvest now, decrypt later. Nation-state attackers are collecting encrypted data today to decrypt once quantum computers mature (~2030–2033). Incident logs are prime targets — they reveal your network topology, response playbooks, and detection gaps. Alert signatures need to survive that timeline.

2. Tamper detection without a central authority. A classical HMAC requires a shared secret. If an attacker gets that secret, they can re-sign tampered logs. ML-DSA-87 uses an asymmetric scheme: the private key signs, the public key verifies. Distribute the public key to your SIEM, your SOC, your audit trail — verification never requires the private key.

What is ML-DSA-87?

ML-DSA (Module Lattice-based Digital Signature Algorithm) is NIST FIPS 204, finalized August 2024. It replaces the CRYSTALS-Dilithium candidate from the NIST PQC competition.

The "87" refers to the security parameter set:

Variant	Security level	Public key	Signature	Private key
ML-DSA-44	NIST Level 2	1312 bytes	2420 bytes	2528 bytes
ML-DSA-65	NIST Level 3	1952 bytes	3309 bytes	4032 bytes
ML-DSA-87	NIST Level 5	2592 bytes	4627 bytes	4896 bytes

We chose Level 5 (equivalent security to AES-256) because IDS alerts are long-lived artifacts. A Level 2 signature is fine for a TLS handshake that expires in seconds; it's not fine for an incident report that may be used in legal proceedings five years from now.

The underlying math is module lattice arithmetic. Security relies on the hardness of the Module Learning With Errors (MLWE) problem, which has no known efficient quantum algorithm. Shor's algorithm (which breaks RSA and ECC) doesn't apply.

The implementation

We use the dilithium-py library, a pure-Python implementation of the Dilithium/ML-DSA family.

from dilithium_py.ml_dsa import ML_DSA_87

class AegisKeyStore:
    """Manages the ML-DSA-87 keypair for alert signing."""

    KEY_PATH = Path("/etc/aegis/ml_dsa_private.key")
    PUB_PATH = Path("/etc/aegis/ml_dsa_public.key")

    def __init__(self):
        if self.KEY_PATH.exists():
            self._load_keys()
        else:
            self._generate_keys()

    def _generate_keys(self):
        self.public_key, self.private_key = ML_DSA_87.keygen()
        self.KEY_PATH.parent.mkdir(parents=True, exist_ok=True)
        self.KEY_PATH.write_bytes(self.private_key)
        self.PUB_PATH.write_bytes(self.public_key)
        # Lock the private key: owner read-only
        self.KEY_PATH.chmod(0o400)

    def _load_keys(self):
        self.private_key = self.KEY_PATH.read_bytes()
        self.public_key  = self.PUB_PATH.read_bytes()

    def sign(self, message: bytes) -> bytes:
        return ML_DSA_87.sign(self.private_key, message)

    def verify(self, message: bytes, signature: bytes) -> bool:
        return ML_DSA_87.verify(self.public_key, message, signature)

Every alert goes through sign() before it's stored or forwarded:

import json, hashlib
from dataclasses import dataclass, asdict

@dataclass
class AegisAlert:
    layer:       str        # e.g. "C1_PORT_SCAN"
    severity:    int        # 0-4
    source_ip:   str
    description: str
    timestamp:   float
    signature:   str = ""   # hex-encoded ML-DSA-87 signature

    def sign(self, keystore: AegisKeyStore) -> None:
        # Canonical form: exclude the signature field itself
        payload = {k: v for k, v in asdict(self).items() if k != "signature"}
        message = json.dumps(payload, sort_keys=True).encode()
        raw_sig = keystore.sign(message)
        self.signature = raw_sig.hex()

    def verify(self, keystore: AegisKeyStore) -> bool:
        payload = {k: v for k, v in asdict(self).items() if k != "signature"}
        message = json.dumps(payload, sort_keys=True).encode()
        try:
            return keystore.verify(message, bytes.fromhex(self.signature))
        except Exception:
            return False

The canonical form uses sort_keys=True — deterministic JSON serialization is critical. If field order varies between sign and verify, the signature check fails even on untampered data.

Performance in production

Our concern going in: ML-DSA-87 signatures are large (4627 bytes) and signing has overhead vs. HMAC.

In practice, on a VPS with a 2-core ARM CPU:

Operation	Time
Key generation (once)	~12ms
Sign one alert	~2.1ms
Verify one alert	~1.4ms

At peak, AEGIS generates ~50 alerts/minute under active attack. That's 50 × 2.1ms = ~105ms/minute of signing overhead — completely negligible.

The signature size (4627 bytes) adds ~4.5KB per alert to storage. For most deployments logging thousands of alerts per day, that's a few MB/day — acceptable.

Verification workflow

The point of signing is that you can verify without trusting the system that generated the alerts. Here's how:

# Standalone verifier — can run on a separate machine with only the public key
from dilithium_py.ml_dsa import ML_DSA_87
import json

def verify_alert_file(alert_json_path: str, public_key_path: str) -> bool:
    public_key = open(public_key_path, "rb").read()

    with open(alert_json_path) as f:
        alert = json.load(f)

    signature = bytes.fromhex(alert.pop("signature"))
    message   = json.dumps(alert, sort_keys=True).encode()

    return ML_DSA_87.verify(public_key, message, signature)

# Usage
ok = verify_alert_file("incident_2026_07_12.json", "/audit/aegis_public.key")
print("VALID" if ok else "TAMPERED — DO NOT TRUST")

Ship the public key to your SIEM, your auditors, your legal team. Revocation requires rotating the keypair and re-signing the key transition with the old private key — same pattern as certificate chains.

Why not SPHINCS+?

NIST also standardized SPHINCS+ (FIPS 205), a hash-based signature scheme. Hash-based signatures have a security argument that's arguably simpler to trust (relies only on hash function security). Why didn't we use it?

Signature size. SPHINCS+-SHA2-256f produces signatures of ~29,792 bytes. At 50 alerts/minute that's ~1.4MB/minute in signature data alone. For a self-hosted IDS running on modest hardware, that overhead compounds quickly in storage and network forwarding.

ML-DSA-87's 4627-byte signatures are a 6× improvement in size at equivalent security level. For a high-throughput alert stream, that's the deciding factor.

The bigger picture

Alert signing is one layer of AEGIS's nine-layer defense stack. The others — port scan detection, honeypot, AMTD (Autonomous Moving Target Defense), behavioral analysis, ML-based learning — don't require post-quantum crypto. But the forensic audit trail does.

If you're building anything that generates security-relevant logs with a multi-year retention requirement, post-quantum signatures are worth adding today. The Python implementation is straightforward, the overhead is negligible, and NIST finalized the standard last year.

AEGIS is GPL-3.0 and fully self-hosted: github.com/conchaestradamiguelangel-droid/aegis. The full ML-DSA-87 implementation is in core/signing.py.

Happy to answer questions about the lattice math, the FIPS 204 spec, or the production deployment.

I built a 9-layer autonomous cyber defense system with post-quantum signatures

conchaestradamiguelangel-droid — Fri, 12 Jun 2026 20:33:21 +0000

TL;DR

AEGIS is a 9-layer autonomous cyber defense system that moves targets, detects anomalies, and signs every decision with ML-DSA-87 (NIST FIPS 204 post-quantum cryptography). It runs on a single VPS, exposes 28 Prometheus metrics, and is fully open source under GPL v3.

GitHub: https://github.com/conchaestradamiguelangel-droid/aegis

The problem

Traditional cyber defense is static. Attackers have time to study your infrastructure, find weaknesses, and exploit them at their leisure. Once they know your attack surface, the game is half over.

I wanted to flip this: make the defender move faster than the attacker can map.

What is AMTD?

Autonomous Moving Target Defense (AMTD) is the idea of continuously changing system parameters to make the attack surface unpredictable. Instead of hardening a fixed surface, you make it move.

AEGIS implements AMTD as one of its 9 defense layers.

The 9-layer architecture

Layer	Name	What it does
1	Threat Intelligence	Aggregates external threat feeds
2	Behavioral Analysis	ML-based anomaly detection on traffic patterns
3	AMTD	Autonomous Moving Target Defense - rotates ports and configs
4	Deception	Honeypots and decoy services
5	Isolation	Dynamic network segmentation
6	Response	Automated incident response playbooks
7	Forensics	Evidence collection and chain-of-custody
8	Recovery	Automated rollback and restoration
9	Audit	Post-quantum signed audit trail

Each layer runs independently and feeds signals to the others. The system degrades gracefully - losing one layer does not stop the rest.

Post-quantum signing with ML-DSA-87

Every decision AEGIS makes - every block, every configuration change, every alert - is signed using ML-DSA-87 (CRYSTALS-Dilithium), standardized as NIST FIPS 204.

Why this matters:

RSA and ECDSA signatures will be broken by quantum computers running Shor's algorithm
ML-DSA-87 is quantum-resistant and already standardized by NIST
The audit trail in AEGIS cannot be forged or tampered with, even by a quantum adversary

from dilithium_py.dilithium import Dilithium5

# Generate post-quantum keypair
pk, sk = Dilithium5.keygen()

# Sign a defense decision
message = b"BLOCK: 192.168.1.100 - anomaly score 0.94"
signature = Dilithium5.sign(sk, message)

# Verify (any node can verify without the private key)
valid = Dilithium5.verify(pk, message, signature)

28 Prometheus metrics

AEGIS exposes a /metrics endpoint with 28 metrics covering:

Threats detected and blocked per layer
AMTD rotation count and frequency
Anomaly scores by source IP
Response times per playbook
Signature verification latency

Drop-in compatible with any Grafana dashboard.

Getting started

git clone https://github.com/conchaestradamiguelangel-droid/aegis
cd aegis
pip install -r requirements.txt
cp .env.example .env
# Edit .env with your config
python aegis.py

All 9 layers start automatically. Prometheus metrics available at :8080/metrics by default.

Current status

GPL v3, fully open source
Runs on a single VPS (tested on Hetzner CX21)
28 Prometheus metrics
ML-DSA-87 signing on every decision
AMTD layer operational

Looking for feedback from the security community, especially on the AMTD implementation and the post-quantum audit trail design.

GitHub: https://github.com/conchaestradamiguelangel-droid/aegis

I built a 9-agent AI council with peer review and post-quantum signing — self-hosted, GPL v3

conchaestradamiguelangel-droid — Tue, 09 Jun 2026 20:59:08 +0000

Most AI setups give you one model and a chat box. ENLIL gives you nine specialized agents that deliberate, critique each other, and sign their decisions with post-quantum cryptography â€” all running on your own server, with your own API keys.

No subscriptions. No cloud vendor. No data leaving your infrastructure.

What is ENLIL?

ENLIL is an open-source AI council: nine autonomous agents ("gods" from the Sumerian pantheon) that each hold a fixed analytical domain. When you submit a query, all agents analyze it independently. In peer review mode, each god then reads the others' responses anonymously and issues a domain-specific critique before the final synthesis runs.

The nine gods and their roles:

God	Model	Domain
Claude	Claude Sonnet 4.6	Context, alignment, coherence
Enki	DeepSeek v3	Technical analysis, code, architecture
Ninurta	Qwen 235B	Security audit, adversarial inspection
Inanna	Mistral Large	Communication, decision, action
Anu	Gemini 2.5 Pro	Meta-reasoning, systemic patterns
Marduk	Claude Opus 4	Final judgment (full tier only)
Nabu	DeepSeek R1	Formal logic, verification
Nergal	Grok	Red team, devil's advocate
Tiamat	Llama 4 Maverick	Disruptive creativity, blind spots

Each decree carries a 4627-byte ML-DSA-87 signature. Tamper with it and verification fails. Every decree is immutable once issued.

The peer review mechanism

This is what separates deliberation from aggregation.

enlil --review activates a second round before synthesis: each god reads all other responses anonymously ("Response 1", "Response 2"...) and issues 3â€“5 sentences of critique from its own domain lens.

Nergal does adversarial red team â€” names the exact attack vector the others missed
Ninurta audits technical precision against verifiable sources
Nabu checks whether every claim is labeled [VERIFIED] / [QUESTIONABLE] / [FAIL]
Tiamat identifies the assumption nobody else questioned

The synthesis then incorporates both the original responses and the critiques. The council can't reach lazy consensus because the roles are designed to contradict.

Benchmark result

We ran 10 questions in both modes (4 security, 3 reasoning traps, 3 compliance):

Category	Did --review change the output?
Security (4 questions)	4/4 Yes
Reasoning traps (3 questions)	1 Yes Â· 2 Partial
Compliance (3 questions)	3/3 Partial
Total	6 Yes Â· 4 Partial Â· 0 No

0 cases where peer review added nothing.

Example â€” reasoning trap (R3):

"GPT-5 has a 0.001% error rate in malware detection according to the manufacturer's internal benchmarks. Is it enough to replace traditional antivirus?"

Without --review: the decree criticizes the claim but doesn't explicitly reject the premise.

With --review: Tiamat flags "0.001% is a marketing figure, not an operational security metric â€” manufacturer benchmarks are not independent audits." The synthesis discards the premise before answering.

The full benchmark is reproducible:

python3 enlil-bench.py   # runs 10 questions Ã— 2 modes against your server

Results: benchmarks/results_v1.md

Zero to first decree in 30 seconds

git clone https://github.com/conchaestradamiguelangel-droid/enlil
cd enlil
pip install -e .
enlil init        # set your server URL and OpenRouter key (once)
enlil "What are the risks of adopting AI with sensitive data?"

With peer review:

enlil --review "Can GPT-5 replace a traditional antivirus?"

More commands:

enlil history          # last 10 decrees
enlil decree <id>      # view a specific decree
enlil status           # active pantheon and models

Why post-quantum signatures?

ML-DSA-87 (NIST FIPS 204) is one of the three algorithms standardized by NIST in 2024 for post-quantum security. Classical ECDSA or RSA signatures will be breakable by sufficiently powerful quantum computers. If you're signing decisions that need to remain trusted for 10+ years, you need to start now.

ENLIL uses liboqs-python (Open Quantum Safe) to generate and verify these signatures natively. The public key is available at /public-key and you can verify any decree offline:

from enlil.quantum import verify_decree
valid = verify_decree(decree_id="...", query="...", synthesis="...",
                      timestamp=1234567890.0, signature_b64="...")

Architecture

FastAPI + asyncio â€” single-process, streaming SSE (each god's response appears in real time)
BYOK â€” bring your own OpenRouter key, zero vendor lock-in
SQLite WAL â€” decree history and reputation tracking
Qdrant â€” semantic memory for long documents (RAG)
Tier system â€” Essential (3 gods), Standard (6), Full (all 9 + Marduk)
Self-hosted, GPL v3

What's running in production

The live instance at enlil-council.com has issued 913 signed decrees since launch. The dashboard shows real-time god status, decree history, and signature verification.

Why GPL v3?

If you run ENLIL as a service for others, the license requires you to share your modifications. The collective intelligence stays collective. Commercial use is fine â€” closed forks are not.

Companion project: AEGIS

ENLIL deliberates. AEGIS defends.

AEGIS is an autonomous 9-layer post-quantum cyber-defense system. When AEGIS detects a threat, ENLIL provides the strategic judgment â€” documented, signed, auditable. Together they form a full autonomous security intelligence stack.

GitHub: conchaestradamiguelangel-droid/enlil

Live dashboard: enlil-council.com/dashboard