Security

How Aikebom is secured.

The short version: guests are anonymous by default, every tenant is isolated at the database layer, staff access is role-scoped, integrations fail closed, and deletion is automated and verified. The mechanisms, plainly, below — and what we store and for how long is on the Privacy page.

Anonymous by default

Guests never create accounts or passwords. A session is an anonymous, HMAC-signed, httpOnly cookie — there is no credential to phish and no password database to breach. Where a client opts into verified guest links, the claims ride inside a signed token (name and room at most), delivered individually and expiring with the stay.

Tenant isolation

Every event and property is a separate tenant. Row-level security is enabled deny-all on every database table, admin operations are hard-scoped to the tenant of the logged-in role, and a request that names a tenant that can’t be resolved fails closed rather than falling back to another tenant’s data. Nothing one client’s guests teach the concierge is ever used for another client.

Role-scoped staff access

Three staff roles, least-privilege by construction: platform admin, per-tenant organiser (locked to their own tenant), and a front-desk reception role that can see the request queue and mint guest links — and nothing else. Passwords are stored as scrypt hashes; admin and public endpoints are rate-limited.

Integrations fail closed

Inbound integrations (such as the PMS webhook) authenticate with per-tenant secrets verified before the payload is even parsed; rotating a secret revokes access instantly. Server-side fetches of client-supplied URLs are SSRF-guarded (https-only, private networks blocked, size and time capped). The per-tenant MCP endpoint is read-only, disabled by default, and token-gated when enabled — it serves official information, never guest data. Voice infrastructure is self-hosted and its webhook refuses unauthenticated calls.

Deletion that proves itself

Retention (the two models on the Privacy page) is enforced by an automated daily job in the engine itself — not a manual routine, and not a client-adjustable setting. A failed deletion run is recorded and surfaced in the admin as “data was NOT deleted” — it can never silently pass for a completed one.

Application & transport

TLS everywhere; strict security headers including a Content-Security-Policy; framework and dependencies kept current with automated vulnerability triage. Hosting runs on Vercel with the database on Supabase (managed Postgres); voice runs on our own dedicated server. AI providers are used via their APIs, which do not train on this data.

Certifications, honestly

We’re a young company and don’t yet hold formal certifications such as SOC 2 or ISO 27001. What we can do today: answer your security questionnaire directly, walk your IT team through the architecture on a call, and sign a data-processing agreement. Ask via hello@aikebom.com.

Reporting a vulnerability

Found something? Please email hello@aikebom.com with details and we’ll respond quickly. We ask for reasonable disclosure time and will credit researchers who report in good faith.

Changes

Last updated: 24 July 2026.