DEV Community: conchaestradamiguelangel-droid

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