Multi-Tenant Isolation Architecture

Overview

This guide describes how to implement cryptographic tenant isolation using Locktera containers.

Multi-tenant systems must ensure that each tenant’s data is accessible only to authorized identities within that tenant. Traditional approaches rely on application logic, database filtering, or storage-level permissions. These mechanisms cannot reliably prevent cross-tenant access if infrastructure, storage systems, or application layers are compromised.

Locktera enforces tenant isolation cryptographically.

Each tenant’s data is encrypted into independent, immutable containers with separate access policies. Containers can only be decrypted by explicitly authorized identities. Unauthorized tenants, systems, or applications cannot decrypt protected data—even if they obtain a copy.

This ensures complete tenant isolation regardless of infrastructure, storage location, or system compromise.

Isolation Guarantee

Locktera provides cryptographic isolation between tenants.

This ensures:

• Tenant data cannot be decrypted by unauthorized tenants

• Cross-tenant access is cryptographically prevented

• Isolation does not rely on application logic or infrastructure trust

• Storage systems cannot access tenant plaintext data

• Tenant isolation persists after transfer, backup, or copying

Isolation enforcement occurs at container decryption.

Architecture Overview

Traditional multi-tenant architecture:

Tenant A → Application → Shared Database → Storage
Tenant B → Application → Shared Database → Storage

Isolation depends on:

• Application logic

• Database filtering

• Storage permissions

If infrastructure is compromised, tenant data may be exposed.

Locktera multi-tenant architecture:

Tenant A Data
  │
  ▼
Encrypted Container (.tera) — Tenant A
  │
  ▼
Shared Storage Infrastructure
  │
  ├── Authorized Tenant A identity → Decrypt permitted
  │
  └── Tenant B identity → Decrypt denied

Isolation is enforced cryptographically.

Infrastructure does not determine access.

Architecture Components

Tenant Containers

Each tenant’s data is encrypted into separate containers.

Containers:

• Are immutable

• Enforce access policies independently

• Cannot be decrypted without authorization

• Remain protected after transfer or storage

Each container represents an isolated cryptographic security boundary.

Tenant Identity

Each tenant identity represents an authorized user, service, or system.

Examples:

• Tenant user accounts

• Tenant application services

• Tenant AI systems

• Tenant API identities

Access policies bind container access to tenant identities.

Access Policy Enforcement

Container access policies define which tenant identities may decrypt containers.

Policies can:

• Grant access to authorized tenant identities

• Revoke access instantly

• Restrict access to specific systems or services

• Enforce time-limited access

Policies are enforced cryptographically at decryption.

Shared Infrastructure

Containers may be stored in shared infrastructure, including:

• Cloud object storage

• Shared databases

• Data lakes

• Backup systems

• Multi-tenant SaaS platforms

Storage systems cannot decrypt container contents.

Infrastructure compromise does not expose tenant data.

Audit Logging

All container access attempts are recorded.

Audit logs include:

• Identity requesting access

• Tenant context

• Authorization result

• Timestamp

• Operation performed

Audit logs enable compliance, forensic analysis, and tenant access verification.

Implementation Workflow

Step 1 — Encrypt Tenant Data

Encrypt tenant data into a dedicated container.

manifest.json

{
  "container": {
    "drm": {
      "dynamic": true
    }
  }
}

Request:

curl -X POST $BASE_URL/users/USER_ID/containers/encode \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "manifest.json=@manifest.json;type=application/json" \
  -F "name=Tenant A Container" \
  -F "file=@tenant_a_data.pdf"

Response:

{
  "org_id": "YOUR_USER_ID",
  "container": {
    "uuid": "123e4567-e89b-12d3-a456-426614174000",
    "name": "Tenant A Container"
    "created_at": "2026-02-21T18:35:17Z"
  }
}

Tenant A data is now cryptographically isolated.

Step 2 — Grant Access to Authorized Tenant Identities

Grant access only to authorized tenant identities.

curl -X PATCH $BASE_URL/users/USER_ID/containers/CONTAINER_ID/drm \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "recipients": [
          "tenant-a-user@company.com"
        ]
     }'

Only authorized tenant identities may decrypt the container.

Step 3 — Authorized Tenant Access

Authorized tenant identity retrieves container:

curl -X GET $BASE_URL/users/USER_ID/containers/CONTAINER_ID/decode \
  -H "Authorization: Bearer TENANT_A_API_KEY"

Response:

{
  "files": [
    {
      "name": "tenant_a_data.pdf"
    }
  ]
}

Access is permitted.

Step 4 — Unauthorized Tenant Access Attempt

Unauthorized tenant attempts access:

curl -X GET $BASE_URL/users/USER_ID/containers/CONTAINER_ID/decode \
  -H "Authorization: Bearer TENANT_B_API_KEY"

Response:

{
  "error": "access_denied",
  "message": "Decryption is not permitted for this container."
}

Access is denied cryptographically.

Step 5 — Audit Tenant Access

Retrieve audit logs:

curl -X GET $BASE_URL/users/USER_ID/containers/CONTAINER_ID/events \
  -H "Authorization: Bearer YOUR_API_KEY"

Audit logs provide verifiable tenant access history.

Security Properties

This architecture ensures:

• Complete cryptographic isolation between tenants

• Cross-tenant access is cryptographically prevented

• Isolation does not rely on application logic or storage security

• Infrastructure compromise does not expose tenant data

• Access policies are independently enforced per tenant

• Access may be revoked instantly

• Containers remain immutable

• All access attempts are audit logged

Ideal Use Cases

This architecture is ideal for:

• Multi-tenant SaaS platforms

• Enterprise AI copilots serving multiple organizations

• Healthcare platforms handling patient data per tenant

• Secure enterprise document management systems

• Developer platforms hosting customer data

• Multi-tenant analytics platforms

Comparison to Traditional Multi-Tenant Isolation

Traditional isolation:

• Depends on application logic

• Depends on database filtering

• Depends on infrastructure security

• Cannot protect copied data

Locktera isolation:

• Enforced cryptographically

• Independent of infrastructure

• Protects copied containers

• Provides verifiable isolation

Summary

Locktera enables cryptographic tenant isolation by encrypting each tenant’s data into independent containers with separate access policies. Only authorized tenant identities can decrypt tenant containers. Unauthorized tenants, systems, or applications cannot access protected data regardless of storage location or infrastructure compromise.

This enables secure multi-tenant SaaS, AI, and enterprise platforms with verifiable isolation and infrastructure-independent security.