---
title: Security
description: How Niyra stores keys, encrypts data, isolates user accounts, and handles third-party tokens. The practical security posture, not marketing copy.
url: /docs/security
lastUpdated: 2026-06-10
---

# Security


## Account isolation

Every user is a row in `users` with a UUID. All other tables (conversations, memories, records, integrations, tokens) reference that UUID. Cross-account queries are not architecturally possible — every read passes through a repository that filters by `user_id`.

## Key storage

- **LLM provider keys (BYOK)**: AES-256-GCM encrypted at rest, key material in `JSONB` column. The encryption key itself lives in environment config and never touches the database.
- **OAuth tokens (Gmail, Slack, etc.)**: same envelope encryption. Tokens auto-refresh 60s before expiry; refresh failures don't surface real tokens to logs.
- **Niyra API keys** (for the public OAuth provider surface): signed JWT with rotating RSA key.

## Transport

TLS 1.2+ everywhere. HSTS enabled on `niyra.ai` and `api.niyra.ai`. No plaintext fallback.

## Third-party data

When you connect Gmail, your token lets us call Gmail on your behalf. We don't bulk-download your inbox; we call the API only when actively answering you. Cached data is per-conversation and clears with the conversation.

## Audit

Every privileged action — token use, browser session, outbound call, integration write — is logged with timestamp, actor (you), and target. Review from the Activity panel in the dashboard.

## What we don't do

- We do not sell your data.
- We do not train models on your conversations.
- We do not share data with other Niyra users.
- We do not store provider passwords (OAuth only).

## Disclosure

Security issues: email **security@niyra.ai**. PGP key at `/.well-known/security.txt`. We respond within 48 hours and credit researchers in the changelog.