Sovereign Deployment
QUORUM is designed to operate entirely within institutional boundaries. No decision data, behavioral signal, model weight, or cryptographic key material is required to leave the institution's sovereign infrastructure. The institution controls all enforcement actions, all audit data, and all cryptographic signing keys.
Three supported deployment topologies span a range from fully air-gapped on-premises to managed single-tenant cloud. All three topologies maintain the core sovereignty invariant: the institution retains cryptographic co-signing authority and no decision enforcement data is shared with any third party.
Full stack deployed within the institution's own data center or private cloud. No external network connectivity is required for decision enforcement — all pipeline stages, rule evaluation, model inference, and audit ledger operations are fully on-premises. External TSA timestamp anchoring and OSINT intelligence feeds are available as optional, configurable integrations.
Core enforcement and audit stack on-premises with optional connectivity to QUORUM's shared intelligence feeds. Intelligence feed contributions are anonymized aggregate threat signals — institution-specific session data, entity profiles, and verdicts are never transmitted. External TSA anchoring is enabled. The institution can disconnect from shared feeds at any time with no impact on core enforcement operations.
QUORUM manages infrastructure on dedicated single-tenant cloud instances. The institution retains cryptographic co-signing authority via its FROST key share — no verdict can be finalized without the institution's participation. Physical and logical isolation from all other deployments is enforced at the infrastructure level. The institution has full audit access to infrastructure logs.
Raw session data and behavioral signal vectors
Entity profiles, risk scores, and session histories
Audit ledger contents and finalized verdict records
Model weights and rule configurations
Cryptographic key material of any kind
Anonymized aggregate threat intelligence contributions — no session-level data, no entity identifiers
RFC 3161 TSA timestamp requests — contain only SHA-256(accumulator_root), no decision content, no session data
OSINT IP reputation queries — configurable via local cache or anonymizing proxy to prevent correlation
The institution holds the FROST co-signing key share. Audit verdicts require the institution's key share to achieve threshold. If QUORUM's infrastructure is compromised, the attacker cannot forge signed verdicts — they lack the institution's key share. Compromise of one party is insufficient to produce a valid threshold signature.
FROST key generation is performed as a documented, auditable ceremony. The institution generates its own key share in its own environment. QUORUM never has access to the institution's share. The ceremony is logged and can be independently verified.
Key rotation is supported via FROST's proactive refresh protocol. Shares are rotated without changing the group public key — existing verification material remains valid. Rotation events are logged to the governance ledger with the new share commitment.
All verdicts signed under a prior key version remain verifiable against the historical group public key. Key version is recorded in the verdict signature envelope. Historical audit artifacts do not become invalid on rotation.
In fully air-gapped deployment, the decision pipeline operates with zero external network dependency. All updates — threat intelligence, model weights, rule changes — are delivered via signed offline packages. No component requires outbound connectivity to function.
Before any deployment package is accepted into a sovereign environment, a mandatory integrity verification procedure ensures that the package is authentic, unmodified, and traceable to a specific published version. No unauthorized code can be introduced without a verifiable signature chain.
The deployment package carries an ML-DSA-65 signature computed by QUORUM's published signing key. The receiving environment verifies this signature before extracting any package contents. Signature failure halts installation.
Package contents are hash-verified against the included manifest. Every file in the package carries a SHA-256 hash in the manifest. Any file addition, modification, or removal between signing and installation is detected.
Successful installation is logged to the governance ledger with the package version identifier, the ML-DSA-65 signature, and the installation timestamp. The deployment history of any sovereign installation is traceable from governance ledger state alone.
// Deployment package verification flow
1. receive(package)
2. verify_signature(package.sig, QUORUM_ML_DSA_65_PUBKEY)
→ FAIL: halt, log rejection event
3. verify_manifest(package.contents, package.manifest)
→ FAIL: halt, log tamper detection event
4. install(package.contents)
5. ledger.append({
type: "DEPLOYMENT_INSTALL",
version: package.version,
sig: package.sig,
ts: now(),
signed_by: governance_key
})
// No package is executed before steps 2 and 3 complete successfully.
// Signing algorithm: ML-DSA-65 (FIPS 204 / CRYSTALS-Dilithium3)