Engineering

Multi-Tenant Access Control Prompt

Keep tenants out of each other's data — design the isolation model, the tenant-scoping rule every query must obey, and the cross-tenant leaks to test for.

Overview

In a multi-tenant system, the worst bug is one tenant seeing another's data, and it's one missing WHERE clause away. This prompt designs tenant isolation: the model (row-level, schema, or database), the scoping rule every data access must enforce, where the tenant context comes from (and why it can't be client-trusted), and the cross-tenant leak paths to test — shared caches, background jobs, admin tools.

Why This Works

Central scoping beats per-query filters you can forget — the #1 leak cause
Deriving tenant from auth (not the request) closes the obvious tampering path
The leak-path list catches caches and jobs that bypass the main scoping

Best for

Multi-tenant SaaS handling separate customers' data
Marketplaces and B2B apps with strict data boundaries
Teams adding multi-tenancy to a single-tenant app

Not for

Single-tenant apps
General authorization within one tenant — use the Authorization Review Prompt

Use cases

Designing data isolation for a SaaS platform
Preventing the missing-WHERE-clause cross-tenant leak
Listing the cross-tenant paths a security review must test

Customize This Resource

Opens this resource in the related tool with the fields pre-filled. Customize role, tone, and behavior rules — then generate your prompt.

Prompt Template

ROLE
You are designing tenant isolation for a multi-tenant application — preventing one tenant from accessing another's data.

INPUT
The system:
[Architecture, data model, and how tenants are identified]

DESIGN ISOLATION
1. MODEL: row-level (tenant_id), schema-per-tenant, or database-per-tenant — chosen on scale and isolation needs, with the trade-off.
2. SCOPING RULE: the single rule every data access must obey (e.g. every query filtered by the authenticated tenant), and how it's enforced centrally rather than per-query (middleware, ORM scope, RLS).
3. TENANT CONTEXT: where the tenant identity comes from on each request, and why it must derive from the authenticated session — never from a client-supplied parameter.
4. LEAK PATHS: the cross-tenant leak vectors to design against and test — shared caches keyed without tenant, background jobs running without tenant context, admin/impersonation tools, aggregate queries, file storage paths.
5. NOISY NEIGHBOR: how one tenant can't exhaust resources for others (where relevant).

RULES
- Tenant scoping must be enforced centrally; a per-query filter you can forget is a leak waiting to happen.
- Tenant context derives from auth, never from the request body or URL.

OUTPUT
The isolation model with rationale, the central scoping mechanism, and the leak-path test list.

Related Resources

Explore more resources that work well with this one.

Related Tools

Role Prompt Generator

Part of these Blueprints

End-to-end build journeys that use this resource.

Build a Marketplace with AI Blueprint · 9 stages

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources