1. Scope and principle
This policy covers the Ayonix Zoomer service at zoomer.ayonix.com, its supporting
infrastructure and the engineering process that changes it. It applies to everyone who commits code
or holds production access.
The product processes biometric data. We therefore state limitations as plainly as controls: a security document that only lists strengths is not useful to the customer relying on it.
2. Access control
- Role-based access with three roles. Viewing an evidence image and exporting evidence in bulk are deliberately separate permissions, so an operator who triages alerts cannot bulk-export biometric material.
- Tenant isolation. Every business record carries an organisation identifier and every query filters on it. A session token presented against another tenant is rejected as an attack signal, not a mistake.
- Least privilege for production. Deployment credentials are held by named engineers; there are no shared logins.
- Administrator sessions are
HttpOnly,Secure,SameSite=Laxcookies expiring after 12 hours.
3. Data protection
| Asset | Control |
|---|---|
| Face templates | AES-256-GCM at rest. Original photographs are not stored. Templates never leave the server. |
| Evidence images | Disabled by default. When enabled: encrypted at rest, SHA-256 integrity hash, access only via HMAC-signed URLs valid for 60 seconds, every access audited, automatic deletion at end of retention. |
| OAuth tokens | AES-256-GCM at rest; deleted on disconnect. |
| Meeting video and audio | Never recorded. Frames analysed in memory and discarded. |
| Audit log | Append-only; excludes templates, object keys and tokens by construction. |
| Transport | TLS 1.2 minimum; TLS 1.0 and 1.1 are refused. HSTS with a one-year max-age. |
4. Application security controls
- Content-Security-Policy, HSTS,
X-Content-Type-Options,Referrer-PolicyandPermissions-Policyon every response. - Parameterised database access through an ORM query builder. No dynamic SQL identifiers anywhere in the codebase.
- Input validated at every API boundary with declarative schemas.
- Replay protection on mutating endpoints via
Idempotency-Key. - Constant-time comparison for tokens and signatures.
- Server-side re-derivation of every monitoring judgement: a tampered client cannot assert that a face matched.
5. Secure development
Every change is reviewed and must pass automated verification before it reaches production. The pipeline is described in the Secure Development Lifecycle policy and runs static analysis, dependency auditing, secret scanning, linting, type checking and the full test suite.
6. Logging and monitoring
- Structured application logs covering authentication, integration events, analysis ingestion and errors.
- An append-only audit log for administrator actions, evidence access and exports.
- Logs deliberately exclude biometric data, image keys and tokens.
7. Known limitations
Stated openly because a customer's risk assessment depends on it.
- No third-party penetration test has been performed to date. One is planned before general availability.
- No application-layer rate limiting. Replay is prevented by idempotency keys, but request volume is not bounded in the application. Edge rate limiting is the intended control.
- Password authentication is a bootstrap path only. The runtime caps PBKDF2 at 100,000 iterations, below current guidance. SSO with MFA is the intended production authentication route.
- Liveness detection is unevaluated against printed photographs, screen replay and masks.
- Detection thresholds ship as sample values and must be tuned on customer data before being relied upon.
8. Reporting a vulnerability
Email security@ayonix.com. We acknowledge within 3 business days. Please do not open a public issue, access other people's data, or run denial-of-service tests against production. Full terms: Vulnerability Management.