The security boundary of the teaching service is deliberately small: a local process runs simulated experiments for its operator. That boundary determines what its controls can reasonably promise. The website hosts a browser simulator and reading material; it does not host the Python process or expose the loopback service to the internet.
Start with the assets. The operator wants to protect local compute capacity, stored run records, and the interpretation of results. A caller who can submit work can consume resources. A caller who can cancel or alter another run can change its outcome or destroy confidence in its evidence. Those concerns remain relevant even when the quantum workload is small.
What the local service actually enforces
The Python HTTP listener binds to 127.0.0.1. Its request handler checks the expected Host header and permits only an absent Origin or its exact loopback origin. Cross-origin preflight requests are rejected. The submission route accepts a bounded JSON body and validates the configuration before execution.
Two active worker slots bound admitted simulation tasks. A third submission receives HTTP 429 while both slots are occupied. That protects this small teaching service against an unbounded work queue; it is not comprehensive denial-of-service protection. Request-handling threads and local machine resources still require operational judgment.
The service has no user accounts, authentication tokens, or tenant authorization model. Loopback binding narrows network reachability, but it does not distinguish trusted and untrusted processes belonging to a local user. The database and its directory should therefore be treated as local application data, under the operating system's access controls.
These implementation details explain why a public webpage should not attempt to use this endpoint as a hosted backend. The browser lab runs its own simulation. If you start the optional Python API, local clients communicate with your own machine.
Worked example: separate access failures from scientific outcomes
Start the installed local service:
quantum-ops --db security-lab.sqlite3 serve --port 8765Its submission endpoint is POST /runs, and inspection uses GET /runs/RUN_ID. The request body selects a scenario and may specify the supported configuration overrides. The service returns a job identifier after admission, not a promise that the quality criteria have passed.
The test suite exercises hostile Host and Origin values and expects HTTP 403. That is an access-boundary result. The invalid-provenance scenario instead completes the measurement workflow and fails evidence validation. The degraded scenario produces valid evidence and rejects a scientific quality claim. These three failures need different responses: refuse the caller, investigate the evidence, or examine the measured operating quality.
An integrity digest also addresses a narrower question than authentication. It detects inconsistency relative to its recorded value; it does not identify who supplied the record. Refer to Reproducible Runs and Experiment Data before treating a correctly hashed file as trusted evidence.
Extending the boundary is a new design
For a proposed multiuser deployment, represent a human or service principal separately from a run identifier. A run identifier is a lookup key, not a credential. Authorization must determine whether the principal can submit, inspect, cancel, or export that particular run. The check belongs at each operation, including artifact retrieval.
Worker credentials should be limited to the resources needed by their tasks. A provider credential, a storage credential, and an administrator's authority serve different purposes. Passing a broad administrator token through every stage increases the consequences of a compromised worker.
A public service would also need a considered authentication mechanism, transport protection, tenant quotas, credential handling, operational monitoring, and data-retention policy. These are architectural requirements for that extension; the local lab does not implement or claim them. Publishing the existing listener behind a public proxy would not supply the missing authorization model.
Exercise and worked answer
A team proposes to expose the local API publicly and use its unpredictable job identifiers as access control. It plans to keep the same database and evidence hashes. Is that sufficient?
Worked answer: No. Knowledge of a job identifier currently permits lookup through the implemented routes; there is no principal-to-job permission check. Unpredictability cannot establish ownership or safely authorize cancellation. The team needs explicit identity and operation-level authorization, plus a threat model for the newly public boundary. Evidence hashing does not fill that gap because it concerns record consistency, not caller authority.
For the present exercise, keep the service on loopback. Use the browser lab for the website experience, and use the local project to inspect how a clearly bounded service enforces the controls it actually has.