Reference

Security

How Seren protects your data, credentials, and integration access across every layer of the stack.

Authentication

Seren uses Supabase Auth for all user authentication. Users sign in via magic link a one-time URL sent to their email that expires after a single use. There are no passwords stored anywhere in Seren's database, which eliminates the entire class of password-related vulnerabilities including brute force, credential stuffing, and password database leaks.

Sessions are managed via short-lived JWTs issued by Supabase. These tokens expire automatically and are refreshed transparently via the middleware layer on every request. If a token is stolen, it becomes useless within minutes.

No passwords, ever.

Magic link authentication means there is no password to steal, guess, or brute force. Your email address is the only credential Seren ever asks for.

Row Level Security

Every user's data in the Postgres database is protected by Row Level Security policies enforced at the database layer, not just at the application layer. This means even if there is a bug in the application code that constructs a bad query, the database itself refuses to return data belonging to another user.

-- RLS policy on memories table
CREATE POLICY "users can only access own memories"
ON memories
FOR ALL
USING (auth.uid() = user_id);

This policy is enforced by Supabase on every single query, regardless of where it originates. The following tables all have RLS enabled:

memories · contradictions · integration_connections · investigations

OAuth token storage

When users connect their tools GitHub, Sentry, PagerDuty, Seren never stores their platform passwords or OAuth app secrets. The OAuth flow exchanges a one-time code for a scoped access token. Only that token is stored, never the credentials used to obtain it.

Token exchange flow

User approves access on GitHub/Sentry/PagerDuty
        ↓
Platform issues a scoped access token
        ↓
Seren stores only that token - not credentials
        ↓
Token is scoped · expires · user-revocable

Seren uses a server-owned OAuth model. Your CLIENT_ID and CLIENT_SECRETlive only in Seren's server environment variables never in the database, never sent to the browser, never logged.

Your credentials never touch Seren's database.

GitHub passwords, Sentry account credentials, PagerDuty logins none of these ever reach Seren's servers. Only the scoped access token issued after you approve is stored, and only for your account.

Data isolation

Every piece of data in Seren is scoped to a user ID. There is no shared data between users. One user's incidents, memories, and integration tokens are completely invisible to another user at the database level enforced by RLS, not just application logic.

Integration scopes

Seren requests the minimum permissions needed from each platform. All external integrations are read-only by design Seren observes and investigates, it never mutates your external systems.

GitHub

repo · read:org

Cannot: write code, create PRs, delete repos

Sentry

org:read · project:read · event:read

Cannot: delete issues, modify settings

PagerDuty

incidents.read · services.read · users.read

Cannot: acknowledge, resolve, or create incidents

Transport security

All communication between the browser and Seren's servers happens over HTTPS. All communication between Seren's backend and external APIs GitHub, Sentry, PagerDuty, Qdrant, Neo4j happens over TLS. There is no plaintext data transmission anywhere in the system.

Memory layer

Seren's memory system stores context about past investigations to improve future ones. This data is scoped to your user ID exclusively, protected by RLS, stored in your own Supabase instance, never used to train models, and never shared with other users.

When you disconnect a tool or delete your account, access tokens are deleted immediately from the database. Seren loses the ability to query that platform instantly. You can also revoke access directly on GitHub, Sentry, or PagerDuty for complete certainty.

Summary

Threat	How Seren addresses it
Password theft	No passwords stored - magic link only
Cross-user data access	Row Level Security enforced at DB layer
OAuth credential exposure	Server env only, never in DB or browser
Stolen session token	Short-lived JWTs with automatic refresh
Scope creep on integrations	Minimum read-only scopes requested
Plaintext data transmission	HTTPS and TLS everywhere
Memory data leakage	User-scoped with RLS protection

See the quickstart for deployment setup and the memory layer for more on retention and isolation.