Skip to content
← All docs

Security

How Niyra stores keys, encrypts data, isolates user accounts, and handles third-party tokens. The practical security posture, not marketing copy.

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.

FAQ

Do you train models on my conversations?
No. Your conversations never leave the Niyra system for training. They go to LLM providers (Anthropic, OpenAI) only as inference input under contracts that prohibit training on customer data.
What happens to BYOK keys when I revoke?
The encrypted blob in the users table is overwritten with zeroes, the in-memory cache is invalidated immediately, and audit logs record the revocation. We can't recover the key after that.
Where is data stored?
Supabase Postgres for structured data (Mumbai region). pgvector for embeddings. Object storage for attachments. All at rest with provider-managed encryption + our app-layer AES-256 on sensitive fields.
For AI:.md.txt