Multi-Tenancy Isolation Test Case Prompt from SaaS Specs

This prompt is designed for SaaS platform testers and QA engineers who need to verify that tenant isolation boundaries hold under real-world conditions. Use it when you have a multi-tenant architecture specification, access control matrix, or tenant data model and need to generate structured test cases that validate cross-tenant data access prevention, configuration leakage between tenants, and resource quota enforcement per tenant. The ideal user is a senior QA engineer or SDET who understands the platform's tenancy model and can provide detailed specifications, not just a high-level architectural diagram.

The prompt requires concrete input documents: a tenant data model showing how tenant IDs propagate through the stack, an access control matrix defining per-role permissions across tenant boundaries, and isolation requirements specifying what must never leak between tenants. It produces test cases with explicit tenant context setup (e.g., 'Authenticate as Tenant A, create resource X, then attempt access as Tenant B'), attack vectors (e.g., IDOR attempts, shared cache poisoning, metadata enumeration), expected isolation behavior, and traceability back to specific isolation requirements. Each generated test case includes a unique test ID, preconditions, steps, expected results, and a risk classification.

Do not use this prompt for single-tenant application testing, general authentication testing, or performance load testing. It is specifically scoped to multi-tenancy isolation verification. If your specifications are incomplete or you lack a documented tenant isolation model, run a specification review first—this prompt cannot infer isolation requirements from code alone. For regulated environments, always route generated test cases through a security architect review before execution, and ensure test data is synthetic rather than copied from production tenants.

This prompt template converts your SaaS platform's tenant isolation specifications, architecture diagrams, and access control matrices into a structured suite of negative test cases. It is designed to produce tests that verify cross-tenant data access prevention, tenant-specific configuration leakage, resource quota enforcement, and tenant context propagation across shared infrastructure layers. Replace every square-bracket placeholder with your actual specifications before running the prompt. The output is a traceable test suite with preconditions, attack steps, expected isolation behavior, and evidence requirements.

textCopy
You are a senior SaaS security test architect. Your task is to generate a comprehensive suite of multi-tenancy isolation test cases from the provided specifications.

## INPUTS
- Tenant isolation architecture specification: [TENANT_ISOLATION_SPEC]
- Access control matrix and role definitions: [ACCESS_CONTROL_MATRIX]
- Shared infrastructure component list: [SHARED_COMPONENTS]
- Tenant data model and partitioning strategy: [DATA_PARTITIONING_STRATEGY]
- Resource quota and rate limit policies: [RESOURCE_QUOTA_POLICIES]
- Tenant context propagation mechanism: [CONTEXT_PROPAGATION_MECHANISM]
- Known isolation boundaries and trust zones: [ISOLATION_BOUNDARIES]

## OUTPUT SCHEMA
Return a JSON array of test case objects with this exact structure:
{
  "testCases": [
    {
      "testId": "string (e.g., TI-001)",
      "testName": "string",
      "isolationCategory": "cross_tenant_data_access | config_leakage | quota_enforcement | context_spoofing | shared_infrastructure_isolation",
      "riskLevel": "critical | high | medium | low",
      "tenantSetup": {
        "tenantA": "string (description of source tenant state)",
        "tenantB": "string (description of target tenant state)",
        "sharedResource": "string (if applicable)"
      },
      "preconditions": ["string"],
      "attackVector": "string (detailed steps the attacker tenant attempts)",
      "expectedIsolationBehavior": "string (what the system must do to prevent the breach)",
      "expectedEvidence": ["string (logs, response codes, audit entries that prove isolation held)"],
      "bypassScenario": "string (what failure looks like if isolation is broken)",
      "affectedComponents": ["string"],
      "testType": "automated | manual | semi_automated",
      "cleanupSteps": ["string"]
    }
  ]
}

## CONSTRAINTS
- Generate at least one test case for each isolationCategory.
- For cross_tenant_data_access, include tests for direct API calls, SQL injection attempts, and object reference manipulation.
- For config_leakage, include tests for feature flags, rate limits, and custom domain settings.
- For quota_enforcement, include tests where one tenant's resource exhaustion must not affect another tenant.
- For context_spoofing, include tests where Tenant A attempts to pass Tenant B's tenant ID in headers, tokens, or request parameters.
- For shared_infrastructure_isolation, include tests for connection pool exhaustion, cache key collision, and message queue cross-delivery.
- Every test case must specify what logs or audit trails prove isolation held.
- Flag any test that requires destructive actions or production data access as manual with human review required.

## EXAMPLES
Input: A SaaS platform using row-level security with a tenant_id column in a shared PostgreSQL database, JWT-based tenant context propagation, and per-tenant rate limiting via Redis.

Example output test case:
{
  "testId": "TI-001",
  "testName": "Cross-Tenant Data Access via Direct Tenant ID Manipulation in API Request",
  "isolationCategory": "cross_tenant_data_access",
  "riskLevel": "critical",
  "tenantSetup": {
    "tenantA": "Authenticated user in Tenant A with valid JWT containing tenant_id=A",
    "tenantB": "Tenant B exists with its own isolated data rows",
    "sharedResource": "PostgreSQL database with row-level security policy on tenant_id column"
  },
  "preconditions": [
    "Tenant A user is authenticated and holds a valid session",
    "Tenant B has data rows with tenant_id=B",
    "Row-level security policy is active on the target table"
  ],
  "attackVector": "Tenant A user sends a GET request to /api/records with a modified JWT claim tenant_id=B or passes X-Tenant-ID: B header",
  "expectedIsolationBehavior": "The API gateway or middleware must reject the tenant context override. The database query must apply row-level security using the verified tenant context from the authenticated session, not the request header. Tenant A must receive only tenant_id=A rows or a 403 Forbidden response.",
  "expectedEvidence": [
    "Application log showing tenant context mismatch detected",
    "403 Forbidden response in API access logs",
    "Database audit log confirming query filtered by correct tenant_id=A",
    "No Tenant B data rows in the response body"
  ],
  "bypassScenario": "If the application trusts the X-Tenant-ID header without re-verifying against the authenticated session, Tenant A receives Tenant B's data rows in the response.",
  "affectedComponents": ["API Gateway", "Authentication Middleware", "PostgreSQL RLS Policy"],
  "testType": "automated",
  "cleanupSteps": ["Revoke any modified tokens", "Reset rate limit counters for Tenant A"]
}

## RISK_LEVEL
High. Multi-tenancy isolation failures can cause data breaches across customer boundaries. All generated test cases must be reviewed by a security architect before execution in any environment that contains production tenant data. Tests marked as manual require human approval before each run.

To adapt this prompt, replace the [TENANT_ISOLATION_SPEC] placeholder with your actual architecture document describing how tenants are separated—whether through database-per-tenant, schema-per-tenant, or row-level security. The [ACCESS_CONTROL_MATRIX] should contain your role-to-permission mappings and tenant-scoping rules. If your platform uses multiple isolation strategies for different components, list each in [SHARED_COMPONENTS] and describe the partitioning approach in [DATA_PARTITIONING_STRATEGY]. The output schema is intentionally strict: every test case must include the expectedEvidence field so that your test automation or manual QA team can confirm isolation held, not just that the test passed. Before running this prompt in a CI pipeline, validate the JSON output against the schema and reject any test case missing a bypassScenario—that field is your canary for whether the model understood the failure mode.

After generating the test suite, run a coverage check: map each isolationCategory to your trust boundaries and confirm no boundary is untested. For high-risk SaaS platforms handling PII or payment data, require a security architect to review all critical and high risk test cases before they enter your test management system. Store the generated test cases with a version reference to the input specifications so that when your isolation architecture changes, you can regenerate and diff the test suite.

This prompt is not a standalone QA tool. It is a generation engine that must be embedded in a pipeline with validation, human review, and traceability controls. The prompt accepts a SaaS specification document and produces structured test cases, but the output is a candidate artifact—not a verified test suite. The harness must treat every generated test case as a draft that requires schema validation, coverage gap analysis, and security reviewer sign-off before it lands in a test management system.

Wire the prompt into a workflow that first extracts the relevant specification sections (tenant model, data isolation rules, configuration scoping, quota definitions) and passes them as [SPECIFICATION_TEXT]. Set [TENANT_MODEL] to the isolation architecture in use (e.g., shared-database, database-per-tenant, hybrid). The [OUTPUT_SCHEMA] should enforce a strict JSON array of test case objects, each containing test_id, isolation_vector, preconditions, steps, expected_result, tenant_context, and risk_level. Validate every output against this schema programmatically. Reject any test case missing tenant_context—the field that describes which tenant identity is active during the test—because without it, isolation intent is unverifiable.

After schema validation, run a coverage check: compare generated test vectors against a known list of isolation dimensions (cross-tenant data read, cross-tenant data write, configuration leakage, quota bypass, metadata exposure, shared cache poisoning, log leakage). Flag any missing dimensions and re-prompt with the gap list appended to [CONSTRAINTS]. For high-risk vectors like cross-tenant write attempts, route the test case to a human security reviewer before automation. Log every generation run with the prompt version, input spec hash, output test count, validation failures, and reviewer decisions. This audit trail is essential when a tenant isolation bug escapes to production and the investigation asks whether the test suite covered that vector.

Model choice matters. Use a model with strong instruction-following and structured output reliability for the initial generation pass. For the coverage gap analysis pass, a separate classifier prompt or a smaller, faster model can check whether each isolation dimension is represented in the output. Do not rely on the generation model to self-critique its own coverage—use a second pass with a focused eval prompt. When retrying after validation failures, include the specific schema violation or missing dimension in the retry context rather than re-running the original prompt blindly. This targeted repair loop reduces token waste and prevents the model from drifting away from the specification source.