Multi-Tenant Model Isolation Prompt

This prompt is designed for platform engineers building AI infrastructure that serves multiple organizations from a single application instance. The core job-to-be-done is to inspect an incoming request, identify the tenant context, and produce a deterministic routing decision that enforces model instance separation and data boundary policies. The ideal user is an AI infrastructure engineer or platform architect who already has a tenant resolution mechanism (such as an API key, JWT claim, or header) and needs a prompt-based policy layer to prevent cross-tenant data leakage at the model routing level. You should use this prompt when your system routes requests to tenant-specific model deployments, dedicated inference endpoints, or isolated model instances, and you need an auditable, testable decision point that logs why a particular model instance was selected.

This prompt is not a tenant resolution system—it assumes the tenant identity is already resolved and injected into the prompt context via the [TENANT_CONTEXT] placeholder. It does not handle authentication, authorization, or encryption. The prompt's job is to apply isolation policies: mapping a tenant to their approved model deployment, detecting requests that attempt to cross tenant boundaries, and flagging inputs that contain data from multiple tenants or reference resources outside the tenant's scope. In practice, you will wire this prompt into a routing middleware layer that calls the model, parses the structured routing decision, and then directs the request to the appropriate tenant-specific inference endpoint. The output must include a tenant_id, a model_deployment identifier, an isolation_level (such as dedicated, shared-logical, or shared-physical), and a list of policy_violations if the request attempts to access resources outside the tenant boundary.

Do not use this prompt when all tenants share the same model instance and isolation is handled entirely at the application or database layer. If your system uses row-level security in a vector database or API-level authorization without model-level separation, this prompt adds unnecessary latency and complexity. Also avoid this prompt for single-tenant deployments where the entire stack is dedicated to one organization—there is no routing decision to make. Before implementing, ensure you have defined your tenant isolation tiers, documented which model deployments serve which tenants, and built eval suites that test for cross-tenant leakage patterns such as one tenant's context appearing in another tenant's model selection output. The next section provides the copy-ready prompt template you can adapt to your specific tenant topology.

This prompt template is designed to be integrated into a model routing middleware layer. It accepts a user request and tenant context, then produces a structured routing decision that enforces model instance separation and data boundary policies. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to populate from application context before inference.

codeCopy
SYSTEM:
You are a multi-tenant model isolation router. Your job is to produce a routing decision that enforces strict tenant data boundaries. You must never route a request from one tenant to a model instance or processing pipeline associated with another tenant. You must detect and flag any cross-tenant data leakage risks.

INPUT:
- Tenant ID: [TENANT_ID]
- Tenant Data Boundary Policy: [TENANT_POLICY]
- User Request: [USER_REQUEST]
- Available Model Instances: [MODEL_INSTANCES]
- Request Metadata: [REQUEST_METADATA]

OUTPUT SCHEMA:
{
  "decision": "ALLOWED" | "BLOCKED" | "REVIEW_REQUIRED",
  "routed_model_instance": "[MODEL_INSTANCE_ID]" | null,
  "isolation_check": {
    "tenant_boundary_respected": true | false,
    "cross_tenant_risk_detected": true | false,
    "risk_detail": "[EXPLANATION]" | null
  },
  "data_handling_notes": "[NOTES]",
  "confidence": 0.0-1.0
}

CONSTRAINTS:
- Never route a request to a model instance not explicitly assigned to [TENANT_ID].
- If [USER_REQUEST] contains data that appears to reference another tenant, flag as REVIEW_REQUIRED.
- If [TENANT_POLICY] requires data residency in a specific region, verify [MODEL_INSTANCES] deployment region matches.
- If no compliant model instance is available, return BLOCKED with explanation.
- If confidence is below 0.85, return REVIEW_REQUIRED.

EXAMPLES:
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with values from your application's tenant context and model registry. The [TENANT_POLICY] field should contain a structured description of the tenant's data handling requirements, such as data residency regions, approved model tiers, and isolation level. The [MODEL_INSTANCES] field should list available instances with their tenant assignments, deployment regions, and capability profiles. Before deploying, run this prompt through your eval suite using known tenant-request pairs and verify that cross-tenant routing attempts are consistently blocked or flagged for review.

The Multi-Tenant Model Isolation Prompt is not a standalone classifier; it is a policy enforcement point in your model routing middleware. Wire it as a synchronous pre-routing step that executes before any model invocation. The prompt receives the raw user input, the authenticated tenant context (tenant ID, data boundary region, compliance tier), and the list of available model instances mapped to tenants. Its output is a structured routing decision that must be validated before the request proceeds to the selected model. Never pass the prompt's output directly to a model dispatcher without running the validation harness described below.

Build a validation layer that enforces three hard constraints before the routing decision is accepted. First, confirm that the selected_model_instance exists in your live model registry and is explicitly mapped to the tenant_id in the request context—reject any decision that routes to an instance not in the tenant's allowlist. Second, verify that the data_boundary_region in the routing decision matches the tenant's configured region; flag any cross-region routing as a potential isolation violation for immediate review. Third, check the isolation_confidence score against your operational threshold (start at 0.95 for production). If confidence falls below the threshold, route to a human review queue instead of an automated model. Log every routing decision with the full prompt input, the raw model output, the validation results, and the final dispatch action. This audit trail is essential for compliance reviews and debugging isolation failures.

For retry logic, implement a single retry with a stricter system instruction if the first attempt fails validation. The retry prompt should explicitly list the validation errors and instruct the model to correct them. If the retry also fails, escalate to a human operator and block the request—never fall back to a default model instance, as this is the primary vector for cross-tenant leakage. When deploying changes to the prompt template, run your regression test suite against a golden dataset of tenant-routing scenarios that includes edge cases: same user input from different tenants, inputs containing other tenant IDs in the text, and requests that mention competitors or partners sharing infrastructure. Measure both routing accuracy and isolation violation rate. A single cross-tenant misroute in production is a critical incident, so treat this prompt with the same change management rigor as authentication or authorization code.