Memory Permissions

Category: Security

Problem

Multi-user and multi-tenant systems need access control on memories. Without isolation, one user's private conversations could leak into another user's context. In team environments, some memories should be shared (team knowledge) while others remain private (personal preferences). A flat memory store with no permissions is a security liability.

Architecture

This pattern uses Dakera's namespace isolation combined with scoped API keys to enforce access boundaries. Each user gets a private namespace, teams get shared namespaces, and admin keys can query across namespaces for analytics or moderation. The namespace boundary is enforced server-side — no client-side trust required.

Flow

• Create a namespace per user for private memories
• Create shared namespaces for team or org-level knowledge
• Issue scoped API keys that restrict access to specific namespaces
• Admin keys can query across namespaces for moderation

Implementation

from dakera import Dakera

# Admin client with full access
admin_client = Dakera(base_url="http://localhost:3300", api_key="dk-admin-...")

# Create user-specific namespace
admin_client.namespace.create(name="user-alice", description="Alice's private memories")
admin_client.namespace.create(name="user-bob", description="Bob's private memories")
admin_client.namespace.create(name="team-engineering", description="Shared engineering knowledge")

# Create scoped keys for each user
alice_key = admin_client.namespace.key_create(
    namespace="user-alice",
    description="Alice's scoped key",
    permissions=["store", "recall"]
)

# Alice's client can only access her namespace
alice_client = Dakera(base_url="http://localhost:3300", api_key=alice_key["key"])

# Alice stores private memory — isolated from Bob
alice_client.memory.store(
    content="My AWS account ID is 123456789012",
    namespace="user-alice",
    metadata={"type": "private", "importance": 0.9}
)

# Alice cannot access Bob's namespace (server-side enforcement)
# This would raise a 403 Forbidden error:
# alice_client.memory.recall(query="account", namespace="user-bob")

# Team-shared memory with broader access
team_key = admin_client.namespace.key_create(
    namespace="team-engineering",
    description="Engineering team shared key",
    permissions=["store", "recall"]
)
team_client = Dakera(base_url="http://localhost:3300", api_key=team_key["key"])

team_client.memory.store(
    content="Production database is on port 5432, read replica on 5433",
    namespace="team-engineering",
    metadata={"type": "infrastructure", "importance": 0.8}
)

# Admin cross-namespace query for moderation
def admin_search_all(query: str) -> list:
    """Admin can search across all namespaces for compliance."""
    namespaces = ["user-alice", "user-bob", "team-engineering"]
    all_results = []
    for ns in namespaces:
        results = admin_client.memory.recall(query=query, namespace=ns, top_k=5)
        all_results.extend(results["results"])
    return all_results

When to Use This Pattern

• Multi-tenant SaaS applications with user isolation requirements
• Team collaboration tools where knowledge has different access levels
• Healthcare or legal agents handling sensitive personal data
• Any system requiring GDPR-compliant data separation

Key Considerations

• Always enforce permissions server-side via scoped API keys, never client-side
• Design namespace hierarchy upfront: user/team/org levels
• Consider read-only keys for agents that should recall but not store
• Implement key rotation policies for production deployments