Security Posture

ABSTRACT

The Quantum Audit CLI runs entirely inside the customer's firewall, reads scheduler logs locally, generates a PDF report on the head node, and never opens a network connection. The only artifact designed to cross the trust boundary is a sanitized JSON manifest, written to a local file only after the customer types a consent token, and moved — if at all — by the customer, by hand, over a channel they choose. This document specifies the threat model, sanitization treatment, control mappings against [NIST SP 800-53], [ISO/IEC 27001], and [SOC 2 TSC 2017], and the incident-handling protocol adopted from [NIST SP 800-61].

Principles

Four invariants. Every section below is a consequence of one of these.

1. 1.1
   On-prem only. The CLI is a GPG-signed single binary (a Docker distribution path is committed on the roadmap, not yet shipped). The CLI's own code imports no network-capable module, enforced by an automated test. Since v0.0.3 each release binary bundles no Python networking modules and no TLS libraries, checked automatically on every release build with the bundle's module list published and signed, and it completes a full audit with networking disabled at the kernel level. Air-gapped environments are supported. Platform: Linux x86-64 with glibc 2.28 or newer; v0.0.3 and v0.0.4 were tested before signing on RHEL/Rocky 8 and 9, Ubuntu 22.04 and 24.04, and Debian 12 and 13.
2. 1.2
   Customer-typed consent. The customer previews the sanitized manifest locally, and the CLI refuses to write it to disk unless the customer types --consent EXPORT-SANITIZED-MANIFEST. The CLI never transmits it; any transfer is a separate manual step.
3. 1.3
   Methodology hash on every artifact. Every PDF report page and every manifest carry the version and hash of the methodology that produced them. The hash pins the scoring math; it is not a signature over the report, and it does not authenticate the binary.
4. 1.4
   Open compliance. Controls are mapped to [SOC 2 TSC 2017], [ISO/IEC 27001], [GDPR Art. 32], [HIPAA §164.312]. Mappings are reproduced in §4 and disclosed in the engagement SOW.

Threat model

2.1 Adversaries

The audit CLI defends against the following adversary classes, in order of effort required:

• A1: Curious insider. An employee of the customer who is authorized to run the CLI but not authorized to see other customers' data. Mitigated by §3 sanitization; no cross-customer data exists in the customer's manifest.
• A2: Network observer. An in-network attacker watching the customer's traffic. The CLI generates none. If the customer later transfers a manifest, it moves over a channel the customer chooses and secures; the payload is already sanitized, and its workload ids are keyed HMACs that cannot be reversed without the customer's key.
• A3: Q-Intercept staff. Engineering staff at Q-Intercept attempting to learn customer-identifiable details from manifests. Mitigated by sanitization at the source: identifying fields are not in the manifest schema, and ids are keyed under a customer-held key Q-Intercept never receives.
• A4: Compromised methodology. A modified CLI distributed to customers. Mitigated by GPG signature verification before running (§4.2). The methodology hash on each report page identifies the scoring constants but is not itself proof the binary is genuine.

2.2 Trust boundary

The boundary runs through a manual transfer the customer performs, if they choose to. Everything left of the boundary stays inside the customer's network. Only the sanitized manifest is designed to cross.

   CUSTOMER INFRASTRUCTURE  (firewalled)                    │   Q-INTERCEPT
                                                            │
   ┌──────────────────────────────────────────┐             │
   │  qintercept CLI  (opens no connections)  │             │
   │                                          │             │
   │   sacct / kubectl JSON / PBS accounting ─┤             │
   │              │                           │             │
   │              ▼                           │             │
   │   ┌─────────────────────┐                │             │
   │   │  Workload classifier│                │             │
   │   │  (15 archetypes)    │                │             │
   │   └──────────┬──────────┘                │             │
   │              ▼                           │             │
   │   ┌─────────────────────┐                │             │
   │   │  PDF report + QSS   │ stays local    │             │
   │   └─────────────────────┘                │             │
   │              │                           │             │
   │              ▼                           │             │
   │   ┌─────────────────────┐                │             │
   │   │  manifest.json      │                │             │
   │   │  (sanitized, HMAC)  │ written local  │             │
   │   └──────────┬──────────┘                │             │
   │              │                           │             │
   │  --consent EXPORT-SANITIZED-MANIFEST     │             │
   │              │                           │ manual,     │  ┌────────────────┐
   │              └──────────────────────────── customer's ─┼─►│ Q-Intercept    │
   │                                          │ channel     │  │ (optional)     │
   └──────────────────────────────────────────┘             │  └────────────────┘
                                                            │
   ── trust boundary ─────────────────────────────────────  │
                                                            │

2.3 Out of scope

Endpoint compromise of the customer's head node is out of scope; the CLI inherits the operating system's trust model. Side-channel attacks against the local PDF artifact are out of scope; the customer is responsible for the PDF's local storage. The security of the customer's chosen transfer channel is the customer's. Quantum-cryptographic attacks against HMAC-SHA256 and the GPG release signature are out of scope until fault-tolerant hardware credibly threatens the underlying primitives; see §5.3 for the policy on methodology revisions triggered by the threat landscape.

Sanitization

3.1 Field-level treatment

The following table is the full schema of what the CLI may include in a manifest, and what it never includes. The manifest is built from categorical results only; raw identifiers are discarded when the logs are parsed, before any manifest exists.

3.2 Customer consent flow

Writing an exportable manifest is gated on a typed consent token. The CLI never uploads anything. Output below is from the bundled sample logs (v0.0.4).

$ qintercept audit --sample --manifest-preview

# Sanitized manifest preview (nothing has left this machine):
{
  "archetype_counts": { "no_candidate": 1, "portfolio_qaoa": 1, "vqe_molecular": 1 },
  "band_counts": { "High": 2, "Not a candidate": 1 },
  "cost_band_counts": { "low": 3 },
  "methodology_hash": "sha256:5586bedd…89cd",
  "methodology_version": "1.0.0-draft",
  "scheduler": "slurm",
  "workload_count": 3,
  "workloads": [
    { "archetype": "vqe_molecular", "band": "High", "cost_band": "low", "id": "4c43dcac0170e66e" },
    ...
  ]
}

$ qintercept audit --sample --export-manifest m.json

REFUSED: manifest export requires explicit consent.
  Review with --manifest-preview, then re-run with:
  --export-manifest m.json --consent EXPORT-SANITIZED-MANIFEST

$ qintercept audit --sample --export-manifest m.json --consent EXPORT-SANITIZED-MANIFEST

Sanitized manifest written LOCALLY: m.json
  Review it, then upload manually out-of-band if you choose. This tool made no network connection.

3.3 Methodology-hash provenance

Every report PDF carries the methodology version and hash in each page footer, and every manifest carries them as fields. A reviewer can pin a report to an exact methodology revision and audit the lineage. Methodology updates never silently revise downstream artifacts; old reports continue to cite the version that produced them.

Compliance

4.1 Mapped controls

The audit CLI distribution and manifest handling carry the following control mappings. Full mapping spreadsheet provided with the engagement SOW.

4.2 Distribution security

The CLI is distributed as a PyInstaller binary, GPG-signed with our release key. SHA-256 checksums and detached signatures are published alongside every release. (Corrected 2026-08-11: an earlier version of this page claimed cosign-signed Docker images with SLSA level 3 provenance. Neither exists yet — the Docker distribution path is committed on the roadmap and will ship only when it carries equivalent signature guarantees.)

bash <<'VERIFY'
set -euo pipefail
V=v0.0.4
BIN="qintercept-${V}-linux-x86_64"
FPR=8E0F6615AF74ED0292BC9DE0327E0EDEF81E63D4
export GNUPGHOME="$(mktemp -d)"                     # throwaway keyring; leaves yours untouched
gpg --quiet --import q-intercept-release-signing-key.asc
gpg --status-fd 1 --verify "${BIN}.asc" "$BIN" 2>/dev/null | grep -q "^\[GNUPG:\] VALIDSIG ${FPR} " \
  || { echo "FAIL: binary signature is not from ${FPR}"; exit 1; }
gpg --status-fd 1 --verify SHA256SUMS.asc SHA256SUMS 2>/dev/null | grep -q "^\[GNUPG:\] VALIDSIG ${FPR} " \
  || { echo "FAIL: SHA256SUMS signature is not from ${FPR}"; exit 1; }
sha256sum -c --ignore-missing SHA256SUMS | grep -q "^${BIN}: OK$" \
  || { echo "FAIL: ${BIN} does not match SHA256SUMS"; exit 1; }
rm -rf "$GNUPGHOME"
chmod +x "$BIN"
echo "OK: ${BIN} verified (signature + checksum, key ${FPR})"
VERIFY

Verifying by hand, gpg will also warn that the key "is not certified with a trusted signature". That warning is expected for a key you have just imported; the fingerprint comparison against this page is the trust check, and the block above performs it. Do not skip it: a download of the key alone proves nothing if the same channel could have been tampered with. A good signature proves the file was signed by the holder of this key; it does not prove the binary matches our source, which is what source review under NDA (§4.3) is for.

Installation instructions verify the signature before running. The signature is the only check on the binary itself: a modified binary run without verification could print any methodology hash, so the hash on a report is not proof of a genuine binary. Scope note: the automated no-network test covers the CLI's own code. For the release binary, v0.0.3 added a build gate: no Python networking modules (socket, ssl, http, urllib.request) and no OpenSSL libraries may be bundled, and each release publishes a signed BUNDLE-MANIFEST.txt listing every bundled module and native file. The binary still contains the Python interpreter and system C library, which can make system calls, so the hard boundary is your own sandbox (for example a container with networking disabled). v0.0.2 bundled networking modules and OpenSSL that the CLI never called.

4.3 Third-party review

The audit CLI source, the sanitization layer, and the manifest schema are open to inspection under mutual NDA during engagement scoping. Independent code review by a customer-nominated firm is supported and is the only path to certifying that the deployed binary matches the published source.

Incident response

The protocol below follows the lifecycle defined in [NIST SP 800-61]: Preparation, Detection & Analysis, Containment, Eradication & Recovery, Post-incident.

5.1 Customer-side incidents

The CLI is the customer's. Incident response on the customer head node is owned by the customer. Q-Intercept is available within 24 hours of notification to assist with manifest re-validation, methodology re-pinning, and engagement re-issue at no charge if the cause is traced to the CLI distribution.

5.2 Q-Intercept-side incidents

An incident is declared when any of the following are detected: accidental disclosure of customer manifest data, or release signing-key compromise. Notification is sent to all affected customers within 72 hours per [GDPR Art. 32].

Recovery includes rotation of the release signing key, re-issue of affected binaries and reports, and a public post-mortem published on this page within 30 calendar days.

5.3 Threat-landscape revisions

When the cryptographic primitives this document relies on become credibly threatened, the methodology version increments and a migration plan is published. The plan is reviewed by the technical advisor once one is seated, and any affected customer under active engagement receives the migrated artifact at no charge.

Publication

6.1 Versioning

This document is versioned independently of the methodology. The methodology is identified by its version and hash; this document by the version and date below. Together they are the canonical reference for any audit, response, or compliance evidence.