Proposal: Quantum Job Authorization, Revocation, and Replay Failures

[meridianverity]

A candidate platform-surface entry for Sprint 1 consideration.

The assurance gap

A quantum job may remain correctly linked through transformation and dispatch, execute on the advertised hardware, and return an authentic result, yet still be accepted, altered in scope, or repeated outside the authority granted for that exact logical job.

This proposal addresses whether job-specific authority is defined, scoped, made effective at the declared lifecycle point, delegated within its permitted limits, changed or revoked according to its declared semantics, consumed no more than the permitted number of times, and deduplicated consistently across submission, brokering, provider acceptance, dispatch, retry, cancellation, and completion.

Integrity asks whether it is the same job. Execution assurance asks whether the execution claim is true. This proposal asks whether that exact job was permitted under the declared scope, at the applicable enforcement point, and only as many times as authorized.

Relationship to adjacent work

#16 addresses integrity-verifiable linkage across the submitted job, security-relevant transformations, the dispatched artifact and platform context, and the returned result record.

#22 proposes independent assurance of the underlying physical execution and returned result.

This proposal addresses a third assurance question: whether the authority governing the exact logical job is enforced at its declared lifecycle boundaries and consumed no more times than permitted.

The entries may share individual mitigations, but their primary failure conditions and assurance questions are distinct.

Quantum-platform manifestation

The underlying authorization and replay principles are not unique to quantum computing. Their quantum-platform manifestation is material because one logical workload may cross tenant, broker, provider, queue, and device boundaries; target selection and shot count affect cost and statistical confidence; execution may occur materially after submission; and cancellation behavior may depend on the provider and current job state.

Evidence posture

The attack class is presented as theoretical. Official platform documentation establishes relevant operating conditions, including provider queues, state-dependent cancellation and completion behavior, target- and shot-specific requests, creation-time spending controls that account for queued work, session semantics for previously submitted jobs, and request-level idempotency controls.

Those sources establish the lifecycle conditions under which explicit authority semantics matter. They are not presented as evidence that any named provider is vulnerable, and this proposal claims no production incident, CVE, or quantum-specific proof of concept.

Scope discipline

The proposal does not require universal dispatch-time reauthorization and does not treat delayed execution, state-dependent cancellation, or intentionally durable acceptance as vulnerabilities by themselves. It focuses on required authority constraints that are absent, or declared authority semantics that are ambiguous or enforced inconsistently with what the system represented.

Authentication identifies the actor. Account-level authorization may permit use of the platform. Neither, by itself, defines or consumes authority for this exact logical job.

The proposal does not address compromised credentials or control-plane access, substitution or loss of integrity across job transformation and dispatch, or independent proof of the underlying physical execution and returned result.

Submission format

This candidate is placed in proposals/ pursuant to the 2026 sprint plan, uses the standard entry structure, and intentionally carries no QS number pending Sprint 1 selection.

The current README and open contribution-infrastructure work use different routing conventions. I am happy to make any requested mechanical adjustment to the path, naming, or evidence format without changing the proposal's substance.

The proposal is offered for refinement, consolidation, or boundary adjustment if reviewers conclude that the taxonomy is clearer another way.

[meridianverity]

Greetings @Treyrob3 — since this proposal is intended to sit alongside #16 and #22, I would value your read on whether the boundary is as clear from your side as it appears from mine.

I have tried to keep #23 centered on a distinct question: how authority for the exact logical job is defined, scoped, made effective, delegated, changed or revoked, consumed, and deduplicated across lifecycle boundaries. It intentionally leaves job-lineage integrity to #16 and independent execution and result assurance to #22.

I have also classified the attack class as theoretical and expressly preserved legitimate durable-acceptance and state-dependent cancellation semantics.

No detailed review is expected, but any boundary concern you notice would be very helpful. Thank you again for the thoughtful and constructive collaboration on #22.

[Treyrob3]

Thanks for the ping — the boundary reads clearly from my side, and I think the three-way split holds: same job (#16), true claim (#22), permitted job (#23).

One thing worth naming before Sprint 1: shot count appears in both #22 and #23, in opposite directions. Yours covers an operator raising it beyond what was approved — authority exceeded. Mine lists it under service claims accepted without verification — a provider billing for shots it didn't run. Same attribute, opposite failure. In a diff review that just looks like the same term twice, so it may be worth an explicit clause in one or both entries.

Otherwise I'd frame the relationship as complementary rather than overlapping — several of your failure modes are only detectable if the tenant has execution evidence to begin with, so #22 partly acts as the detection layer for #23.

[meridianverity]

Thanks @Treyrob3 — agreed. The same job / true claim / permitted job triad is a clean boundary, and shot count is exactly the right shared field to make the distinction explicit rather than leave reviewers to infer it.

I’ve added a narrow clarification to #23. For shot count, #23 asks whether the requested or accepted shot count is within the authorized maximum; #22 asks whether a provider’s claim about the number of shots performed is supported by independently appraisable evidence. I also tightened the #23 examples to say “requested shot count above the authorized maximum.”

I agree that the entries are complementary. I would frame #22 as providing evidence that can reveal some #23 violations, rather than as a prerequisite for the #23 failure class as a whole: #23 also covers authority at acceptance, delegation, retry, cancellation, and atomic consumption before or independently of any proof about physical execution.

Thank you for catching this before Sprint 1. It makes the three-way boundary substantially clearer.