Role-Based Data Filtering Prompt for Multi-Tenant Systems

This prompt is designed for AI platform engineers and enterprise architects building multi-tenant AI applications. It acts as a pre-inference filter that receives a fully assembled prompt context and a user's role definition, then produces a sanitized version of the context that excludes any information the user is not authorized to see. Use this when your application serves multiple tenants or user tiers from a shared knowledge base, and you cannot rely solely on upstream retrieval filters to enforce data boundaries. The prompt is not a replacement for database-level access controls or row-level security. It is a defense-in-depth layer that catches authorization gaps before sensitive data reaches the model.

In practice, you would wire this prompt into your inference pipeline after context assembly but before the final model call. For example, if a retrieval system pulls documents from a shared vector store, this prompt acts as a second gate: given a user with role tenant_b_viewer and a context containing documents tagged tenant_a, tenant_b, and public, the prompt should return only the tenant_b and public content. The prompt expects a structured input containing the user's role definition (including allowed tenants, data classifications, and explicit denials) alongside the assembled context. It outputs a sanitized context block and a compliance report listing what was removed and why. You should validate the output by checking that no removed content appears in the sanitized context and that the compliance report matches your authorization rules.

Do not use this prompt as the sole enforcement mechanism for regulatory compliance. Always combine it with application-layer authorization, audit logging, and human review for high-risk domains. The prompt operates on text and cannot enforce cryptographic access controls. It is also subject to model failure modes: a sufficiently complex or adversarial context might cause the model to miss a sensitive passage. For regulated data, implement a post-sanitization verification step that scans the output for known sensitive patterns before it reaches the model. Start by testing this prompt against a golden dataset of contexts with known authorization boundaries, measuring both precision (no authorized content removed) and recall (no unauthorized content retained).

This template is the core instruction set for a role-based data filtering prompt. It is designed to be inserted into your prompt assembly pipeline after user authentication and data retrieval but before the final inference call. The prompt instructs the model to act as a strict data filter, removing any information from the provided context that the specified user role is not authorized to see. Use this when you have a multi-tenant system where different users have different data access levels, and you need to sanitize context before it reaches the model to prevent privilege escalation or data leakage. Do not use this for simple public/private binary splits; a deterministic access control list (ACL) check in application code is faster and cheaper for that case. This prompt is for complex, unstructured context where authorization boundaries depend on semantic understanding of the content.

textCopy
You are a strict data access filter for a multi-tenant enterprise system. Your only job is to remove unauthorized information from the provided context.

## USER ROLE AND PERMISSIONS
The current user has the following role and explicit data access permissions:
- Role: [USER_ROLE]
- Authorized Data Scopes: [AUTHORIZED_SCOPES]
- Explicitly Denied Data Scopes: [DENIED_SCOPES]

## FILTERING RULES
1. Read the entire [CONTEXT] block below. It contains information that may span multiple tenants, projects, or sensitivity levels.
2. Remove any sentence, paragraph, bullet point, table row, or code block that contains information the user is not authorized to see based on their role and scopes.
3. If a piece of information is explicitly within [AUTHORIZED_SCOPES], keep it.
4. If a piece of information falls within [DENIED_SCOPES] or is not explicitly authorized, remove it entirely.
5. Do not summarize, paraphrase, or alter the remaining content. Keep the exact wording of authorized information.
6. If an entire section is unauthorized, remove the section header and all its content.
7. If removing information creates a broken sentence or orphaned reference, remove the entire sentence to maintain readability.
8. Do not add any commentary, explanations, or metadata about what was removed.
9. Do not reveal the existence of redacted information through phrasing or structure.

## CONTEXT TO FILTER
[CONTEXT]

## OUTPUT INSTRUCTIONS
Return ONLY the filtered context. The output must be valid [OUTPUT_FORMAT] and conform to this schema:
[OUTPUT_SCHEMA]

If the entire context is unauthorized, return an empty result according to the schema.

Adaptation guidance: Replace [USER_ROLE] with a string like "project_alpha_viewer" or "auditor_read_only". Populate [AUTHORIZED_SCOPES] and [DENIED_SCOPES] with lists derived from your identity and access management (IAM) system, such as ["project:alpha", "doc_type:design"] and ["project:beta", "doc_type:financial"]. The [CONTEXT] placeholder should receive the fully assembled context that would have been sent to the model, including retrieved documents, conversation history, and tool outputs. Set [OUTPUT_FORMAT] to JSON, Markdown, or plain text depending on your downstream parser. Define [OUTPUT_SCHEMA] as a concrete schema, for example: {"filtered_context": "string", "retained_section_count": "integer"}. Before deploying, test this prompt against a golden dataset of mixed-authorization contexts and verify that no unauthorized data survives filtering. For high-risk domains such as healthcare or finance, always route the filtered output to a human review queue before it is used in downstream inference or displayed to the user.

This prompt is not a standalone service; it is a pre-inference gate that must execute before any user or application prompt reaches the model. The harness should intercept the fully assembled prompt context—including retrieved documents, conversation history, and tool outputs—and pass it through this filter with the user's role and data access level as runtime parameters. The output is a sanitized prompt that excludes any information the user is not authorized to see, plus a structured audit record of what was removed and why. This gate should be placed immediately after context assembly and before the model API call, with a hard block on proceeding if the filter fails or times out.

Validation and Retry Logic: The filter prompt must return a valid JSON object with a filtered_prompt string and a removed_segments array. Implement a JSON schema validator in your application layer that checks for required fields, correct types, and non-empty filtered_prompt. If validation fails, retry once with the same input and a stronger instruction to return valid JSON. If the second attempt fails, escalate to a human review queue and block the inference request. Log every validation failure with the user ID, role, and a hash of the original prompt for audit purposes. Never fall back to sending the unfiltered prompt.

Model Choice and Latency Budget: This gate adds latency to every request, so choose a model that balances speed and accuracy. A fast, instruction-tuned model like GPT-4o-mini or Claude 3 Haiku is appropriate for most deployments. Set a strict timeout (e.g., 2 seconds) and a token budget (e.g., 4,000 output tokens) to prevent the gate from becoming a bottleneck. For high-throughput systems, consider batching multiple filter requests or using a dedicated, low-latency deployment. Tool use and RAG are not required for this prompt; it operates on the assembled text alone. However, if your system uses dynamic role definitions stored in a database, retrieve the user's permissions and inject them into the [USER_ROLE] and [ACCESS_LEVEL] placeholders before calling the filter.

Logging and Audit Trail: Every invocation must produce an audit log entry containing: a unique request ID, the user's tenant and role, a hash of the pre-filter prompt, a hash of the post-filter prompt, the list of removed segments with their categories, and a timestamp. This log is essential for compliance reviews, debugging privilege escalation attempts, and demonstrating that data boundaries were enforced. Do not log the raw prompt content itself unless your logging infrastructure is classified at the same sensitivity level as the data. Store audit logs in a write-once, append-only store with access restricted to security and compliance personnel.

What to Avoid: Do not use this prompt as a post-generation check on model outputs—it is designed for input filtering only. Do not rely on it to catch PII or secrets; pair it with a dedicated PII redaction prompt from the Sensitive Data Redaction pillar for defense in depth. Do not skip the validation step; a malformed JSON response from the filter must be treated as a failure, not a pass. Finally, never cache filtered prompts across users or sessions, as this creates a cross-tenant data leakage vector.