Invitation-only access
An account and permission to enter the closed alpha are separate. Being authenticated alone does not grant alpha access.
Security & trust
Trust is a product behaviour, not a badge.
Sarlo is still in closed alpha, so this page deliberately separates what the product already enforces from what still has to be proven before wider access. No certification or security guarantee is being claimed here.
Protected account recovery
Invite and recovery links use a deliberate confirmation boundary before a one-time token is consumed, reducing accidental activation by automated email scanners.
Private routes stay private
The public site is separated from the authenticated product. Login, recovery, auth and private-app routes are excluded from search indexing.
Uncertainty is part of safety
Sarlo is designed to surface material ambiguity for confirmation rather than silently turning uncertain AI output into confirmed user reality.
Do not give Sarlo secrets
Some information should never become normal memory.
Do not submit passwords, PINs, card security codes, one-time access codes, private encryption keys or similar credentials. Sarlo is not a password manager or credential vault.
Sensitive-data handling is being tested as a product boundary. The safest design is often to refuse or avoid storing a category rather than claim that every type of secret belongs inside the product.
Already enforced
- • invitation-only closed-alpha authorisation;
- • server-side checks on protected pages and APIs;
- • one-time email-action hardening and no-index/no-store boundaries on sensitive auth routes;
- • public/private route separation; and
- • explicit history/correction requirements in the product design.
Still to prove before wider testing
- • production usage and runaway-cost enforcement;
- • hostile/failure testing across model and database boundaries;
- • production backup and recovery proof; and
- • the complete Gate 2 rota behaviour under real tester inputs.
Responsible reporting
Found something that could put a user at risk?
Send enough detail to reproduce the issue, but do not include another person's private information or real credentials unless it is strictly necessary and safe to do so.