Draft pending counsel review. This document describes our current security practices and is being reviewed by counsel for final publication.
1. Encryption
In transit
All connections to Brand Atlas (the application, the API, the documentation site, the marketing site) use TLS 1.2 or 1.3. HTTP requests are redirected to HTTPS. HSTS is enabled with a one-year max-age and includeSubDomains.
At rest
- Database content. Encrypted at rest using AES-256 (managed by Supabase / underlying cloud provider).
- File storage. Encrypted at rest using AES-256 (managed by Supabase / underlying cloud provider).
- API keys (Henry BYOK). Encrypted in Supabase Vault using authenticated symmetric encryption (libsodium). Decryption only in memory at the moment of use.
- Backups. Encrypted at rest with separate keys.
2. Authentication and access control
For customers
- Email and password sign-in with bcrypt-hashed passwords (cost factor 12 or higher).
- Two-factor authentication (TOTP authenticator apps, passkeys/WebAuthn, hardware security keys). SMS-based 2FA is not supported.
- Optional Single Sign-On (SAML, Guardian tier).
- Session timeout after 14 days of inactivity. Immediate session invalidation on password change.
- Brute-force protection: account lockout after several failed sign-in attempts.
For Brand Atlas personnel
- Mandatory two-factor authentication on all systems.
- Role-based access control with least-privilege defaults.
- Production-environment access via short-lived credentials issued through single sign-on with audit logging.
- Quarterly access reviews to detect and remove unnecessary access.
3. Infrastructure
Hosting
- Application and API hosted on Vercel’s edge infrastructure.
- Database, file storage, and Vault hosted on Supabase in the European Union region.
- CDN delivery through Vercel’s global edge network.
Network
- All inbound traffic terminates at TLS-capable proxies.
- The database is not directly reachable from the public internet; application servers connect through Supabase’s private connection.
- Outbound traffic to third-party services (AI providers, email, payment processing) is logged.
Isolation
- Each atlas’s data is logically isolated. Row-level security policies ensure queries are scoped to the requesting atlas.
- Backups are stored separately from active data.
- Test and staging environments use synthetic data; no production data flows into non-production environments.
4. Application security
- Code review on every change before merging to main.
- Static analysis and dependency scanning in CI.
- Regular dependency updates with attention to security advisories.
- CSP, X-Frame-Options, X-Content-Type-Options, and related security headers on all responses.
- Input validation and output encoding to prevent injection.
- Rate limiting on sensitive endpoints to defend against credential stuffing and abuse.
5. BYOK key handling
Customer-supplied AI provider API keys (Henry) are handled with additional care:
- Stored in Supabase Vault, encrypted at rest with libsodium.
- Decrypted only in memory at the moment of an AI API call.
- Never written to disk in plaintext.
- Never included in log lines.
- Scoped to the atlas; not usable by any other atlas.
- Deletable by the customer at any time.
The full description is on How your key is stored and in BYOK Policy.
6. AI feature security
The AI features (Oswald, Henry) are designed with explicit boundaries:
- Oswald drafts only; it cannot apply changes without brand-owner confirmation. The boundary is enforced at the system prompt, the tool set, and the application layer.
- Henry is read-only with no write tools. The boundary is enforced at the same three layers.
AI provider integrations use enterprise API tiers with no training on customer data. See AI Usage & Disclosure.
7. Monitoring and logging
- Application logs aggregated centrally with structured fields for traceability.
- Security-relevant events (sign-in, role changes, permission changes, Guest Pass creation and access) logged separately and retained longer.
- Automated alerts on anomalous patterns (failed sign-ins, unusual API usage, error spikes).
- 24/7 monitoring of critical paths.
8. Vulnerability management
- Regular automated scanning of infrastructure and dependencies.
- Annual penetration testing by an independent assessor.
- Public vulnerability disclosure policy with safe-harbour terms; see Vulnerability Disclosure.
security.txt published at brandatlas.pro/.well-known/security.txt per RFC 9116.
9. Incident response
When a security incident occurs, we follow a documented response process:
- Detect (through monitoring, customer reports, or third-party notification).
- Triage and assemble the response team.
- Contain the incident.
- Eradicate the cause.
- Recover affected systems.
- Notify customers within 72 hours where required by Breach Notification.
- Post-incident review and remediation.
10. Business continuity
- Daily encrypted backups with point-in-time recovery.
- Backups retained per the Data Retention & Deletion policy.
- Documented disaster recovery procedures tested at least annually.
- Recovery time and recovery point objectives reviewed regularly.
11. Personnel security
- Background checks where legally permissible.
- Confidentiality agreements with all personnel.
- Mandatory security training on joining and annually.
- Offboarding procedures including access revocation on the same day.
12. Certifications
Brand Atlas does not yet hold SOC 2 or ISO 27001 certification. Both are on the roadmap. Customers requiring a specific certification today should write to security@brandatlas.pro for the current status.
13. Reporting a vulnerability
Write to security@brandatlas.pro. We respond to security reports within one working day and welcome coordinated disclosure. See Vulnerability Disclosure.
What changed
- 27 May 2026: Initial publication.
