Security and privacy

Publishing research records introduces risks that do not exist in a local-only installation.

Separate planes

• Research plane — private engine, data, holdout, execution sandbox, and scientific ledgers.
• Publication plane — signed, redacted, read-only records.
• Submission plane — quarantined untrusted uploads and claims.

Use separate credentials and storage for each plane.

Never publish

• .env contents or API keys;
• confirmation reserve data or burn paths;
• private or licensed source files;
• proprietary raw datasets;
• local absolute paths and usernames;
• model prompts containing private material;
• unrestricted audit payloads;
• arbitrary generated code before review.

Upload controls

If public submission is enabled:

• restrict types and byte sizes;
• malware-scan and parse in isolation;
• treat documents as untrusted data, not instructions;
• require redistribution and processing attestations;
• strip active PDF content where possible;
• prevent server-side URL fetching by default;
• enforce per-user and global compute budgets;
• queue all work rather than executing synchronously.

Public identifiers

Use opaque public record identifiers. Do not expose internal filesystem layout. Preserve cryptographic links to receipts and versions without revealing secret or private inputs.

Incident response

The publication layer needs a revocation banner and supersession mechanism for privacy or licensing incidents. Removing public access does not rewrite the private append-only scientific record.