Sentinel — Face Identification
On-Demand Vision, No Background Processing
Sentinel can identify visitors at your door against your household's reference photos. The pipeline runs only when a person, voice call, workflow, or rule explicitly asks — never as a background daemon. No surprise face matching while you're away.
Reference photos
SourceAddress-book Contact records (single source of truth — no separate face DB)
StoragePer-user / per-company on disk; never leave your account
Sent to OpenAIdetail: low (85 tokens flat)
Embeddings stored?No. Vision API is stateless on our side
Delete contactRemoves them from vision matching too
Probe images (camera frames)
WyzeCloudFront-signed thumbnail (~1h TTL); downloaded on-demand
Home Assistant/api/camera_proxy/<entity> via your local HA
Stored on server?No — bytes are sent to vision and discarded
TriggerChat / voice / workflow / Sentinel automation rule
Default poll intervalnone (off-by-default)
OpenAI biometric policy: our prompt is engineered to comply — we ask the model to compare a snapshot to the homeowner's own labeled household photos and return a name from the supplied list, never to "identify" a stranger from a public database. If a future model rejects the prompt, the dispatcher falls back to "Snapshot captured." with no false match.
Wyze account password: Wyze publishes no public OAuth, so the cloud-direct path holds your account password encrypted at rest with AES-256-GCM (per-user key) and uses it only against Wyze's auth host. Never logged. For users who want stricter isolation, the older Mac-mini-routed path keeps the password in macOS Keychain.
Kitchen Mini Public Surface
No-PII Web Pages — Opaque Token Auth
Households can share the week's menu, manage email opt-ins, and vote on Friday eat-out plans without an account. Engineered so the URL and rendered HTML never reveal who the family is.
Token Model
Format12 chars · base32 minus 0/O/1/l/I
Sourcecrypto.randomBytes(8)
Keyspace≈ 1.4×10¹⁵
Kindsmenu_week · preferences · eatout
LifecycleIssued on plan generation; revocable
Per-member tokensLazy on first newsletter
Privacy Guarantees
URLOpaque token only — no family or member id derivable
HTMLNo family / member name, role, age, dietary, contact
HeaderHardcoded "Your week's menu" / "Kitchen Mini"
PhotosToken-scoped — must be a dish in the bound plan
Searchnoindex meta + X-Robots-Tag + robots.txt Disallow
TestedSnapshot test fails on any forbidden substring
One-click invalidation: The Kitchen home page exposes a "Regenerate" action that revokes the current week's token. Anyone with the prior URL gets a 404 on the next request. Old non-current-week tokens stay live as read-only snapshots; they're pruned 90 days after revocation.
Distinction from website builder: The Dev Mini website builder is for marketing pages where the user wants identity in the URL (subdomain, indexable). Kitchen menu pages are for sharing live application state where privacy matters (apex, opaque token, noindex). Different problems, different security postures.
Roadmap
Path to 10/10
Three items remain before achieving a perfect security score.
Gallery & Reports stores still use PerUserStore with filter-only isolation. Should migrate to PerCompanyStore for full directory-level isolation.
callRelay admin tools lack companyId scoping on workflow and contact operations. Could allow cross-company data access.
gmailPoller missing null companyId guard on trigger polling. Edge case where triggers without a company context may fire incorrectly.