Engineering Auth Multi-Tenancy

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.

How to use this resource

  1. Define the tenancy context

    Note how tenants map to data, where the tenant context comes from, and which stores are shared. The model is designed around keeping one tenant out of another data.

  2. Open this resource in Role Prompt Generator

    Load the prompt into Role Prompt Generator and fill in your context. It designs the isolation model and the scoping rule every data access must enforce.

  3. Review the isolation design

    Read the chosen model (row, schema, or database), the tenant-scoping rule, why the context cannot be client-trusted, and the cross-tenant leak paths to test.

  4. Tighten the model and re-run

    Close any leak path the design surfaces - shared caches, background jobs, admin tools - then regenerate so the scoping rule holds everywhere.

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

FAQ

How do I decide between row-level, schema-per-tenant, and database-per-tenant isolation?

The prompt's MODEL step forces that pick explicitly, choosing row-level (tenant_id), schema-per-tenant, or database-per-tenant based on your scale and isolation needs and stating the trade-off. Role Prompt Generator turns this into a prompt you run in your own assistant; the returned model is a design draft with rationale, so your team validates the choice against real requirements before building.

Where should the tenant identity come from on each request so it can't be tampered with?

The TENANT CONTEXT step and a hard RULE both require tenant identity to derive from the authenticated session, never from a client-supplied parameter, request body, or URL. Running this through Role Prompt Generator produces a prompt that designs that derivation; the output is a recommendation your engineers must confirm holds in your actual auth flow, not a guarantee the tampering path is closed.

Which cross-tenant leak paths does this prompt tell me to test beyond the query filter?

The LEAK PATHS step lists the vectors that bypass the main scoping: shared caches keyed without tenant, background jobs running without tenant context, admin/impersonation tools, aggregate queries, and file storage paths. It outputs these as a leak-path test list. That list is a checklist your security review must actually exercise, not proof the leaks are absent, since NewPrompt does not run or verify anything.

More resources from Role Prompt Generator

Resources that pair well

Related tools

Projects that use this resource

Guides for this resource

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