Permission-Aware Index Selection Prompt

This prompt is designed for enterprise RAG teams managing access-controlled indexes where different users, roles, or tenants have permission to see different subsets of documents. The core job-to-be-done is routing a user query to the correct retrieval index based on the user's authorization profile, preventing both over-permission (retrieving documents the user should not see) and under-permission (failing to retrieve documents the user is entitled to access). The ideal user is an orchestration engineer or platform developer building a retrieval dispatch layer that must enforce data access policies before any retrieval call is made. Required context includes the user's role, clearance level, tenant scope, or group memberships, plus a mapping of available indexes to their access requirements.

Do not use this prompt when all users share the same access scope, when authorization is handled entirely at the application layer after retrieval, or when the index landscape is flat and unpartitioned. This prompt is also inappropriate for public-facing systems with no access controls, as the permission-checking overhead adds latency and complexity without benefit. If your system uses a single index with document-level filtering, prefer a metadata filter generation prompt instead. The prompt assumes that index-to-permission mappings are known and stable; if permissions change frequently during a session, you must invalidate cached routing decisions and re-evaluate.

Before deploying this prompt, ensure you have defined clear eval checks for both over-permission failures (the model routes a query to an index the user cannot access) and under-permission failures (the model fails to route to an index the user is authorized to use, causing missed results). Human review is required for any routing decision where the model's confidence falls below a defined threshold, or where the user's permission set is ambiguous or conflicting. Wire this prompt into a retrieval dispatch layer that logs every routing decision with the user's permission context, the selected index, and the confidence score, so that access violations can be audited and traced.

This prompt acts as a permission-aware dispatch layer for enterprise RAG systems. It takes a user query, a list of available indexes with their access policies, and the user's current authorization context, then returns a single index selection decision with a confidence score and a justification. The template is designed to be wrapped in application code that enforces the decision—the model selects, the application gates. Never rely on the model alone to enforce access control; the prompt output should always be validated against a source-of-truth permissions store before retrieval executes.

textCopy
You are an index selection router for an enterprise retrieval system. Your job is to choose the single most appropriate search index for a user query, respecting the user's permissions, role, tenant scope, and data clearance level.

## INPUT

User Query: [USER_QUERY]

User Authorization Context:
- User ID: [USER_ID]
- Roles: [USER_ROLES]
- Tenant IDs: [USER_TENANT_IDS]
- Clearance Level: [USER_CLEARANCE_LEVEL]
- Explicit Index Permissions: [USER_INDEX_PERMISSIONS]

Available Indexes (with access policies):
[AVAILABLE_INDEXES]

## TASK

1. Eliminate any index the user is not authorized to access based on role, tenant scope, clearance level, or explicit permissions.
2. From the remaining authorized indexes, select the single index best suited to answer the user query.
3. Consider: content domain match, query type fit (factual, procedural, comparative, etc.), freshness requirements, and entity coverage.
4. If no authorized index can reasonably answer the query, select "none" and explain why.
5. If multiple authorized indexes could work, choose the most specific one and note the alternatives.

## CONSTRAINTS

- Never select an index the user lacks permission to access, even if it would be the best semantic match.
- Prefer tenant-scoped indexes over global indexes when the user belongs to a specific tenant.
- If the query contains PII or sensitive terms, prefer indexes with higher clearance requirements.
- Do not fabricate index names or capabilities not listed in the available indexes.

## OUTPUT SCHEMA

Return a JSON object with these fields:
{
  "selected_index": string,        // index ID or "none"
  "confidence": number,            // 0.0 to 1.0
  "authorized_indexes_considered": [string],  // indexes that passed permission check
  "rejected_indexes": [             // indexes eliminated with reasons
    {
      "index": string,
      "reason": string
    }
  ],
  "justification": string,         // why this index was selected
  "alternative_indexes": [string], // runner-up authorized indexes
  "requires_human_review": boolean  // true if confidence < 0.7 or ambiguity detected
}

To adapt this prompt, replace the square-bracket placeholders with data from your application's authorization service and index registry. The [AVAILABLE_INDEXES] placeholder should be populated with a structured list of index objects, each containing at minimum an index_id, description, content_domain, required_roles, required_clearance_level, and tenant_scope field. If your system uses attribute-based access control (ABAC), extend the user authorization context with the relevant attributes. For high-security deployments, add a [RISK_LEVEL] parameter that adjusts the confidence threshold for requires_human_review. Always log the full prompt input and output for audit trails, and never cache index selection decisions across users with different permission sets.

This prompt operates as a pre-retrieval gate in your RAG pipeline. Before any vector or keyword search executes, the application must resolve the user's identity, roles, group memberships, and tenant scope from your auth layer (e.g., OAuth2 claims, JWT, session store). These resolved permissions become the [USER_PERMISSIONS] input. The prompt itself should run as a lightweight classification call—ideally on a fast, inexpensive model—because its job is to output a structured index selection decision, not to generate fluent text. The output is a JSON object containing the selected index name, a confidence score, and a fallback chain. Your application parses this JSON and uses it to route the retrieval request to the correct index backend.

Validation and enforcement happen in the application layer, not in the prompt. After the model returns an index selection, validate that the chosen index exists in your configured index registry and that the user's resolved permissions actually grant access to it. This is a hard server-side check: never trust the model's output as the sole access control decision. If the model selects an index the user cannot access, log the mismatch as a potential over-permission attempt, fall back to the highest-confidence permitted index from the fallback chain, and flag the event for review. Conversely, if the model fails to select an index the user should be able to access (under-permission), log it and attempt the fallback chain. Both failure modes should increment metrics you monitor: permission_override_count, fallback_triggered_count, and index_selection_confidence_below_threshold.

Retry logic should be minimal at the prompt level. If the model returns malformed JSON or a confidence score below your configured threshold (start with 0.7 and tune based on production data), do not blindly retry with the same inputs. Instead, route to a conservative default index scoped to the user's minimum guaranteed permissions, or escalate to a human review queue if the query context is high-risk. For multi-tenant SaaS applications, the [TENANT_SCOPE] input must be injected server-side from the authenticated session—never from the user's message—to prevent cross-tenant index leakage. Log every routing decision with: user_id, resolved_permissions_hash, query_fingerprint, selected_index, confidence, fallback_used, and timestamp. This audit trail is essential for compliance reviews and debugging permission boundary errors in production.