Security secrets

Configure SECURITY_SECRET and optional INTEGRATIONS_TOKEN_ENCRYPTION_KEY for invite links, OAuth hashing, and channel token encryption.

2 min read

Connect your agent today

Draft from chat, review in your calendar, and publish only what you approve.

Start for $0

What to set

Set SECURITY_SECRET in your backend environment.

It is used for:

Invite links: signing organization invite tokens.
OAuth2: hashing OAuth client secrets, authorization codes, and access tokens (raw secrets are never stored).
Channel tokens (fallback): AES-GCM encryption of integrations.token / refresh_token when INTEGRATIONS_TOKEN_ENCRYPTION_KEY is unset.

Optionally set a dedicated INTEGRATIONS_TOKEN_ENCRYPTION_KEY so rotating invite/OAuth hashing does not re-key every connected channel. Prefer a separate value in production.

How to generate

Generate a random secret and store it in your backend env file.

openssl rand -hex 32

Where to set it

Local dev: backend/.env.development
Production: your deployment secret manager / env (e.g. backend/.env.production.local if you use it)
Self-host: infra/self-host/.env (see the example template)

Migrating existing plaintext channel tokens

New connects encrypt automatically when a key is configured. To rewrite legacy plaintext rows:

pnpm --filter ./backend exec tsx scripts/migrate_encrypt_integration_tokens.ts

Rotation warning

Changing SECURITY_SECRET will invalidate:

outstanding invite links
existing OAuth client secrets (apps must be updated/re-rotated)
existing OAuth access tokens (clients must re-authorize)

If you relied on SECURITY_SECRET as the channel-token encryption key (no dedicated INTEGRATIONS_TOKEN_ENCRYPTION_KEY), rotating it also prevents decrypting existing ciphertext — set a dedicated integrations key before rotating, or re-connect channels after migrating with the new key.