Entitlement-Check Query Rewrite Prompt for Secure RAG

This prompt is for teams building Retrieval-Augmented Generation (RAG) systems over compliance-sensitive, regulated, or classified data stores. Its job is to rewrite a user's natural language query while cross-referencing a provided user entitlement manifest. The rewritten query must embed explicit access constraints so that downstream retrieval components cannot surface documents outside the user's clearance scope. Use this prompt when a single retrieval index serves multiple user classes with different data access levels, and you need a pre-retrieval enforcement layer that fails closed.

The ideal user is an engineering lead or AI architect responsible for a multi-tenant RAG system where data sensitivity varies by user role. Required context includes a structured user entitlement manifest—typically a JSON object listing allowed document scopes, classification levels, or project memberships—and the original user query. This prompt is not a replacement for database-level access controls or row-level security. It is a defense-in-depth component that reduces the blast radius of a misconfigured retriever, not a primary authorization system. Do not use this prompt when the retrieval index is already partitioned per user or when entitlements are enforced at the storage layer with guaranteed isolation.

Before deploying this prompt, ensure you have a reliable entitlement source of truth and a mechanism to inject the rewritten query into your retrieval pipeline. The prompt works best when paired with a validation step that confirms the rewritten query contains only authorized scope references. If your entitlement model changes frequently, plan to version the manifest schema and test the prompt against stale or malformed manifests. In high-risk regulated environments, add a human review step for queries that touch the boundary of a user's clearance—this catches edge cases where the model misinterprets complex entitlement rules.

This template is the core instruction set you will send to the model. It forces the model to treat the user's access profile as a first-class constraint during query generation, not as an afterthought. The prompt instructs the model to produce a rewritten query and an explicit list of allowed and denied document scopes, making the entitlement decision auditable before any retrieval call is made. Use this template when you need to guarantee that a RAG pipeline never surfaces content from outside a user's clearance boundary, such as in legal document review, financial audit, or healthcare record retrieval.

textCopy
You are a secure query rewriter for a Retrieval-Augmented Generation system. Your job is to rewrite a user's natural language query so that it retrieves only documents the user is authorized to see. You must never generate a query that could access documents outside the user's entitlement scope.

## INPUTS
- User Query: [USER_QUERY]
- User Entitlements (JSON): [USER_ENTITLEMENTS]
- Available Document Scopes (JSON): [DOCUMENT_SCOPES]
- Output Schema: [OUTPUT_SCHEMA]

## INSTRUCTIONS
1. Parse the user's query to understand the information need.
2. Cross-reference the information need with the user's entitlements. Identify which document scopes the user is permitted to access and which are explicitly denied.
3. Rewrite the query to include explicit scope constraints. The rewritten query must only reference permitted scopes.
4. If the user's query implicitly or explicitly requests information from a denied scope, rewrite the query to exclude that scope and add a note to the `entitlement_violations` field.
5. If the user has no entitlements that can satisfy the query, set the rewritten query to `null` and explain why in the `block_reason` field.
6. Output the result as a valid JSON object matching the Output Schema.

## CONSTRAINTS
- Do not invent document scopes. Use only scopes from the provided `DOCUMENT_SCOPES` list.
- Do not assume a user has access to a scope unless it is explicitly listed in their entitlements.
- If a scope is not in the user's entitlements, treat it as denied.
- The rewritten query must be a standalone string suitable for a vector or keyword search engine.
- If the query is blocked, `rewritten_query` must be `null` and `block_reason` must be populated.

## OUTPUT SCHEMA
{
  "rewritten_query": "string | null",
  "allowed_scopes": ["string"],
  "denied_scopes": ["string"],
  "entitlement_violations": ["string"],
  "block_reason": "string | null"
}

Before sending this prompt to the model, replace every square-bracket placeholder with concrete data from your application. [USER_ENTITLEMENTS] should be a JSON object mapping scope identifiers to permission levels. [DOCUMENT_SCOPES] should be the complete list of valid scopes in your system, which prevents the model from hallucinating scope names. [OUTPUT_SCHEMA] can be replaced with your own schema if you need additional fields like confidence_score or audit_trail. After receiving the model's output, validate the JSON structure, confirm that every scope in allowed_scopes and denied_scopes exists in your system's scope registry, and log any entitlement_violations for security review. Never pass the rewritten_query directly to your retrieval engine without this validation step.

This prompt is not a standalone component; it is a security-critical gate that must be integrated into your retrieval pipeline before any vector or keyword search executes. The prompt accepts a user query and a structured entitlement payload, then produces a rewritten query with embedded access constraints. The application layer is responsible for supplying accurate, up-to-date entitlements and for enforcing the output constraints downstream. Never rely on the model alone to enforce access boundaries—the retrieval system must apply the generated filters as a hard constraint, and the application must verify that returned document IDs fall within the user's authorized scope.

Wire the prompt into a pre-retrieval middleware function that constructs the entitlement payload from your identity provider (e.g., OAuth scopes, LDAP groups, or a policy engine like OpenFGA or Cedar) and injects it into the [USER_ENTITLEMENTS] placeholder. The function should validate the model's output against a strict schema: a rewritten query string, an allow-list of document scopes or classification labels, an explicit deny-list, and an audit trail of any terms removed from the original query. Implement a retry loop with a maximum of two attempts if the output fails schema validation or if the generated allow-list contains scopes outside the user's entitlements. Log every rewrite attempt—including the original query, the entitlement payload hash, the rewritten query, and the filter clauses—to an immutable audit store. For regulated environments, route any query where the model removes more than 30% of the original terms or where the deny-list is non-empty to a human reviewer before retrieval proceeds.

Model choice matters here. Use a model with strong instruction-following and low hallucination rates on structured output tasks, such as Claude 3.5 Sonnet or GPT-4o, and set the temperature to 0 or near-zero to maximize deterministic enforcement of the entitlement schema. If you are using a local or air-gapped model, validate the output schema even more aggressively and consider a secondary validation prompt that checks whether the rewritten query would retrieve documents outside the user's clearance. The next step after implementing this harness is to build a regression test suite using the entitlement boundary enforcement test cases described in the companion evaluation section—run those tests on every prompt or model change before deployment.