Multi-Tenant Query Rewriting Prompt with Tenant Context

This prompt is designed for SaaS platform teams operating a shared Retrieval Augmented Generation (RAG) infrastructure that serves multiple tenants. The primary job-to-be-done is to rewrite a user's natural language query before it reaches a vector or keyword index, injecting tenant-specific terminology, data scope boundaries, and access policies. The goal is to ensure that retrieval is strictly confined to the correct tenant partition, preventing cross-tenant data leakage at the retrieval layer. This is critical when a generic query like 'show me the Q3 revenue report' must resolve to entirely different documents for Tenant A versus Tenant B, based on their isolated data stores within the same physical index.

You should use this prompt when tenant isolation cannot be guaranteed solely by pre-filtering metadata at the database level. If your vector database applies a tenant ID filter after a semantic search, the query itself might still pull irrelevant or neighboring tenant vectors into the top-K candidate set, wasting compute and risking leakage. This prompt solves that by making the query semantically specific to the tenant's domain before it's embedded. For example, it can expand 'Q3 report' to 'Q3 2024 financial performance report for [Tenant A's Product Line]' using a tenant-specific glossary, ensuring the embedding is closer to the correct document cluster. Do not use this prompt for single-tenant applications where the entire index belongs to one organization, or when tenant context is already perfectly enforced by row-level security in a structured database without any need for semantic scoping on the query side.

Before implementing this prompt, you must have a reliable mechanism to inject the correct tenant context at runtime. This means your application middleware must resolve the user's identity to a tenant_id and fetch the corresponding tenant profile—including a terminology glossary, data scope rules, and access policies—before assembling the prompt. A failure to provide this context will result in a generic rewrite that fails to isolate tenants. Next, proceed to the prompt template to see how these dynamic inputs are structured, and then review the implementation harness to understand how to validate the rewritten query for tenant isolation before it is executed against your retrieval index.

This prompt template is the core instruction set for a multi-tenant query rewriting system. It takes a raw user query and a structured tenant context object and produces a rewritten query that is safe to execute against a tenant-partitioned retrieval index. The prompt enforces tenant isolation by explicitly binding the rewrite to the tenant's allowed data scopes, terminology, and access policies. Use this template as a starting point; you will need to replace each square-bracket placeholder with live data from your tenant context service before sending the request to the model.

textCopy
You are a query rewriting agent for a multi-tenant SaaS platform. Your job is to rewrite a user's query so that retrieval stays strictly within the correct tenant partition. You must inject tenant-specific terminology, enforce data scope boundaries, and apply tenant-level access policies.

## Tenant Context
- Tenant ID: [TENANT_ID]
- Tenant Name: [TENANT_NAME]
- Allowed Data Scopes: [ALLOWED_DATA_SCOPES]
- Denied Data Scopes: [DENIED_DATA_SCOPES]
- Tenant-Specific Terminology: [TENANT_TERMINOLOGY_MAP]
- Access Policies: [ACCESS_POLICIES]
- User Role within Tenant: [USER_ROLE]
- User Permissions: [USER_PERMISSIONS]

## Original User Query
[USER_QUERY]

## Rewriting Rules
1. Replace any generic terms with the tenant-specific equivalents from the Tenant-Specific Terminology map. Do not invent new terms.
2. Add explicit scope constraints to the query so that retrieval only considers documents within the Allowed Data Scopes. If the original query implies a scope outside the allowed list, narrow it to the closest allowed scope.
3. Remove or rewrite any query component that would require access to a Denied Data Scope. If the entire query targets a denied scope, output an empty query and set `blocked: true`.
4. Apply the Access Policies to determine if the user's role and permissions allow the requested information. If the policy denies access, output an empty query and set `blocked: true`.
5. Preserve the user's original intent as much as possible while enforcing the above rules.
6. Do not add information that is not present in the Tenant Context or the Original User Query.

## Output Format
Return a valid JSON object with the following schema:
{
  "rewritten_query": "string (the rewritten query, or empty string if blocked)",
  "blocked": boolean,
  "blocked_reason": "string (explanation if blocked, otherwise null)",
  "applied_terminology": ["string (list of tenant terms injected)"],
  "applied_scopes": ["string (list of allowed scopes applied)"],
  "warnings": ["string (any concerns about the rewrite, e.g., ambiguous scope mapping)"]
}

## Examples
[FEW_SHOT_EXAMPLES]

## Constraints
[CONSTRAINTS]

To adapt this template, start by wiring your tenant context resolution service to populate the placeholders. The [TENANT_TERMINOLOGY_MAP] should be a JSON object mapping generic terms to tenant-specific equivalents, sourced from the tenant's configuration. The [ALLOWED_DATA_SCOPES] and [DENIED_DATA_SCOPES] should be explicit lists of document partitions, tags, or namespaces. The [FEW_SHOT_EXAMPLES] placeholder is critical for teaching the model the expected behavior—include at least one example of a normal rewrite, one example of a blocked query due to scope violation, and one example of terminology injection. The [CONSTRAINTS] placeholder can be used to add additional rules, such as maximum query length or required output language. After populating the template, validate the model's output against the expected JSON schema before forwarding the rewritten query to your retrieval system. If the blocked field is true, log the blocked_reason and return a controlled empty result set to the user rather than executing any retrieval.

This prompt is not a standalone chatbot. It is a pre-retrieval transformation step that must sit between the user's raw query and the retrieval engine. The application layer is responsible for injecting the correct tenant context, validating the rewritten query against tenant boundaries, and logging every transformation for auditability. The prompt's job is to produce a rewritten query and a set of explicit tenant-scope constraints; the harness's job is to enforce those constraints before any document is retrieved.

Wiring the prompt into a retrieval pipeline requires a strict execution order. First, resolve the tenant identifier from the authenticated session or API key—never from user input. Second, fetch the tenant's configuration object, which must include tenant_id, allowed_document_scopes, tenant_terminology, and access_policies. Third, assemble the prompt with the raw user query, the tenant context, and the output schema. Fourth, parse the model's JSON response and validate that every scope constraint in the output maps to an allowed scope in the tenant configuration. Reject any rewritten query that introduces a scope not present in the tenant's allow-list. Fifth, pass the validated rewritten query and scope filters to the retrieval engine. Retries and fallbacks: if the model returns malformed JSON, retry once with a stricter schema reminder. If the rewritten query contains disallowed scopes, log the violation, strip the offending constraints, and fall back to a tenant-scoped keyword search. Do not retry scope violations—they indicate a prompt or tenant config issue that needs human review.

Model choice and tool use matter here. This prompt works best with models that have strong instruction-following and JSON output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may hallucinate tenant terminology or ignore scope constraints. This prompt should not call external tools or APIs—it is a pure text-to-JSON transformation. If your retrieval engine requires tool calls for filter construction, perform the tool call in the harness after validating the prompt's output, not inside the prompt itself. Observability: log the raw user query, the tenant ID, the full rewritten query, the scope constraints, and a hash of the tenant configuration version. This audit trail is essential for debugging cross-tenant leakage incidents and for demonstrating compliance during security reviews. Human review is not required for every query, but you should implement a monitoring alert that triggers when a rewritten query is rejected for scope violations or when the model's output deviates from the expected schema more than 5% of the time in a rolling window.

What to avoid: never pass the tenant configuration as a raw user input or allow the user to specify their own tenant ID. Never skip the scope validation step—even if the model has been reliable in testing, a single hallucinated scope can cause a cross-tenant data leak. Never use this prompt without versioning both the prompt template and the tenant configuration schema; a mismatch between the two will produce silent failures. Finally, do not treat this prompt as a security boundary on its own. The retrieval engine must enforce tenant isolation at the index or database level. The prompt is a query transformation aid, not an access control mechanism.