DEV Community

Cover image for Chapter 74 — Secure AI Multi-Tenancy & Tenant Isolation
Black Shadow Team ©
Black Shadow Team ©

Posted on

Chapter 74 — Secure AI Multi-Tenancy & Tenant Isolation

#ai

Chapter 74 — Secure AI Multi-Tenancy & Tenant Isolation: Tenant Boundaries, Data Isolation, Database Row-Level Security, Object Storage Isolation, Vector/RAG Isolation, Cache Isolation, Network Segmentation, Cross-Tenant Attack Prevention & Verification.

74.1 Introduction

Multi-tenancy allows one AI platform to serve many independent users, organizations, teams, or customers while sharing application infrastructure.

This architecture creates a fundamental security requirement:

A tenant must never be able to access, modify, infer, or influence another tenant's data or resources unless an explicitly authorized cross-tenant operation exists.

For an AI platform, tenant isolation is broader than database isolation. Tenant boundaries may exist across:

  • Authentication
  • API requests
  • Databases
  • Object storage
  • Vector databases
  • RAG indexes
  • AI conversations
  • Memory
  • Caches
  • Queues
  • Background jobs
  • Model execution
  • Logs
  • Analytics
  • Notifications
  • Billing
  • Temporary files
  • Browser state
  • Network resources
  • Administrative interfaces

A platform can therefore have a perfectly secure database while still suffering from a cross-tenant vulnerability through a cache, object-storage path, vector search, background worker, or AI memory system.

74.2 Tenant Isolation as a Security Boundary

A tenant should be treated as a first-class security boundary.

Example:

Platform
│
├── Tenant A
│   ├── Users
│   ├── Projects
│   ├── Files
│   ├── Conversations
│   ├── AI generations
│   └── Vector data
│
├── Tenant B
│   ├── Users
│   ├── Projects
│   ├── Files
│   ├── Conversations
│   └── Vector data
│
└── Tenant C
    ├── Users
    ├── Projects
    ├── Files
    ├── Conversations
    └── Vector data
Enter fullscreen mode Exit fullscreen mode

The security model must prevent:

Tenant A → Tenant B data
Tenant B → Tenant C data
Tenant C → Tenant A data
Enter fullscreen mode Exit fullscreen mode

even if an attacker knows:

  • another tenant's identifier
  • another object's identifier
  • a file URL
  • a project identifier
  • a conversation identifier
  • a vector-document identifier
  • an API endpoint
  • an internal job identifier

Tenant IDs must therefore be treated as authorization attributes, not as security secrets.

74.3 Tenant Identification

Every authenticated request should have a trusted tenant context.

A simplified request context might look like:

Request
   ↓
Authentication
   ↓
User identity
   ↓
Membership lookup
   ↓
Tenant context
   ↓
Authorization
   ↓
Resource access
Enter fullscreen mode Exit fullscreen mode

For example:

type RequestContext = {
  userId: string;
  tenantId: string;
  roles: string[];
  permissions: string[];
};
Enter fullscreen mode Exit fullscreen mode

The important rule is:

The application must derive tenant membership from trusted authentication and authorization data rather than trusting arbitrary client-supplied tenant identifiers.

Unsafe conceptual pattern:

POST /api/files
{
  tenantId: "tenant-b"
}
Enter fullscreen mode Exit fullscreen mode

if the server simply trusts that value.

Safer conceptual pattern:

Authenticated user
        ↓
Membership database
        ↓
Authorized tenant
        ↓
Server-generated tenant context
        ↓
Database query
Enter fullscreen mode Exit fullscreen mode

74.4 Tenant Membership

A user may belong to one or multiple tenants.

Example:

User
 ├── Tenant A → owner
 ├── Tenant B → member
 └── Tenant C → viewer
Enter fullscreen mode Exit fullscreen mode

Therefore authorization should distinguish:

identity ≠ tenant membership ≠ resource permission
Enter fullscreen mode Exit fullscreen mode

A user being authenticated does not automatically mean they can access every tenant.

A robust model can contain:

users
organizations
memberships
roles
permissions
projects
resources
Enter fullscreen mode Exit fullscreen mode

Example relationship:

User
  ↓
Membership
  ↓
Tenant
  ↓
Project
  ↓
Resource
Enter fullscreen mode Exit fullscreen mode

This supports hierarchical authorization.

74.5 Database Tenant Isolation

A common shared-database architecture is:

Single Database
      │
      ├── users
      ├── tenants
      ├── memberships
      ├── projects
      ├── files
      ├── conversations
      └── generations
Enter fullscreen mode Exit fullscreen mode

Each tenant-owned record should contain a tenant identifier.

Example:

projects
--------------------------------
id
tenant_id
name
created_at
Enter fullscreen mode Exit fullscreen mode 
generations
--------------------------------
id
tenant_id
user_id
project_id
model
status
created_at
Enter fullscreen mode Exit fullscreen mode

The tenant identifier should be part of the authorization boundary.

Instead of conceptually doing:

SELECT *
FROM projects
WHERE id = $1;
Enter fullscreen mode Exit fullscreen mode

the secure model is:

SELECT *
FROM projects
WHERE id = $1
  AND tenant_id = $2;
Enter fullscreen mode Exit fullscreen mode

The second condition is critical.

74.6 Object-Level Authorization

One of the most important multi-tenant controls is object-level authorization.

Suppose:

Tenant A
  project_123

Tenant B
  project_456
Enter fullscreen mode Exit fullscreen mode

An attacker from Tenant A changes:

project_123
Enter fullscreen mode Exit fullscreen mode

to:

project_456
Enter fullscreen mode Exit fullscreen mode

The API must not return Tenant B's project.

The security decision should be:

Does this authenticated principal
have permission to access
THIS resource
inside THIS tenant?
Enter fullscreen mode Exit fullscreen mode

not simply:

Is the user authenticated?
Enter fullscreen mode Exit fullscreen mode

This protects against insecure direct object reference and broken object-level authorization patterns.

74.7 Row-Level Security

Database-level row-level security can provide an additional defense layer.

Conceptually:

Application authorization
        +
Database authorization
        =
Defense in depth
Enter fullscreen mode Exit fullscreen mode

For databases that support row-level security, policies can restrict records according to the active tenant context.

Conceptually:

Current tenant = Tenant A

Allowed:
tenant_id = Tenant A

Denied:
tenant_id = Tenant B
tenant_id = Tenant C
Enter fullscreen mode Exit fullscreen mode

This reduces dependence on every individual application query being perfect.

However:

Row-level security should complement application authorization, not replace proper application design.

74.8 Tenant Context Propagation

Tenant identity must survive the entire request lifecycle.

Example:

HTTP Request
    ↓
API Gateway
    ↓
Application
    ↓
Service
    ↓
Queue
    ↓
Worker
    ↓
Database
    ↓
Object Storage
Enter fullscreen mode Exit fullscreen mode

If tenant context disappears at one stage, isolation can fail.

A job should therefore contain trusted tenant context.

Example:

type GenerationJob = {
  jobId: string;
  tenantId: string;
  userId: string;
  projectId: string;
  generationId: string;
};
Enter fullscreen mode Exit fullscreen mode

The worker should validate that:

job.tenantId
matches
resource.tenantId
Enter fullscreen mode Exit fullscreen mode

before processing the job.

74.9 Background Worker Isolation

AI platforms frequently use asynchronous processing.

Example:

User
 ↓
API
 ↓
Queue
 ↓
Worker
 ↓
AI Model
 ↓
Storage
Enter fullscreen mode Exit fullscreen mode

A dangerous worker design might process a job using only:

generationId
Enter fullscreen mode Exit fullscreen mode

without verifying its tenant.

A safer design validates the complete ownership chain:

Job
 ↓
Generation
 ↓
Project
 ↓
Tenant
Enter fullscreen mode Exit fullscreen mode

Conceptually:

job.tenant_id
      ↓
generation.tenant_id
      ↓
project.tenant_id
Enter fullscreen mode Exit fullscreen mode

All relevant relationships should agree.

74.10 Object Storage Isolation

Object storage introduces another major tenant boundary.

Example:

bucket/
  tenant-a/
    project-1/
      image.png

  tenant-b/
    project-7/
      image.png
Enter fullscreen mode Exit fullscreen mode

Storage paths can help organization, but paths alone are not authorization.

An attacker should not gain access simply by guessing:

tenant-b/project-7/image.png
Enter fullscreen mode Exit fullscreen mode

The application should authorize access before issuing a download or signed URL.

Recommended conceptual flow:

User request
    ↓
Authenticate
    ↓
Authorize resource
    ↓
Verify tenant ownership
    ↓
Generate short-lived signed URL
    ↓
Download
Enter fullscreen mode Exit fullscreen mode

74.11 Signed URL Security

Signed URLs should be:

  • short-lived
  • scoped
  • generated only after authorization
  • restricted to the required object
  • protected against unintended reuse

Avoid unnecessarily long expiration periods.

A signed URL should not become a permanent alternative authentication mechanism.

74.12 Vector Database Isolation

RAG systems create an especially important multi-tenancy problem.

Suppose:

Tenant A documents
Tenant B documents
Tenant C documents
Enter fullscreen mode Exit fullscreen mode

are stored in one vector database.

A naive semantic search could retrieve:

Tenant A query
        ↓
Global vector search
        ↓
Tenant B document
Enter fullscreen mode Exit fullscreen mode

This is a severe information-isolation failure.

Every vector search should include a trusted tenant filter.

Conceptually:

query embedding
      +
tenant_id = current tenant
      ↓
vector search
      ↓
authorized documents only
Enter fullscreen mode Exit fullscreen mode

The tenant boundary must be enforced before or as part of retrieval, not merely after results are returned.

74.13 RAG Isolation

A secure RAG pipeline should look like:

User
 ↓
Authentication
 ↓
Tenant authorization
 ↓
Tenant-specific retrieval
 ↓
Document authorization
 ↓
Context construction
 ↓
AI model
 ↓
Output policy checks
Enter fullscreen mode Exit fullscreen mode

Not:

User
 ↓
Global search
 ↓
Filter results afterward
Enter fullscreen mode Exit fullscreen mode

Filtering after retrieval can still create risks involving:

  • accidental context leakage
  • ranking influence
  • metadata exposure
  • logging
  • prompt construction
  • model inference

The safest approach is to prevent unauthorized data from entering the retrieval result set.

74.14 AI Memory Isolation

Long-term AI memory must also be tenant-aware.

Example:

Tenant A
 └── User 1
      └── Memory A

Tenant B
 └── User 2
      └── Memory B
Enter fullscreen mode Exit fullscreen mode

The system must prevent:

Tenant A request
       ↓
Memory retrieval
       ↓
Tenant B memory
Enter fullscreen mode Exit fullscreen mode

Memory should have explicit ownership metadata such as:

tenant_id
user_id
conversation_id
project_id
memory_scope
Enter fullscreen mode Exit fullscreen mode

A memory retrieval operation should enforce those boundaries.

74.15 Cache Isolation

Caches are frequently overlooked.

Suppose an API stores:

cache["project:123"] = project_data
Enter fullscreen mode Exit fullscreen mode

If project identifiers are globally addressable but authorization is not part of the cache design, a second tenant could potentially receive cached data.

A safer conceptual cache key can include the tenant:

tenant:A:project:123
Enter fullscreen mode Exit fullscreen mode

or, preferably, authorization should still be independently checked before returning cached data.

Tenant-aware cache design should apply to:

  • API responses
  • AI responses
  • embeddings
  • user profiles
  • permissions
  • search results
  • generated media metadata
  • session state

74.16 Session Isolation

Session data should never be ambiguously associated with multiple tenants.

A session should identify:

session_id
user_id
tenant_id
created_at
expires_at
Enter fullscreen mode Exit fullscreen mode

When a user switches organizations, the active tenant context should be explicitly updated and re-authorized.

The application should not assume:

same user = same tenant
Enter fullscreen mode Exit fullscreen mode

because one user may belong to several tenants.

74.17 Queue Isolation

Queues can also leak information.

Consider:

queue:
  job1 → Tenant A
  job2 → Tenant B
  job3 → Tenant C
Enter fullscreen mode Exit fullscreen mode

Workers must not assume that a job identifier is enough.

Every job should carry validated ownership context.

Additionally:

  • avoid exposing internal queue identifiers to clients
  • authorize job-status requests
  • validate ownership before cancellation
  • validate ownership before retry
  • prevent cross-tenant job substitution

74.18 Network-Level Isolation

Large platforms may require stronger infrastructure separation.

Possible architecture:

Internet
   ↓
API Gateway
   ↓
Tenant-aware services
   ↓
Internal service network
   ↓
Data services
Enter fullscreen mode Exit fullscreen mode

Higher-isolation deployments may use:

Tenant
 ↓
Dedicated namespace
 ↓
Dedicated service resources
 ↓
Dedicated database/schema
 ↓
Dedicated storage
Enter fullscreen mode Exit fullscreen mode

The correct level depends on:

  • threat model
  • regulatory requirements
  • customer expectations
  • scale
  • cost
  • operational complexity

74.19 Isolation Models

Common multi-tenant database models include:

Model 1 — Shared database, shared tables 

Database
 └── Shared tables
      └── tenant_id
Enter fullscreen mode Exit fullscreen mode

Advantages:

  • lower cost
  • simpler infrastructure
  • easier scaling

Risks:

  • requires strong tenant enforcement
  • query mistakes can become serious

Model 2 — Shared database, separate schemas 

Database
 ├── tenant_a_schema
 ├── tenant_b_schema
 └── tenant_c_schema
Enter fullscreen mode Exit fullscreen mode

Provides stronger logical separation but introduces schema-management complexity.

Model 3 — Separate database per tenant 

Tenant A → Database A
Tenant B → Database B
Tenant C → Database C
Enter fullscreen mode Exit fullscreen mode

Provides stronger isolation but increases:

  • operational complexity
  • migration complexity
  • monitoring requirements
  • infrastructure cost

Model 4 — Hybrid isolation

A platform may classify tenants.

Standard tenants
    ↓
Shared infrastructure

High-isolation tenants
    ↓
Dedicated infrastructure
Enter fullscreen mode Exit fullscreen mode

This can balance cost and security.

74.20 Cross-Tenant Attack Scenarios

Security testing should consider realistic failure modes.

Scenario A — Identifier substitution 

Tenant A
 ↓
changes resource ID
 ↓
Tenant B resource
Enter fullscreen mode Exit fullscreen mode

Expected result:

403 Forbidden
Enter fullscreen mode Exit fullscreen mode

or an equivalent non-disclosing response.

Scenario B — Tenant parameter manipulation 

tenant_id=A
      ↓
change to
tenant_id=B
Enter fullscreen mode Exit fullscreen mode

Expected result:

authorization failure
Enter fullscreen mode Exit fullscreen mode

Scenario C — Storage path manipulation 

Tenant A
 ↓
attempts Tenant B object path
Enter fullscreen mode Exit fullscreen mode

Expected result:

access denied
Enter fullscreen mode Exit fullscreen mode

Scenario D — Vector filter removal 

Tenant A
 ↓
attempts global vector search
Enter fullscreen mode Exit fullscreen mode

Expected result:

query rejected
Enter fullscreen mode Exit fullscreen mode

or the system automatically applies the trusted tenant boundary.

Scenario E — Cache collision 

Tenant A request
      ↓
cache entry
      ↓
Tenant B receives same entry
Enter fullscreen mode Exit fullscreen mode

Expected result:

tenant-specific cache isolation
Enter fullscreen mode Exit fullscreen mode

Scenario F — Job substitution 

Tenant A
 ↓
submits Tenant B job ID
Enter fullscreen mode Exit fullscreen mode

Expected result:

authorization failure
Enter fullscreen mode Exit fullscreen mode

74.21 Cross-Tenant Data Leakage Through AI

AI systems create additional leakage channels.

For example:

Tenant A prompt
        ↓
retrieval
        ↓
Tenant B document
        ↓
LLM
        ↓
Tenant A response
Enter fullscreen mode Exit fullscreen mode

The model itself may not be the original security failure.

The underlying failure is:

unauthorized context → model
Enter fullscreen mode Exit fullscreen mode

Therefore AI security must protect the entire context pipeline.

Security boundary:

Tenant
 ↓
Authorization
 ↓
Retrieval
 ↓
Context
 ↓
Model
 ↓
Output
Enter fullscreen mode Exit fullscreen mode

74.22 Model-Level Tenant Isolation

If multiple tenants share an AI model service, requests should still carry tenant-aware metadata.

Example:

request_id
tenant_id
user_id
model_id
policy_context
Enter fullscreen mode Exit fullscreen mode

The model provider or internal inference layer should not be allowed to accidentally mix conversational state between tenants.

Stateless inference is generally easier to isolate than shared mutable model-session state.

74.23 Training Data Isolation

If customer data is used for model improvement, additional controls are required.

A tenant's private data should not automatically become:

global training data
Enter fullscreen mode Exit fullscreen mode

without appropriate authorization, governance, and disclosure.

A safer conceptual separation is:

Production user data
        │
        ├── operational use
        │
        ├── analytics
        │
        └── optional training pipeline
                    ↓
             explicit policy
                    ↓
              approved dataset
Enter fullscreen mode Exit fullscreen mode

Training pipelines require provenance and tenant-boundary controls.

74.24 Logging Isolation

Logs can accidentally become a cross-tenant data source.

Example:

logs:
tenant A prompt
tenant B prompt
tenant C prompt
Enter fullscreen mode Exit fullscreen mode

An ordinary tenant user should never gain access to global logs.

Administrative log access should also be:

  • restricted
  • audited
  • justified
  • monitored

Sensitive AI prompts, uploaded documents, tokens, and generated content should not be unnecessarily written to logs.

74.25 Analytics Isolation

Analytics systems can accidentally combine tenant information.

For example:

Tenant A dashboard
        ↓
global aggregation
        ↓
Tenant B metrics
Enter fullscreen mode Exit fullscreen mode

Every analytics query should define its intended scope.

Possible levels:

user
project
tenant
platform
Enter fullscreen mode Exit fullscreen mode

Platform-wide analytics should require elevated privileges.

74.26 Billing Isolation

Billing records are tenant-sensitive.

A tenant should only access:

its own invoices
its own subscriptions
its own usage
its own payment metadata
Enter fullscreen mode Exit fullscreen mode

Usage metering should also be tenant-aware:

tenant_id
resource
quantity
timestamp
Enter fullscreen mode Exit fullscreen mode

This prevents one tenant's AI usage from being charged to another tenant.

74.27 Notifications

Notifications should also contain tenant context.

Example:

Tenant A
 └── generation completed

Tenant B
 └── generation failed
Enter fullscreen mode Exit fullscreen mode

The notification system must prevent:

Tenant A user
       ↓
Tenant B notification
Enter fullscreen mode Exit fullscreen mode

This includes:

  • email
  • push notifications
  • SMS
  • in-app notifications
  • webhooks

74.28 Webhook Isolation

Webhooks should be associated with the correct tenant.

Example:

webhook_id
tenant_id
endpoint
secret_reference
event_type
Enter fullscreen mode Exit fullscreen mode

Event generation should verify:

event.tenant_id
==
webhook.tenant_id
Enter fullscreen mode Exit fullscreen mode

before delivery.

74.29 Tenant-Aware API Gateway

The API gateway can provide an early security layer.

Possible responsibilities:

  • authentication
  • request correlation
  • tenant context
  • rate limiting
  • abuse detection
  • request-size limits
  • routing
  • audit metadata

However, downstream services should still perform authorization.

The gateway should not become the only tenant-security mechanism.

74.30 Service-to-Service Tenant Propagation

Internal requests should carry trusted context.

Conceptually:

API
 ↓
Generation Service
 ↓
Storage Service
Enter fullscreen mode Exit fullscreen mode

The storage service should know:

Which tenant?
Which user?
Which resource?
Which permission?
Enter fullscreen mode Exit fullscreen mode

Blindly trusting arbitrary headers from clients is unsafe.

Tenant context should originate from trusted internal authentication mechanisms.

74.31 Tenant Isolation and Admin Access

Administrators create special risks.

An administrator may legitimately have access to multiple tenants, but that does not mean:

admin = unrestricted access
Enter fullscreen mode Exit fullscreen mode

Administrative access should still be:

  • role-based
  • purpose-limited
  • audited
  • monitored
  • revocable
  • preferably time-limited for sensitive actions

Support tools should avoid silently impersonating users.

74.32 Tenant Deletion

Tenant deletion must be comprehensive.

Deletion may involve:

Database
Storage
Vectors
Caches
Queues
Backups
Search indexes
AI memory
Analytics
Notifications
Webhooks
Logs
Enter fullscreen mode Exit fullscreen mode

A tenant deletion workflow should define:

what is deleted
what is retained
why it is retained
retention duration
who authorized deletion
verification status
Enter fullscreen mode Exit fullscreen mode

Deletion should also prevent orphaned resources.

74.33 Tenant Offboarding

When a customer leaves the platform:

Tenant disabled
      ↓
sessions revoked
      ↓
API credentials revoked
      ↓
webhooks disabled
      ↓
jobs stopped/cancelled
      ↓
access removed
      ↓
data lifecycle executed
Enter fullscreen mode Exit fullscreen mode

This prevents former users from continuing to access tenant resources.

74.34 Testing Tenant Isolation

A serious platform should test tenant boundaries systematically.

Minimum test categories:

Authentication
Authorization
Database
Storage
Vectors
RAG
Memory
Cache
Queues
Workers
APIs
Webhooks
Notifications
Billing
Analytics
Admin tools
Deletion
Backups
Enter fullscreen mode Exit fullscreen mode

A useful test matrix:

Component Tenant A → Tenant B test
API Required
Database Required
Storage Required
Vector DB Required
RAG Required
Memory Required
Cache Required
Queue Required
Worker Required
Billing Required
Notifications Required
Admin UI Required

74.35 Automated Isolation Tests

Automated tests should create at least two tenants:

Tenant A
Tenant B
Enter fullscreen mode Exit fullscreen mode

Then create equivalent resources:

A/project
B/project
Enter fullscreen mode Exit fullscreen mode

Test:

A user → A resource = allowed
A user → B resource = denied
B user → B resource = allowed
B user → A resource = denied
Enter fullscreen mode Exit fullscreen mode

Repeat this across every resource type.

74.36 Property-Based Security Principle

A useful security invariant is:

For every tenant-owned resource R:

request.tenant_id == R.tenant_id
Enter fullscreen mode Exit fullscreen mode

must be true before access is granted.

For hierarchical resources:

request.tenant
    =
resource.project.tenant
    =
resource.document.tenant
    =
resource.vector.tenant
Enter fullscreen mode Exit fullscreen mode

Any mismatch should terminate the operation.

74.37 Fail-Closed Behavior

If tenant information is:

  • missing
  • malformed
  • ambiguous
  • expired
  • inconsistent
  • unauthorized

the system should fail closed.

Conceptually:

Unknown tenant
     ↓
DENY
Enter fullscreen mode Exit fullscreen mode

rather than:

Unknown tenant
     ↓
fallback to global scope
Enter fullscreen mode Exit fullscreen mode

Global fallback behavior is particularly dangerous in multi-tenant systems.

74.38 Tenant Isolation Monitoring

Security monitoring should detect unusual cross-tenant patterns.

Examples:

User repeatedly requesting foreign resource IDs
Enter fullscreen mode Exit fullscreen mode 
Large number of authorization failures
Enter fullscreen mode Exit fullscreen mode 
Unexpected tenant changes
Enter fullscreen mode Exit fullscreen mode 
Vector searches without tenant filters
Enter fullscreen mode Exit fullscreen mode 
Storage access outside tenant prefix
Enter fullscreen mode Exit fullscreen mode

These events can indicate:

  • application bugs
  • compromised accounts
  • malicious users
  • automation errors
  • privilege escalation attempts

74.39 Incident Response for Cross-Tenant Leakage

If cross-tenant leakage is suspected:

Step 1 — Contain

Disable affected endpoint, workflow, or integration.

Step 2 — Determine scope

Identify:

which tenants
which resources
which time period
which users
Enter fullscreen mode Exit fullscreen mode

Step 3 — Preserve evidence

Retain appropriate:

  • audit logs
  • request IDs
  • access logs
  • authorization decisions
  • job records

Step 4 — Revoke exposure

Invalidate:

  • signed URLs
  • sessions
  • API tokens
  • temporary credentials

as appropriate.

Step 5 — Correct the boundary

Fix the authorization or isolation failure.

Step 6 — Verify

Perform targeted cross-tenant testing.

Step 7 — Review

Determine why existing controls failed.

74.40 Reference Architecture

A secure multi-tenant AI platform can be modeled as:

                    Internet
                       │
                       ▼
                ┌──────────────┐
                │ API Gateway  │
                └──────┬───────┘
                       │
                       ▼
                Authentication
                       │
                       ▼
                Tenant Context
                       │
                       ▼
                Authorization
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
    Database        Storage        AI Services
        │              │              │
        │              │         ┌────┴────┐
        │              │         │ RAG     │
        │              │         │ Memory  │
        │              │         │ Models  │
        │              │         └─────────┘
        │              │
        └──────────────┼──────────────┐
                       │              │
                     Queue          Cache
                       │              │
                       ▼              ▼
                    Workers       Tenant Scope
                       │
                       ▼
                 Audit / Monitoring
Enter fullscreen mode Exit fullscreen mode

Every branch must preserve the tenant boundary.

74.41 Security Design Rules

The following rules should become platform-wide engineering requirements:

  1. Every tenant-owned resource has an explicit ownership model.
  2. Tenant identity is derived from trusted authentication context.
  3. Client-supplied tenant IDs are never blindly trusted.
  4. Every object access requires authorization.
  5. Database queries enforce tenant scope.
  6. Storage access is tenant-aware.
  7. Vector retrieval is tenant-aware.
  8. RAG context is tenant-aware.
  9. AI memory is tenant-aware.
  10. Cache keys and cache authorization are tenant-aware.
  11. Queue jobs carry validated tenant context.
  12. Workers verify resource ownership.
  13. Notifications are tenant-scoped.
  14. Billing records are tenant-scoped.
  15. Webhooks are tenant-scoped.
  16. Analytics enforce intended scope.
  17. Administrative access is separately controlled.
  18. Unknown tenant context fails closed.
  19. Cross-tenant tests are automated.
  20. Tenant isolation failures trigger incident response.

74.42 Final Security Principle

Multi-tenancy should never be implemented as merely adding:

tenant_id
Enter fullscreen mode Exit fullscreen mode

to database tables.

A true multi-tenant security architecture establishes a consistent boundary across the entire platform:

Identity
   ↓
Tenant
   ↓
Authorization
   ↓
Data
   ↓
Storage
   ↓
Retrieval
   ↓
Memory
   ↓
Cache
   ↓
Queue
   ↓
Worker
   ↓
AI Model
   ↓
Output
   ↓
Audit
Enter fullscreen mode Exit fullscreen mode

The most important invariant is:

A tenant can access only the resources, computations, context, and outputs that belong to that tenant or that have been explicitly authorized for cross-tenant use.

For an AI platform, this boundary must be enforced before sensitive data reaches retrieval systems, AI models, caches, workers, or external services.

A secure multi-tenant platform therefore treats tenant isolation as a system-wide security invariant, not as a feature implemented in one database query.

Top comments (0)