Skip to main content
Memory is sensitive data. Velixar treats security as a core product feature, not an afterthought.

Defense in Depth

Velixar uses a 6-layer security model — every request passes through multiple independent validation gates before touching any data.
Request


┌─────────────────────────────────┐
│ Layer 1: Gateway Authentication │  JWT or API key validation
├─────────────────────────────────┤
│ Layer 2: Rate Limiting          │  Per-user, tier-aware throttling
├─────────────────────────────────┤
│ Layer 3: Membership Validation  │  Org/team membership verified
├─────────────────────────────────┤
│ Layer 4: Role-Based Access      │  Action scoped to user's role
├─────────────────────────────────┤
│ Layer 5: Row-Level Security     │  Database enforces data isolation
├─────────────────────────────────┤
│ Layer 6: Resource Verification  │  Target resource existence check
└─────────────────────────────────┘
A request that fails at any layer is rejected immediately — no partial access, no fallthrough.

Authentication

Velixar supports two authentication methods depending on the endpoint:
MethodUsed byFormat
API KeyPersonal memory API (/memory/*)Authorization: Bearer vlx_...
JWTOrg memory API, dashboardAuthorization: Bearer <supabase_jwt>
API keys are scoped to a single user and can be rotated from the dashboard. JWTs are short-lived and validated against the identity provider on every request.

Rate Limiting

Every API key and user is subject to tier-aware rate limits:
PlanMemories / monthRetrievals / month
Free100500
Pro10,000250,000
Power250,0001,000,000
Team5,000 / seat100,000 / seat
Rate limits are tracked in a persistent cache. If the cache is temporarily unavailable, the system falls back to per-instance tracking rather than disabling limits — rate limiting never fails open. Exceeding your limit returns 429 Too Many Requests with a Retry-After header.

Data Isolation

Personal Memories

Each user’s memories are isolated by user_id at both the API and database layers. There is no API surface to access another user’s personal memories.

Org Memories

Org data is isolated at multiple levels:
  • Database: Row-Level Security (RLS) policies enforce that queries only return data within the user’s organization
  • Vector Store: Each team and organization has its own vector collection — there is no shared index
  • API: Membership is verified on every request before any data is returned
Even if a valid JWT is presented, the user must have an active membership record to access any org data. Removing a user from the org immediately revokes access.

Audit Logging

All org memory operations are recorded in an immutable audit log:
  • Memory commits — who committed what, to which scope
  • Memory deletions — who deleted what, with content preview
  • Promotions — who approved or rejected, with before/after scope
  • Member changes — invites and removals with role metadata
Audit entries include the actor, timestamp, target resource, and contextual metadata. The audit log is append-only — entries cannot be modified or deleted by any user, including admins.
Audit log access is restricted to managers and admins. Regular members cannot view the audit trail.

System-to-System Security

Internal system operations (like the embedding pipeline) use dedicated shared secrets stored in a managed secrets service. These endpoints:
  • Are not exposed to end users
  • Validate a secret header on every invocation
  • Verify the target resource exists before performing any operation
  • Cannot be called with user-facing credentials

Observability

Velixar provides security observability through multiple channels:
SignalWhat it covers
Audit LogAll org memory mutations with actor attribution
Access TrackingPer-memory access count and last-accessed timestamp
Rate Limit MetricsPer-user consumption against plan limits
API Usage DashboardReal-time view of memory and retrieval usage by tier
Error MonitoringApplication-level error tracking with session replay
Web AnalyticsDashboard and docs usage patterns
The API Usage page in the dashboard shows your current consumption against plan limits in real time, with breakdowns by operation type.

Credential Management

  • API keys and secrets are stored in a managed secrets service with encryption at rest
  • No credentials are hardcoded in application code
  • Database credentials use service-role keys that are never exposed to the client
  • JWT signing keys are managed by the identity provider

Infrastructure Security

  • All traffic is encrypted in transit (TLS)
  • The API runs on serverless compute with no persistent attack surface
  • Static assets are served through a CDN with edge caching
  • Database connections use SSL with certificate verification
  • Vector store connections are authenticated with API keys over HTTPS

Reporting Vulnerabilities

If you discover a security issue, please email security@velixarai.com. We take all reports seriously and will respond within 48 hours.