This is development software. The preserved browser reader contains public practice answers and editable scores. It is unsuitable for secure examinations or confidential student records.

Use synthetic data. Server account records, session secrets, provider credentials and production assessment specifications must be excluded from Git/frontend assets. Public repository authoring solutions are intentionally discoverable. Production deployments may mount protected assessment packages from a separate read-only server directory using COURSELAB_PRIVATE_ASSESSMENTS_PATH; private:// sources are confined below that root and never fall back to public course content. Missing or changed files fail closed, and enrollment pins their checksum. No shipped course currently references a protected assessment or claims to provide graded coursework.

Never execute submitted code in the API. The future runner requires ephemeral containers with no network, Docker socket, host mounts or writable base filesystem; bounded CPU, memory, processes and runtime; temporary submission storage; and an explicit dependency allowlist. Code assignments stay disabled until isolation is implemented and adversarially tested.

Provider keys remain server-side, logs scrubbed, deterministic scores authoritative. Learner text, sources and model output are untrusted. Feedback cannot authorize tools, access solutions or change policy.

Instructor appeal review is disabled for every account by default. Registration cannot set an instructor role, and email addresses are not used as authorization. An operator may grant or revoke the persisted role with python -m courselab.manage_instructor <user-id> grant|revoke after verifying the person's identity and review authority outside the application. There is no HTTP role-assignment route. Instructor self-review and guest adjudication are rejected. The queue resolves the saved variant and checks its question-specification digest; adjustments and upheld decisions are blocked if the exact current specification cannot be verified. Historical package archives and institutional account verification are not implemented, so operators must provision carefully and deployments should not describe this as a staffed or accredited review service.

Appeal decisions remain separate from immutable automatic attempts. The current review path reconstructs the selected variant and compares the saved specification digest against the installed package. It cannot load retired package versions because immutable content archives are not implemented; those appeals can only be declined. Deleting a learner removes their appeal data; deleting a reviewer anonymizes their reference while preserving the decision audit. No general role-management UI or protected exam workflow exists.

Report vulnerabilities through GitHub private vulnerability reporting if enabled, or an established private channel to the owner. Include version, synthetic reproduction and impact; omit credentials and personal data. No penetration test or security certification is claimed.

Production Compose sets adjustable CPU/memory caps for the API, database and migrations, plus fixed caps for nginx and Caddy. The defaults are initial bounds, not measured capacity; operators must load-test and tune them for expected concurrency and data volume.

PostgreSQL uses a bootstrap account for initialization and Alembic migrations, and a separate courselab_app account for API requests. The runtime account is not a superuser, cannot create databases/roles or create schema objects, and receives only table CRUD and sequence grants, including default grants for objects created by later migrations. This narrows the impact of an API compromise but does not isolate learner rows: the account can access every application record and archived assessment key, while ownership checks remain in application code and no row-level security policy is enabled. Keep both credentials and database backups restricted.