Namespace Isolation

Category: Architecture

Problem

In multi-tenant or multi-user applications, memories from different users or organizations must be completely isolated. User A must never see User B's memories, even through indirect recall. Additionally, different agents or services need controlled access boundaries.

Architecture

Dakera namespaces provide hard isolation boundaries. Each namespace has its own memory store, knowledge graph, and search index. Scoped API keys enforce access at the infrastructure level — a key scoped to namespace "tenant-a" physically cannot access "tenant-b" data.

Isolation Layers

Namespace — logical partition of all data (memories, entities, graphs)
Scoped API keys — keys restricted to specific namespace(s)
Rate limiting — per-key request limits prevent abuse
Encryption — AES-256-GCM at rest per namespace

Implementation

import { Dakera } from 'dakera';

// Admin client for namespace management
const admin = new Dakera({
  baseUrl: 'http://localhost:3300',
  apiKey: 'dk-admin-key'
});

// Create isolated namespaces for each tenant
// Each tenant's data is completely separate

// Tenant A's client — can only access tenant-a namespace
const tenantA = new Dakera({
  baseUrl: 'http://localhost:3300',
  apiKey: 'dk-tenant-a-key'  // scoped to "tenant-a" only
});

// Tenant B's client — can only access tenant-b namespace
const tenantB = new Dakera({
  baseUrl: 'http://localhost:3300',
  apiKey: 'dk-tenant-b-key'  // scoped to "tenant-b" only
});

// Tenant A stores a memory
await tenantA.memory.store({
  content: 'Internal roadmap: launching feature X in Q3',
  namespace: 'tenant-a',
  metadata: { type: 'confidential' }
});

// Tenant B cannot access Tenant A's data
const results = await tenantB.memory.recall({
  query: 'roadmap plans',
  namespace: 'tenant-a'  // This will be rejected — key not scoped for this namespace
});
// Error: 403 Forbidden — API key not authorized for namespace "tenant-a"

// Tenant B can only access their own namespace
await tenantB.memory.store({
  content: 'Our launch date is Q4',
  namespace: 'tenant-b',
  metadata: { type: 'planning' }
});

Namespace Management via REST

# List all namespaces
curl -X GET http://localhost:3300/v1/namespaces \
  -H "Authorization: Bearer dk-admin-key"

# Create a new namespace for a tenant
curl -X POST http://localhost:3300/v1/namespaces \
  -H "Authorization: Bearer dk-admin-key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "tenant-c",
    "description": "Isolated namespace for Tenant C"
  }'

# Create a scoped API key for the tenant
# (key can only access the specified namespace)

Common Namespace Architectures

Per-User Isolation

# Each user gets their own namespace
# namespace: "user-{user_id}"
# Key: scoped to that user's namespace only

Per-Tenant with Sub-Namespaces

# Organization level
# namespace: "org-acme"           (shared org knowledge)
# namespace: "org-acme-user-alice" (Alice's personal memories)
# namespace: "org-acme-user-bob"   (Bob's personal memories)
# Key for Alice: scoped to "org-acme" (read) + "org-acme-user-alice" (read/write)

Per-Agent Isolation

# In multi-agent systems
# namespace: "agent-researcher"   (private)
# namespace: "agent-writer"       (private)
# namespace: "shared"             (collaborative)

When to Use This Pattern

SaaS applications serving multiple customers from one Dakera instance
Multi-user applications with privacy requirements
Multi-agent systems requiring access control
Any application needing data isolation guarantees

Key Considerations

Namespace isolation is enforced at the storage level, not just the API — cross-namespace data leakage is architecturally impossible
Create scoped API keys with minimal access — principle of least privilege
Use a naming convention (e.g., "tenant-{id}", "user-{id}") for programmatic management
Rate limiting per API key prevents any single tenant from impacting others
Each namespace has independent decay configuration, knowledge graphs, and indexes