Sensitive Data, Residency, and Confidential Workflows

Quantum computing is often discussed as if workloads are pure math. In practice, the workload may encode proprietary molecules, logistics networks, risk models, defense scenarios, cryptographic inventories, or unreleased product designs. The quantum circuit may look harmless while its parameters, Hamiltonian, constraints, or output distribution reveal sensitive information.

NIST data-classification guidance emphasizes identifying and labeling sensitive data so handling controls can follow the data; NIST SP 800-171 defines requirements for protecting Controlled Unclassified Information in nonfederal systems, and SP 800-53 provides a broad catalog of security and privacy controls [R136]. Quantum platforms should inherit this discipline rather than invent a parallel security model.

76.1 What can be sensitive?

flowchart TB
    Sensitive[Quantum-sensitive material] --> Problem[Problem formulation]
    Sensitive --> Hamiltonian[Hamiltonian coefficients]
    Sensitive --> Circuit[Circuit structure]
    Sensitive --> Parameters[Variational parameters]
    Sensitive --> Calibration[Private calibration state]
    Sensitive --> Results[Raw counts and samples]
    Sensitive --> Claims[Business or scientific claim]

A circuit can leak intent. A benchmark can reveal strategic priorities. A resource estimate can reveal when an organization believes a cryptographic system is at risk.

76.2 Classification before compilation

sequenceDiagram
    participant Owner as Workload owner
    participant Classifier as Data classifier
    participant Compiler as Compiler
    participant Router as Router
    participant Provider as Provider
    Owner->>Classifier: submit problem artifact
    Classifier-->>Owner: label and handling rules
    Owner->>Compiler: compile with label attached
    Compiler->>Router: target requirements and sensitivity
    Router->>Provider: submit only if controls satisfy label

Classification must happen before compilation. Once a workload is transpiled, decomposed, batched, logged, and cached, sensitive intent may be scattered across many artifacts.

76.3 Residency and sovereignty controls

flowchart LR
    Workload[Workload label] --> Policy[Residency policy]
    Policy --> Region[Allowed regions]
    Policy --> Provider[Allowed providers]
    Policy --> Storage[Allowed storage]
    Policy --> Staff[Allowed operators]
    Policy --> Export[Export-control review]

Residency is not just where the QPU sits. It includes:

• where source artifacts are stored
• where compiled artifacts are cached
• where classical optimizer state runs
• where result data is retained
• where support personnel can access evidence
• where backups and telemetry are replicated

76.4 Confidential hybrid loop

flowchart TB
    User[User enclave] --> Encode[Problem encoding]
    Encode --> Compile[Compilation inside enclave]
    Compile --> Tokenize[Redact or tokenize metadata]
    Tokenize --> Submit[Submit minimal workload]
    Submit --> Runtime[Quantum runtime]
    Runtime --> Counts[Counts or expectation values]
    Counts --> Enclave[Private post-processing]
    Enclave --> Evidence[Classified evidence package]

The minimum-submission principle says that the provider should receive only what is necessary to execute the workload under the agreed controls. This is difficult for early quantum platforms because compilation, mitigation, and runtime services may be provider-integrated. Treat the limitation as an explicit risk, not an implementation detail.

76.5 Metadata leakage

flowchart TB
    Metadata[Metadata leakage] --> JobName[Job names]
    Metadata --> Tags[Tags and labels]
    Metadata --> Timing[Submission timing]
    Metadata --> Target[Selected target]
    Metadata --> Shots[Shot counts]
    Metadata --> Parameters[Parameter sweeps]
    Metadata --> Error[Failure traces]

Job tags and dashboards are useful, but they can reveal sensitive intent. The platform should separate operational metadata from sensitive semantic metadata.

76.6 Secure evidence packages

flowchart LR
    Evidence[Evidence package] --> Encrypt[Encrypt]
    Evidence --> Label[Attach classification]
    Evidence --> Hash[Hash artifacts]
    Evidence --> Access[Access policy]
    Evidence --> Retention[Retention policy]
    Evidence --> Audit[Audit log]

Every evidence package should carry classification label, data owner, allowed readers, export-control state, retention rule, provider access summary, redaction state, and deletion instructions.

76.7 Declassification path

stateDiagram-v2
    [*] --> Restricted
    Restricted --> Internal: redacted artifact approved
    Internal --> Partner: legal and data review
    Partner --> Public: claims review
    Restricted --> Destroyed: retention expired
    Internal --> Restricted: risk discovered

A result may become less sensitive after aggregation, redaction, or publication. Declassification should be a workflow, not an informal screenshot.

76.8 Operating rule

A quantum platform should treat problem encodings as data products with security labels. The right question is not “is the circuit sensitive?” The right question is “what can be inferred from the complete workload and its evidence trail?”

flowchart LR
    Artifact[Artifact] --> Inference[Possible inference]
    Inference --> Label[Security label]
    Label --> Control[Handling control]
    Control --> Evidence[Evidence trail]