The user sees it before we ask
When fresh consent is needed, the user sees who’s asking, why, which checks will run, which service providers are disclosed, and how long artifacts can be kept.
For security, privacy & legal reviewers
Specific controls, not broad promises.
This page tells you what’s actually built: how consent gates a check, how biometric data stays inside your tenant, what leaves in a result, and when things get deleted. Where we don’t have something (a certification, an audit), we say so.
An overview, not the contract: the current platform legal documents govern each check. Last reviewed: July 27, 2026.
ConsentedChecktenant scoped
BeforePurpose disclosed
GateConsent current
ScopeTenant isolated
DataTemplates protected
ResultEvidence minimized
AfterDeletion scheduled
AdmissionValid consent required
IsolationTenant-scoped comparison
OutputCompact signed evidence
LifecycleDeletion on a schedule
Control map
A control at each boundary.
A check carries its privacy context with it, from the consent screen through the result to the deletion job, instead of treating consent, security, and retention as separate paperwork.
No consent, no check
A check refuses to start on a missing, expired, malformed, or superseded consent record. It doesn’t shrug and continue.
Comparison stays in your tenant
Biometric matching runs inside a validated, tenant-specific database boundary, and live database tests pin that isolation in place.
Templates are locked down
Stored biometric vectors get tenant-specific transforms, AES-GCM encryption, encrypted data keys, and versioned key material.
Results carry evidence, not media
Signed outputs hold compact evidence claims. Raw video and audio, embeddings, and internal vectors never leave.
Deletion actually runs
Every check gets a retention deadline up front. When it passes, deletion processes the eligible artifacts and records that it did.
Tenant isolation
The boundary is structural.
Isolation here isn’t a query filter we hope holds. Database sessions are pinned to a validated tenant-specific schema and reasserted after every commit, and comparison never leaves it. Stored vectors add tenant-specific transforms and versioned encryption on top.
Tenant A request
Tenant A schema
isolatedDatabase session pinned to this schema
Comparison uses only this tenant’s protected records.
No shared candidate pool
Tenant B request
Tenant B schema
isolatedDatabase session pinned to this schema
Comparison uses only this tenant’s protected records.
Result boundary
You get the evidence: never the footage.
Results carry compact, signed evidence your backend can validate: what happened, what was measured, what each part contributed. The session itself (video, audio, embeddings) stays behind.
Signed evidence result
policy-referencedInside the result
- Check lifecycle and timestamps
- Normalized measurements and contributions
- Policy and evidence references
- Tenant-safe coarse context
Outside the result
- Raw audio, video, or biometric vectors
- Face or voice embeddings
- Prior-comparison identifiers
- Recommendations about your action
Retention
Retention with a clock on it.
Every check gets its retention boundary the moment it’s admitted, capped by the consent the user saw. When the period ends, deletion runs and records that it ran.
Disclose
Before fresh consent, the user sees how long Sonavera-held artifacts can last. We present it honestly as the boundary for starting deletion, not a guaranteed completion time.
Stamp
The applicable consent and tenant policy are bound to the check the moment it starts.
Purge
After the period ends, eligible artifacts are deleted asynchronously. An active, unexpired session can briefly delay it, and encrypted database backups can retain copies for up to seven more days.
Record
A minimal consent-and-deletion record stays behind (proof of what happened), kept separate from what was deleted.
Integration controls
Trust your backend, not a redirect.
The integration shapes are familiar on purpose. Validation and policy stay on systems you control.
Bound to the app that asked
Authorization Code with S256 PKCE, required state, and required nonce tie the browser flow to the application that started it.
Your backend is the source of truth
Return parameters are advisory. The result comes from an authenticated backend call with your credentials, or it doesn’t count.
Callbacks you can verify
Every delivery is HMAC-signed, so your backend can check who’s calling before anything downstream moves.
The current legal documents govern.
The versioned Privacy & Biometric Notice, Biometric Consent Text, Retention and Destruction Policy, and Service Provider Disclosure live in one legal center. Browser prerequisites are on the Developers page.
Found a potential vulnerability? Emailsecurity@sonavera.ai or read ourresponsible disclosure policy.
Common review questions
Straight answers, including the awkward ones.
Does Sonavera make the final decision about a user?
No. We report what happened during the check and what was measured. Your organization validates the result and decides what it means for the action in front of it.
Does a completed check mean every measurement was strong?
No. Completion means the session finished: nothing more. The evidence inside can be strong, weak, partial, or missing, and the result says which. Those facts stay visible so your policy can deal with them honestly.
Does Sonavera establish government or legal identity?
No. We don’t do document KYC. A verification compares a live person with the enrollment your organization created for its own user reference. How that enrollment was bound to a real-world identity is yours to own.
What does the Evidence Index represent?
A 0–100 measure of the evidence gathered, composed under the versioned profile named inside the signed result. It isn’t a probability or a percentage, and it never comes with a Sonavera recommendation. The result also shows what was measured, what was missing, and what each part contributed.
Do we ever receive raw biometric data?
No. Results exclude raw audio and video, face and voice embeddings, internal matching vectors, prior-comparison identifiers, raw IP-derived identifiers, and raw browser or network fingerprints.
How are service providers disclosed?
The consent screen lists the platform’s disclosed material processors. That list is a policy disclosure, not a runtime log; it doesn’t mean every optional provider ran during a specific check. Current subprocessor details and their retention notes live in the platform legal center.
What certifications does this page claim?
None. And we won’t imply otherwise. This page describes implemented controls and current legal terms. It does not claim SOC 2 or ISO 27001 certification, HIPAA or GDPR compliance, a completed audit, or independent penetration testing. Ask us where we are on any of these and you’ll get a straight answer.
Is this page the governing privacy or biometric notice?
No. This is the readable overview. The versioned Privacy & Biometric Notice, Biometric Consent Text, Retention and Destruction Policy, and Service Provider Disclosure in the platform legal center are what govern.
Bring us your security questionnaire.
Every question gets mapped to an implemented control, a legal term, or an honest “not yet.”