Security

This page describes design choices in the Lummet control plane. It is a description of how the software works, not a certification or an audit report.

Isolation between Lummet and each brand

The control plane never queries a brand's database. It reaches a brand only through that brand's own API, and every brand has its own database. Deleting a brand from the registry removes only the registry entry.

Signed requests

Each request from the control plane to a brand carries a timestamp, a random one-time value and an HMAC-SHA-256 signature. The signature covers the HTTP method, the path, the timestamp, the one-time value and a hash of the request body, so a request cannot be altered or replayed as a different one.

Credentials at rest

The shared secret for each brand is encrypted with AES-GCM before it is stored. The encryption key is held as a Worker secret and is never written to the database. A secret is shown to an administrator once, at the moment it is issued.

Staff accounts and sessions

• Passwords are hashed with PBKDF2 (SHA-256, 100,000 iterations, per-password salt) and compared in constant time.
• Sessions use an HttpOnly, Secure, SameSite=Strict cookie.
• Repeated failed sign-ins are rate limited.
• A disabled account loses its active sessions immediately.

Least privilege

A new staff account has no access to any brand and no permission on any resource. A super admin grants access per brand and per action. The server checks these grants on every request, not only when drawing the navigation.

Audit trail

Sign-ins, failed sign-ins, tenant switches and changes made through the control plane are recorded in an audit log, including changes proposed by the AI assistant. Passwords and secrets are never written to it. Entries are kept for 180 days.