Security — Trix Docs

Overview

Trix is designed with security as a core principle. This page covers our security architecture, data handling practices, and recommendations for securing your integration.

Encryption at Rest - All data encrypted with AES-256
Encryption in Transit - TLS 1.3 for all API communication
Access Control - API key and space-based isolation
Audit Logging - Comprehensive activity logs

Authentication

API Keys

API keys are the primary authentication method for Trix. Each key is scoped to a single account and can have granular permissions.

Permission	Description
`memories:read`	Read and search memories
`memories:write`	Create, update, and delete memories
`spaces:read`	List and read spaces
`spaces:write`	Create and manage spaces
`webhooks:manage`	Configure webhook endpoints
`integrations:manage`	Connect and manage integrations

Key Best Practices

Create separate keys for different applications or environments
Use the minimum required permissions for each key
Rotate keys regularly (at least every 90 days)
Never commit API keys to version control
Use environment variables or a secrets manager

api-key-usage.sh

# Good: Use environment variables
export TRIX_API_KEY="gdb_..."
curl -H "Authorization: Bearer $TRIX_API_KEY" https://api.trixdb.com/v1/memories

# Bad: Hardcoded key in code
# curl -H "Authorization: Bearer gdb_abc123..." ...

If you suspect an API key has been compromised, revoke it immediately in your dashboard and create a new one.

Data Encryption

At Rest

Data is protected at rest through multiple layers:

OAuth tokens for integrations are encrypted with AES-256-GCM using account-specific keys
Database storage uses infrastructure-level encryption
Sensitive credentials are encrypted at the application level

In Transit

All API communication is secured with TLS encryption.

Integration Token Security

OAuth tokens for third-party integrations (Notion, Google) are encrypted with account-specific derived keys using AES-256-GCM. Each account has its own encryption key, ensuring complete isolation between accounts.

Access Control

Account Isolation

Each Trix account is completely isolated. API keys can only access resources within their own account.

Space-Based Access

Spaces provide additional isolation within an account. Memories in one space are not accessible from another unless explicitly shared.

space-isolation.sh

# Create isolated spaces for different use cases
curl -X POST https://api.trixdb.com/v1/spaces \
  -H "Authorization: Bearer $TRIX_API_KEY" \
  -d '{"name": "Production Data", "description": "Production user memories"}'

curl -X POST https://api.trixdb.com/v1/spaces \
  -H "Authorization: Bearer $TRIX_API_KEY" \
  -d '{"name": "Test Data", "description": "Development and testing"}'

Multi-Tenancy

For applications serving multiple users, use spaces or metadata to isolate user data:

// Option 1: One space per user
const userSpace = await trix.spaces.create({
  name: `user_${userId}`,
  metadata: { user_id: userId }
});

// Option 2: Metadata-based isolation
await trix.memories.create({
  content: "User's memory content",
  metadata: { user_id: userId },
  space_id: sharedSpaceId
});

// Always filter by user_id when searching
const results = await trix.search({
  query: "search term",
  metadata_filter: { user_id: userId }
});

Webhook Security

Signature Verification

All webhook payloads are signed with HMAC-SHA256. Always verify signatures before processing webhook events.

import crypto from 'crypto';
import express from 'express';

function verifyWebhookSignature(payload: string, signature: string, secret: string): boolean {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(`sha256=${expected}`)
  );
}

app.post('/webhook', (req, res) => {
  const signature = req.headers['x-trix-signature'] as string;
  const isValid = verifyWebhookSignature(
    JSON.stringify(req.body),
    signature,
    process.env.WEBHOOK_SECRET!
  );

  if (!isValid) {
    return res.status(401).send('Invalid signature');
  }
});

Replay Prevention

Webhook payloads include a timestamp. Reject events older than 5 minutes to prevent replay attacks:

const MAX_AGE_MS = 5 * 60 * 1000; // 5 minutes

function isReplayAttack(timestamp: string): boolean {
  const eventTime = new Date(timestamp).getTime();
  const now = Date.now();
  return Math.abs(now - eventTime) > MAX_AGE_MS;
}

Network Security

IP Allowlisting

Enterprise accounts can restrict API access to specific IP addresses or CIDR ranges. Configure this in your account settings.

Rate Limiting

Rate limits protect against brute-force attacks and abuse. See the Rate Limits documentation for details.

Trix IP Ranges

If you need to allowlist Trix IPs for webhook delivery, contact support for the current list of IP ranges.

Audit Logging

Trix maintains audit logs for security-relevant events including billing changes and permission updates. Audit logs are available through the dashboard.

Compliance

Data Residency

Data is stored in US data centers by default. Contact us to discuss data residency requirements for your organization.

SOC 2

Trix is pursuing SOC 2 Type II certification. Contact us for details on our current security posture and audit timeline.

GDPR

Trix supports GDPR compliance with:

Right to erasure (delete all user data via API)
Data portability (export all memories)
Data processing agreements available
EU data residency option

HIPAA

HIPAA-compliant deployments are planned for enterprise healthcare customers. Contact sales to discuss requirements and timeline.

Vulnerability Reporting

If you discover a security vulnerability, please report it responsibly:

Email: [email protected]
We aim to respond within 24 hours

Please do not publicly disclose vulnerabilities until we've had a chance to investigate and release a fix.

Security Checklist

Use this checklist to ensure your Trix integration is secure: