Permission Boundary Enforcement Prompt for Query Generation

This prompt is designed for security engineering teams building retrieval-augmented generation (RAG) systems where different users have different data access scopes. The core job-to-be-done is to validate a generated or rewritten query against a user's explicit permission boundaries before it executes against a vector database, search index, or document store. The ideal user is an AI/ML engineer or platform developer who already has a working retrieval pipeline and a defined permission model (e.g., role-based access control, attribute-based access control, or entitlement lists) and needs a guardrail that prevents information leakage at the query level. The prompt takes a candidate query and a structured permission profile as input and produces a sanitized query with an audit trail of removed or rewritten terms.

Use this prompt when your retrieval system serves multiple tenants, departments, or clearance levels and a single index contains documents with heterogeneous access scopes. It is appropriate when you cannot rely solely on post-retrieval filtering because the cost of retrieving unauthorized document chunks is too high—either computationally, due to embedding lookups on irrelevant data, or from a compliance standpoint, where even the metadata of a restricted document should not be surfaced. The prompt is also valuable when you need an auditable record of query modifications for governance or debugging purposes. You should have a reliable, machine-readable permission profile available at inference time; the prompt cannot invent or infer permissions.

Do not use this prompt as your sole access control mechanism. It is a defense-in-depth layer, not a replacement for database-level access controls, row-level security, or post-retrieval authorization checks. It is also not suitable when the permission model is too complex to express in a compact text profile—if your user's access is defined by hundreds of dynamic rules, you should pre-compute a simplified scope representation before calling this prompt. Finally, avoid this prompt for low-risk, single-tenant applications where all users share the same data scope; the added latency and token cost are unnecessary. If you are unsure whether your permission model is stable enough to encode in a prompt, start with post-retrieval filtering and add this guardrail once your access patterns are well-understood.

This template is the core instruction set for a permission boundary enforcement step in a retrieval pipeline. It takes a proposed query and the user's explicit access scopes, then rewrites or rejects any query component that would attempt to retrieve documents outside those scopes. The output is a sanitized query and a structured audit log of removed or modified terms, making the enforcement decision explainable and reviewable.

textCopy
You are a permission boundary enforcement engine for a secure retrieval system. Your job is to validate a generated query against a user's explicit access scopes and produce a sanitized query that will only retrieve documents the user is authorized to see.

## INPUTS
[PROPOSED_QUERY]: The query generated by an upstream retrieval system before permission checks.
[USER_ACCESS_SCOPES]: A structured list of document scopes the user is permitted to access. Each scope includes a scope_type (e.g., 'department', 'project', 'classification', 'region') and allowed_values.
[USER_ROLE]: The user's organizational role for context.
[OUTPUT_SCHEMA]: A JSON schema the output must conform to.
[CONSTRAINTS]: Additional constraints such as maximum query length, forbidden term patterns, or required audit detail level.
[EXAMPLES]: Few-shot examples of correct sanitization and rejection decisions.
[RISK_LEVEL]: The sensitivity of the data domain ('standard', 'sensitive', 'regulated').

## INSTRUCTIONS
1. Parse [PROPOSED_QUERY] to identify all terms, phrases, filters, and entity references that imply a document scope.
2. Compare each identified scope against [USER_ACCESS_SCOPES].
3. For any scope component that falls outside the user's allowed scopes:
   - If [RISK_LEVEL] is 'standard', remove the unauthorized term and replace it with the narrowest authorized alternative if one exists.
   - If [RISK_LEVEL] is 'sensitive', remove the unauthorized term without replacement and flag it for review.
   - If [RISK_LEVEL] is 'regulated', reject the entire query and return an empty sanitized query with a full audit trail.
4. Reconstruct the query with only authorized scope components.
5. Produce an audit trail entry for every removed, replaced, or flagged term, including the original term, the reason for removal, and the action taken.
6. If the sanitized query becomes empty or semantically meaningless, set the query to null and flag for human review.
7. Output the result strictly according to [OUTPUT_SCHEMA].

## OUTPUT SCHEMA
{
  "sanitized_query": "string | null",
  "query_accepted": "boolean",
  "requires_review": "boolean",
  "audit_trail": [
    {
      "original_term": "string",
      "detected_scope": "string",
      "action": "removed | replaced | flagged | accepted",
      "replacement_term": "string | null",
      "reason": "string"
    }
  ],
  "rejection_reason": "string | null"
}

## EXAMPLES
[EXAMPLES]

## CONSTRAINTS
[CONSTRAINTS]

To adapt this template, replace the square-bracket placeholders with your application's concrete values. The [USER_ACCESS_SCOPES] should be populated from your identity and access management system at query time. The [OUTPUT_SCHEMA] field can be simplified or extended depending on your logging requirements. For high-risk domains, ensure [RISK_LEVEL] is set to 'regulated' and that a human review queue is configured to handle rejected queries. Before deploying, test the prompt against the adversarial boundary-probing cases described in the evaluation section of this playbook.

This prompt is a security guardrail, not a standalone feature. It must sit between the query generation step and the retrieval execution step in your RAG pipeline. The harness should treat the prompt's output as a structured security decision: a sanitized query plus an audit trail of removed or rewritten terms. Never pass the original user query directly to retrieval after this prompt runs; always use the sanitized output. The harness must also handle the case where the prompt rejects the entire query because every component violates permission boundaries—in that case, return an empty result set or an explicit access-denied response rather than falling back to the original query.

Wire the prompt into your application as a synchronous pre-retrieval step. The input payload must include the generated query, a structured permission profile (document scopes, clearance levels, department access, or tenant boundaries), and the user's identity for audit logging. Validate the model's output against a strict schema: a sanitized_query string, a removed_terms array with reasons, and a rejected boolean. If the output fails schema validation, retry once with a repair prompt that includes the validation error. If the retry also fails, log the failure, block retrieval, and return a safe fallback response. For high-security deployments, consider a secondary lightweight validation step that checks whether any removed terms appear in the sanitized query before allowing retrieval to proceed.

Log every enforcement decision with the user ID, original query, sanitized query, removed terms, and timestamp. This audit trail is critical for security reviews, compliance, and debugging false positives. When a query is partially rewritten, log the specific terms that were stripped and the permission boundary that triggered removal. If the prompt rejects a query entirely, escalate to a human review queue if the user's role or query context suggests the rejection may be a false positive. Avoid caching sanitized queries across users or sessions—permission boundaries are user-specific, and reusing a sanitized query for a different user would bypass the enforcement check entirely.