teamly← Back to home

Security

Last updated: 27 July 2026

Teamly is designed so that the most sensitive thing it holds — the AI provider keys you connect — is protected by default, and so that each account's data is isolated from every other account. This page describes how, and how to report a vulnerability.

Provider keys are encrypted at rest

Every provider key you add is encrypted with AES-256-GCMbefore it is written to the database, using a master key that lives only in your deployment's environment. Keys are decrypted in memory only for the moment a scan needs them, are never written to logs, and are never returned to the browser in plain text — the app shows only a masked form such as sk-…a1b2. Rotating a key re-encrypts it; deleting one removes it and disables any models that depended on it.

Data isolation

Teamly's data model is scoped per brand, and Postgres Row-Level Security enforces the chain brand → account → userat the database layer, so one account cannot read another's prompts, responses, competitors, or metrics. Every request is additionally checked at the API layer against the authenticated account and the active brand.

Authentication & sessions

Authentication is handled by Supabase Auth (email/password and Google OAuth). The web app keeps its session in an httpOnly cookie so it is not readable by client-side JavaScript, and the backend verifies the user's token on every protected request. Internal calls between the web app and the API are additionally gated by a shared secret compared in constant time.

Transport & hardening

  • Security headers are set on API responses via Helmet.
  • CORS is restricted to a configured allow-list of origins rather than a wildcard.
  • Authentication endpoints are rate-limited to slow brute-force and enumeration attempts.
  • Request bodies are size-limited and validated.
  • Run Teamly behind HTTPS in production so tokens and data are encrypted in transit.

Self-hosting responsibilities

When you self-host, you control the infrastructure and the encryption key. Keep your CREDENTIALS_ENCRYPTION_KEY secret and stable — losing it makes stored provider keys unrecoverable, and exposing it undermines their encryption. Keep dependencies and your database patched, and restrict who can access the deployment.

Reporting a vulnerability

If you believe you have found a security issue, please email us with the details and steps to reproduce. Please give us a reasonable chance to investigate and release a fix before any public disclosure. We are grateful for responsible reports and will acknowledge your contribution.