Trust & Security

BirthPlace AI is designed for verifiable provenance with minimal data exposure. This page summarizes how public proofs work, what is stored, and how access is controlled.

Data minimization

Proofs are hash-based.

BirthPlace AI anchors cryptographic digests (e.g., SHA-256) and proof metadata. A hash does not reveal the original file contents.

If you choose to store structured provenance JSON, it may be included in the proof record. Do not include sensitive personal data or secrets in provenance fields.

Access control

Wallet-based session gating.

The dashboard is protected by wallet sign-in. Proof records are scoped to the authenticated wallet.

Public proofs are explicitly opt-in. When a proof is marked public, a read-only page and API endpoints can be accessed without sign-in.

Public vs private proofs

Clear separation to avoid accidental disclosure.

  • Private proof: visible only in your wallet-gated dashboard.
  • Public proof: read-only public page + public export endpoints + badge embed.
  • Public endpoints intentionally expose only non-sensitive fields (no wallet address).

Secrets & environment security

Operational controls.

Server-side secrets (e.g., Supabase service role keys, session secret) must be stored as environment variables and never committed to source control.

When deploying, restrict access to project settings and rotate credentials if you suspect exposure.

Responsible use

What you should not store.

Do not include secrets, private keys, passwords, or sensitive personal data inside provenance JSON fields.

A public proof is designed for citation and sharing; treat it as publishable information.

Note: This page is informational and will evolve as BirthPlace AI adds additional controls and operational maturity.