Prompteus: Confidential Third-Party Safety Auditing with Garbled Circuits, MPC, and PIR

Your system is genuinely clever—using garbled circuits for private verdicts, secret sharing for aggregates, and PIR to hide which probes execute. The sandbagging model passing public audits but failing the PIR-hidden one is a sharp threat model. You're solving something real: Global South regulators can't trust model internals, so you invented a way to audit without revealing them. That's strong.

What lost me: the physics-as-a-service framing feels disconnected from the actual contribution (confidential AI auditing). You reference The Well frame emulators but don't explain why—or whether other black-box simulators would work. Your eval is tight but sparse: only two models tested. I'd want to see how MPC performance degrades at scale or how robust your PIR is against side-channel leaks.

The bigger ask: next week, show us inter-operability with actual deployed services. Right now it's a proof-of-concept. Make it production-ready.

Combining cryptographic privacy (Private Information Retrieval) with ML scientific surrogates to provide honest provenance is an exceptional and novel approach to AI safety. The rigorous execution is commendable, particularly the end-to-end verification showing 0 bits of index leaked to any single server across large random trials. Foregrounding fallback mechanisms and refusing to present deterministic renders as trained scientific output is a highly deployable safety control. As suggested in your future work, replacing the demonstrator garbled-circuit bridge with production MPC primitives would make the system fully deployment-ready.

Instead of treating private retrieval, garbled circuits, and learned surrogates as separate tricks, you fold privacy of intent and honest provenance into a single service and argue convincingly that both are safety controls, and I appreciated that you backed it with randomized verification and a clean-room reimplementation rather than one-off runs. My notes are about reach, not rigor: your "deployable control" story rests on a 16-record demonstrator, the surrogate losses have no baseline to judge them against, and I couldn't find a working code link. I'd add a simple baseline so the held-out loss is interpretable, report latency as the database grows, and publish the repo; I'd also reconcile the Prompteus versus PROMETHEUS title mismatch so the work doesn't undersell itself.