{"id":"a43fbbc1-a4f9-44f3-89da-6fcd4acdb68c","arxiv_id":"2507.17712","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":1.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey of quantum software security challenges in multi-tenant cloud environments, summarizing known attacks and calling for isolation mechanisms, security-aware compilers, and side-channel mitigations.","lead":"This paper surveys security risks from running multiple quantum programs on the same cloud hardware at the same time. It collects known attack methods, such as crosstalk interference, swap injection, qubit sensing, and pulse-level attacks, and urges the community to build isolation and mitigation before confidential data is processed on shared quantum machines.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The survey's central policy conclusion depends on the unverified assumption that multi-tenant co-execution will be offered by quantum cloud providers; without a concrete threat model in which tenants can influence co-placement, the surveyed attacks are future scenarios rather than present risks.","rationale":"The reader's conditional verdict is reasonable. The paper is a competent survey, and it candidly flags its proof-of-concept status and known countermeasures. The load-bearing issue is not the accuracy of any individual summary but the step from isolated demonstrations to a general policy conclusion. That step rests on an economic prediction (providers will adopt multi-programming) and an unarticulated threat model (users can create adversarial co-placement). Since the paper itself notes several attacks are theoretical or require favorable conditions, the conclusion overstates the present situation. This does not invalidate the survey; it should be accepted with the condition that the authors state the threat model and the adoption assumption explicitly, as the reader already recommended. No change to the verdict is needed.","tokens_in":7336,"tokens_out":7159,"duration_ms":88911,"concrete_test":"Audit the 2025-2026 public API documentation, QPU specifications, and published access policies of IBM Quantum, AWS Braket, Microsoft Azure Quantum, IonQ, and Quantinuum, and determine for each: (1) can two independent tenant jobs execute concurrently on one QPU; (2) can a user request specific qubit layouts that create adjacency between circuits from different tenants; (3) is pulse-level or similarly low-level control exposed to end users? Then map each attack in Section III onto the resulting abilities. If no provider exposes multi-tenant co-scheduling, the motivating premise in Section III is unsupported and the conclusion should be reframed as future risk; if at least one does, the premise is confirmed and the paper's warning is timely.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The conclusion that \"the present situation already paints a stark picture\" is not supported by the survey's own evidence. Section III motivates the whole paper with the assertion that providers \"can reasonably expect them to turn to multi-programming to increase profitability,\" but no evidence or timeline is given. More importantly, the attacks are each demonstrated under a favorable but unstated threat model: crosstalk (Section III-A) on two specific five-qubit topologies; adversarial SWAP injection (Section III-B) on a 20-qubit simulator with user-chosen occupation; qubit sensing (Section III-C) requires prior reference signatures and exact knowledge of the victim's qubits; higher-energy state attacks (Section III-D) are admitted by the paper to be currently theoretical because circuit-load delays are too long; circuit reconstruction (Section III-E) achieves only 65% accuracy on single-gate circuits. None of these results is shown to be mountable through a current cloud API in which a provider-controlled scheduler mediates co-placement of independent tenancy. If real schedulers never expose user-controllable co-placement on one QPU, or if pulse access remains restricted, the central claim that new isolation and compiler mechanisms are required before confidential workloads can be processed loses its present-tense force. This is a scope and evidence gap, not an internal inconsistency.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"Ovaskainen, Haghparast, and Mikkonen survey software security challenges in quantum cloud environments that may adopt multi-programming, in which multiple circuits run concurrently on one QPU. The paper summarizes six attack classes drawn from the literature: crosstalk denial-of-service/result corruption, adversarial SWAP injection, qubit sensing, higher-energy state and QubitHammer pulse-level attacks, circuit reconstruction from side-channel measurements, and hardware blueprinting. It closes with a call to action listing six research directions (isolation mechanisms, security-aware compilers, side-channel mitigation, benchmarks, hardware-software co-design, crosstalk mitigation). The authors do not perform new experiments; the contribution is a synthesis and risk assessment.","tokens_in":7552,"tokens_out":4623,"duration_ms":46589,"significance":"If the premise of widespread multi-programming is accepted, the paper provides a useful and largely accurate map of a young literature, and the descriptions of cited attacks match the sources. Its explicit acknowledgment that most attacks are proofs of concept is honest, and the call-to-action items are concrete. The main limitation is that the motivating premise is assumed rather than evidenced, and the conclusion overstates the current risk level. With revision, the paper could serve as a balanced entry point for researchers and practitioners.","major_comments":[{"comment":"The claim that cloud providers 'can reasonably expect them to turn to multi-programming to increase profitability further' is presented without evidence or citation. This is load-bearing because the entire survey's relevance depends on the adoption of multi-programming by commercial providers. Please either cite evidence of existing or planned multi-programming offerings (e.g., provider roadmaps or academic-industry collaborations) or explicitly reframe the paper as a preemptive analysis of a hypothetical future scenario. The current phrasing makes an untested assumption sound like an industry trend.","section":"Section III, first paragraph"},{"comment":"The conclusion that 'the present situation already paints a stark picture' is not supported by the body of the paper. Section III states that most attacks were proofs of concept with known countermeasures (III-A through III-F), and III-D explicitly describes higher-energy state attacks as 'mostly theoretical' due to circuit-loading delays. Recommending a sharper distinction between attacks demonstrated on current hardware and attacks that require future conditions (e.g., reduced load delays or a scheduler that allows co-placement) would make the conclusion accurate.","section":"Section V, first paragraph"},{"comment":"The statement that crosstalk 'may even be the largest source of errors in quantum computers [9]' is not supported by the cited reference [9], which experimentally characterizes crosstalk errors but does not compare their magnitude against all other error sources. Please qualify this claim (e.g., 'some studies suggest crosstalk is among the dominant error sources') or provide a reference that makes the comparative claim.","section":"Section III-A"},{"comment":"The survey lacks a systematic threat-model summary. Each attack assumes different adversarial capabilities: crosstalk assumes co-placement on connected qubits; adversarial SWAP injection assumes the attacker can occupy specific qubits; qubit sensing assumes prior reference signatures; pulse attacks assume pulse-level access; circuit reconstruction assumes control of the execution queue. A table listing, for each attack, the required capabilities, whether it was demonstrated on real hardware or a simulator, and whether it is mountable through current cloud APIs would greatly increase the paper's practical value and would temper the conclusion about present-day risk.","section":"Section III"}],"minor_comments":[{"comment":"The opening sentence 'Term software security is often used without exact definitions' is missing the definite article; it should read 'The term software security...'.","section":"Section II, first paragraph"},{"comment":"The phrase 'qubits have an unwanted influence on each other' might better be 'unintended influence' to avoid implying malicious intent.","section":"Section III-C"},{"comment":"The sentence 'the delay caused by the loading of circuits on IBM machines is too long for these higher energy states not to collapse' is confusingly worded; consider 'too long for higher energy states to survive until the next circuit is loaded.'","section":"Section III-D"},{"comment":"The phrase 'previously accessible five-qubit IBM quantum computers' is vague; specify the hardware generation or remove 'previously accessible'.","section":"Section III-E"},{"comment":"Reference [2] is a web encyclopedia entry; for a formal survey, consider replacing it with a peer-reviewed definition of software security.","section":"References"},{"comment":"The abstract does not mention that the surveyed attacks are mostly proofs of concept; adding a phrase such as 'several of which are currently proof-of-concept' would set reader expectations.","section":"Abstract"}],"recommendation":"major_revision","confidential_remarks":"The paper is a competent survey, and the references are appropriate. The main issue is the unsubstantiated premise and overstated conclusion; these are fixable in revision. I do not see any citation or novelty concerns; the authors clearly position this as a survey."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a competent survey, not a research contribution. It does not introduce new attacks or data; its value is in collecting six previously published attack classes into a single framing and spelling out research directions. The descriptions of the cited work are faithful and the authors are mostly honest about limitations—they note that most attacks are proofs of concept and that higher-energy state attacks are currently theoretical because circuit-load delays are too long. That honesty is a real strength.\n\nWhat the paper does well: it organizes a scattered literature into a readable map of attack classes (crosstalk, SWAP injection, qubit sensing, pulse-level attacks, circuit reconstruction, hardware blueprinting), gives enough detail to understand each threat model, and its call to action lists sensible areas: isolation mechanisms, security-aware compilers, side-channel mitigation, benchmarking, and hardware-software co-design. Someone new to quantum security could use this as a starting point.\n\nWhere it gets soft: the motivating premise—that cloud providers will adopt multi-programming at scale because it is profitable—is stated without evidence or timeline. The stress-test note is right: the surveyed attacks are all demonstrated under favorable, often self-selected conditions. Crosstalk was shown on two five-qubit IBM topologies; SWAP injection on a 20-qubit simulator where the attacker chooses which qubits to occupy; qubit sensing requires prior reference signatures and exact knowledge of the victim's qubits; circuit reconstruction achieves 65% accuracy on single-gate circuits. None is shown to be mountable through a current cloud API where the provider's scheduler controls co-placement. So when the conclusion says 'the present situation already paints a stark picture,' that overstates what the survey itself established. The paper would be stronger if it explicitly framed these as scenarios contingent on multi-programming adoption and if it specified the threat model assumptions under which each attack applies. This is a scope/evidence gap, not a technical error.\n\nWho is it for: readers who want a compact overview of quantum multi-tenant attack research, not specialists looking for new results.\n\nMy recommendation: send it to peer review. It deserves referee time—the survey is useful and honest enough—but ask the authors to soften the conclusion and make the adoption assumption explicit. With that revision, it would be a solid short survey.","headline":"A well-organized survey of known quantum multi-tenant attack classes; the synthesis is useful, but the paper overstates present risk and leans on an unverified adoption premise.","tokens_in":8044,"tokens_out":2707,"would_cite":false,"duration_ms":27813,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Shared quantum clouds carry a new class of software-security attacks.","keywords":["quantum software security","multi-programming","multi-tenant quantum computing","crosstalk attacks","qubit sensing","adversarial SWAP injection","pulse-level attacks","side-channel attacks"],"falsifier":"Run a controlled co-tenancy experiment on a current multi-programming quantum cloud: execute a victim circuit while a co-tenant repeatedly runs the adversary circuits from the paper—CNOT trains on a shared bus, dense occupation of high-connectivity qubits, and pulse-level hammering—and measure whether the victim's success probability degrades with adversary activity. If the error rate stays flat across all three vectors, or if provider logs show tenants are never co-scheduled, the paper's central threat picture would be falsified.","tokens_in":7133,"feed_emoji":"🔐","tokens_out":9249,"duration_ms":87360,"temperature":0.7,"pith_summary":"This paper argues that the coming practice of multi-programming—running several customers' quantum circuits in parallel on one machine to boost utilization—turns physical imperfections in current quantum hardware into software-security channels. It surveys six concrete attack families: crosstalk-based result corruption and denial of service, adversarial SWAP injection that inflates a victim's gate count, qubit sensing that reads a neighbor's output, pulse-level attacks that flip or read qubits, circuit reconstruction through execution-order side channels, and hardware blueprinting that defeats topology hiding. The takeaway is that shared quantum environments need isolation mechanisms, security-aware compilers, and quantum-specific side-channel mitigations before confidential workloads can be processed. A sympathetic reader would take this as a call to treat co-tenant quantum execution as an adversarial setting rather than a performance-optimization problem only.","feed_headline":"Shared quantum clouds carry a new class of software-security attacks","feed_subtitle":"Co-located circuits let attackers corrupt or read results via crosstalk, qubit sensing, and pulse tricks.","key_machinery":"The carrying mechanism is multi-programming in a shared NISQ environment: multiple quantum circuits are compiled onto the same physical chip, with qubits partitioned among tenants and executed in parallel or in close succession. The physical couplings between partitions—unwanted crosstalk between neighboring qubits and control lines, restricted connectivity that forces compiler-inserted SWAP gates, access to control pulses that reach higher energy states, and queue ordering that lets probing circuits run before and after a victim's—are what each attack exploits. In other words, the architecture that raises hardware utilization is itself the attack surface.","core_discovery":"The paper's central claim is that sharing a noisy quantum computer among multiple programs is not security-neutral: because qubits physically couple through crosstalk, connectivity limits, control-pulse lines, and execution scheduling, a co-tenant can corrupt a victim's results or learn information about the victim's circuit. The evidence assembled is a set of proof-of-concept attacks from the literature—degrading a search algorithm until correct results appear less than a fifth of the time, injecting up to 55 percent more SWAP gates into victim circuits, sensing adjacent qubit values with up to 96 percent accuracy, flipping qubits through pulse-level hammering, and reconstructing single-gate test circuits from side-channel measurements. The paper does not claim these attacks are unsolvable; most have known countermeasures. It claims the countermeasures are partial, that buffer qubits and topology hiding are not enough, and that the exploit-and-patch cycle familiar from classical computing is already beginning in quantum clouds.","pith_inferences":["Beyond the paper, the surveyed attacks suggest an end-to-end side channel is plausible: combining qubit sensing with circuit reconstruction could recover not just a result bit but the full victim circuit, something no single proof of concept currently demonstrates.","A testable extension would be to benchmark how much isolation an error-corrected quantum computer provides; logical qubits may suppress crosstalk, but shared control electronics and calibration data could create new co-tenancy channels.","The classical-cloud analogy implies that quantum providers will need continuous adversarial monitoring, not one-time mitigations, if multi-tenancy becomes standard."],"forward_implications":["If the paper is right, confidential workloads should not be scheduled on today's shared quantum clouds without isolation guarantees, because co-tenants can measurably corrupt or infer results.","Security-aware compilers will need to allocate qubits and schedule gates with adversarial co-tenancy in mind, not just error rates and connectivity.","Buffer qubits and topology hiding are necessary but insufficient: pulse-level attacks can cross large buffers, and hardware blueprinting can recover the topology.","Fully disabling pulse-level access would break legitimate applications such as quantum machine learning, so providers need mediated pulse access and monitoring rather than a simple kill switch.","As program sizes grow and circuit-loading delays shrink, the mostly-theoretical higher-energy-state and alternating-execution attacks become practical."],"supporting_citations":[{"why":"Introduces multi-programming for quantum computers, the shared-execution premise that creates the attack surface the paper surveys.","marker":"[6]"},{"why":"Supplies the experimental crosstalk attack showing a victim's result degrades with the number of adversary CNOT gates on shared connections.","marker":"[10]"},{"why":"Demonstrates adversarial SWAP injection, where occupying well-connected qubits forces extra SWAP gates and inflates victim error rates.","marker":"[12]"},{"why":"Defines the qubit sensing attack that reads a neighbor's measurement result by correlating it with a reference signature.","marker":"[13]"},{"why":"Describes higher-energy-state attacks on reset operations, the basis for the paper's alternating-execution threat model.","marker":"[15]"},{"why":"Reports QubitHammer, a pulse-level attack that induces severe crosstalk even across large buffer qubit regions.","marker":"[16]"},{"why":"Shows a neural network can distinguish which test circuit ran between two probing circuits, the circuit-reconstruction side channel.","marker":"[17]"},{"why":"Demonstrates crosstalk-based fingerprinting that identifies which quantum machine a circuit ran on, defeating topology concealment.","marker":"[18]"},{"why":"Shows timing information identifies the quantum processor in about ten measurements, another hardware blueprinting channel.","marker":"[19]"}],"fun_headline_variants":["Quantum cloud co-tenants can steal your data via crosstalk","Shared quantum computers expose programs to side-channel attacks","Multi-programming quantum hardware brings fresh security threats","When quantum jobs run together, crosstalk becomes a spy","Quantum multi-tenancy: crosstalk and qubit sensing leak secrets"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The threat assessment rests on the assumption that providers will actually co-locate different customers' circuits on the same hardware at scale for profitability and that the cited experimental demonstrations on current machines are accurate; if co-tenancy never becomes common or future hardware removes the noise couplings, the surveyed attacks lose their practical relevance.","fun_headline_variants_meta":{"raw":{"variants":["Quantum cloud co-tenants can steal your data via crosstalk","Shared quantum computers expose programs to side-channel attacks","Multi-programming quantum hardware brings fresh security threats","When quantum jobs run together, crosstalk becomes a spy","Quantum multi-tenancy: crosstalk and qubit sensing leak secrets"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000208,"raw_usage":{"total_tokens":1334,"prompt_tokens":806,"completion_tokens":528,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":422,"completion_tokens_details":{"reasoning_tokens":445}},"tokens_in":422,"tokens_out":528,"duration_ms":5877,"temperature":1.0,"reasoning_tokens":445,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T18:17:44.018736+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a controlled co-tenancy experiment on a current multi-programming quantum cloud: execute a victim circuit while a co-tenant repeatedly runs the adversary circuits from the paper—CNOT trains on a shared bus, dense occupation of high-connectivity qubits, and pulse-level hammering—and measure whether the victim's success probability degrades with adversary activity. If the error rate stays flat across all three vectors, or if provider logs show tenants are never co-scheduled, the paper's central threat picture would be falsified.","supporting_citations":[{"cited_title":"A Case for Multi- Programming Quantum Computers,","cited_arxiv_id":null,"evidence_quote":"Introduces multi-programming for quantum computers, the shared-execution premise that creates the attack surface the paper surveys."},{"cited_title":"Analysis of crosstalk in NISQ devices and security implications in multi-programming regime,","cited_arxiv_id":null,"evidence_quote":"Supplies the experimental crosstalk attack showing a victim's result degrades with the number of adversary CNOT gates on shared connections."},{"cited_title":"Securing NISQ Quantum Computer Reset Operations Against Higher Energy State Attacks,","cited_arxiv_id":null,"evidence_quote":"Describes higher-energy-state attacks on reset operations, the basis for the paper's alternating-execution threat model."},{"cited_title":"Reconstructing quantum circuits through side- channel information on cloud-based superconducting quantum comput- ers,","cited_arxiv_id":null,"evidence_quote":"Shows a neural network can distinguish which test circuit ran between two probing circuits, the circuit-reconstruction side channel."},{"cited_title":"Short Paper: Device- and Locality- Specific Fingerprinting of Shared NISQ Quantum Computers,","cited_arxiv_id":null,"evidence_quote":"Demonstrates crosstalk-based fingerprinting that identifies which quantum machine a circuit ran on, defeating topology concealment."}],"review_version":1}