Security & trust

“Private to your team” has to mean something.

Login only answers who can open the door. tertAI also answers who can read each row - and tells you when a rule couldn’t be kept.

Access before render

Apps configured for emails or domains are gated on the server. Uninvited viewers never get the HTML bundle. Owners always pass; invite lists and domains are checked against the signed-in account.

Row-level authorization

Collection policies live next to your data. Examples: hide debrief content until N panelists submit; enforce unique emails; keep ownership rules on updates. The data API refuses to return or accept rows that break the rule - client JS is not the enforcement layer.

Secrets without silent failure

.env files are not published into the site. We scan for obvious live keys (Stripe sk_live, AWS AKIA, private PEMs, DB URLs) and warn at publish time. Owners can store secrets encrypted and inject only keys marked public and named like VITE_ / NEXT_PUBLIC_ / PUBLIC_.

Publish honesty

If we can't run your Express process, we say so. The publish report lists preserved UI, dropped server/SQLite behavior, and unenforced validation. You decide whether to proceed.

Origin isolation

Hosted apps use a CSP sandbox without allow-same-origin, plus isolation headers (frame-ancestors, CORP/COOP). That keeps user apps from reading tertAI's cookie namespace. Distinct usercontent domains remain the long-term hardening step.

Admin controls

Platform admins can list every deploy link, remove an app (cascading files, data, policies, secrets, visits), or delete a user and their connected Supabase data - with confirmation, and with admin accounts protected from accidental wipe.

Publish with your eyes open

Access modes, policies, and reports - then a share link.

Go to dashboard