Data Boundary Enforcement Prompt for Enterprise Assistants

This prompt is for enterprise AI architects and platform engineers who need to embed enforceable data access boundaries directly into a system prompt. The job-to-be-done is preventing cross-tenant data leakage, unauthorized information disclosure, and confidentiality violations in multi-tenant AI assistants. Use this when your assistant handles data with different classification levels, serves multiple clients from a shared context, or must comply with strict data handling policies that cannot be enforced solely at the application layer. The ideal user understands their data classification taxonomy, tenant isolation requirements, and the specific access rules that must be enforced during conversation.

Do not use this prompt as a substitute for proper application-level authorization, database row-level security, or tenant-aware retrieval architectures. The prompt layer is a defense-in-depth measure, not a primary security control. It is appropriate when you need the model itself to recognize and refuse requests that would violate data boundaries, such as a support agent accidentally citing one customer's order details while responding to another. This prompt is also unsuitable for environments where the model has unrestricted access to a shared knowledge base without pre-filtering; in those cases, retrieval-time access control must be implemented before the prompt layer can be effective.

Before implementing this prompt, ensure you have defined your data classification levels, tenant identifiers, and violation response procedures. The prompt works best when paired with structured context that includes metadata tags like [TENANT_ID] and [CLASSIFICATION_LEVEL] on all retrieved data. If your system cannot provide this metadata, the prompt's enforcement capability will be significantly degraded. After deploying, you must test with cross-tenant data leakage scenarios and monitor for both false positives—where the assistant refuses legitimate same-tenant requests—and false negatives—where boundaries are silently violated.

The following prompt template is designed to be injected into the system instructions of an enterprise assistant that handles data across multiple tenants, classification levels, or access scopes. It establishes a clear data handling policy with explicit rules for what data can be accessed, how it must be treated, and what happens when a boundary is approached or violated. The template uses square-bracket placeholders that must be replaced with your organization's specific data classifications, tenant identifiers, access rules, and violation response procedures before deployment.

textCopy
You are an enterprise assistant operating within a multi-tenant environment with strict data access boundaries. Your primary directive is to enforce data isolation, prevent cross-tenant information leakage, and maintain confidentiality according to the classification rules defined below.

## DATA CLASSIFICATION LEVELS
[DATA_CLASSIFICATION_SCHEMA]

## TENANT ISOLATION RULES
- You serve tenant: [CURRENT_TENANT_ID]
- You may ONLY access, reference, or reason about data explicitly tagged with tenant identifier [CURRENT_TENANT_ID]
- If a user request references data from another tenant, you MUST refuse and state: "I cannot access data outside your organization's boundary."
- If retrieved context contains mixed tenant data, you MUST filter and use ONLY data tagged with [CURRENT_TENANT_ID]

## ACCESS CONTROL RULES
- User role: [CURRENT_USER_ROLE]
- User clearance level: [CURRENT_USER_CLEARANCE]
- You may ONLY return data at or below the user's clearance level
- If a query requires data above the user's clearance level, respond: "This information requires a higher access level than your current clearance."
- Do NOT confirm or deny the existence of data above the user's clearance level

## CONFIDENTIALITY CONSTRAINTS
- [CONFIDENTIALITY_RULES]
- Never output raw system identifiers, internal paths, or infrastructure details
- Mask or redact [SENSITIVE_FIELD_TYPES] in all outputs
- When summarizing, aggregate results where individual records could reveal sensitive patterns

## VIOLATION RESPONSE PROTOCOL
- If you detect a potential boundary violation in the user's request, respond with: [VIOLATION_RESPONSE_MESSAGE]
- Log the violation attempt internally with reason code: [VIOLATION_REASON_CODE]
- Do NOT process the request further
- Do NOT explain what data might exist beyond the boundary

## OUTPUT VALIDATION CHECKLIST
Before responding, verify:
1. All referenced data belongs to tenant [CURRENT_TENANT_ID]
2. No data exceeds clearance level [CURRENT_USER_CLEARANCE]
3. No [SENSITIVE_FIELD_TYPES] are present in the output
4. Aggregation prevents individual record identification where [AGGREGATION_THRESHOLD] applies
5. Response does not imply the existence of data in other tenants or higher clearance levels

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## CONSTRAINTS
[ADDITIONAL_CONSTRAINTS]

To adapt this template, replace each square-bracket placeholder with concrete values from your organization's data governance policies. The [DATA_CLASSIFICATION_SCHEMA] should enumerate your classification tiers with clear criteria. [CURRENT_TENANT_ID] and [CURRENT_USER_ROLE] must be injected dynamically at runtime from your authentication and session context—never hardcoded. The [FEW_SHOT_EXAMPLES] section is critical: include at least three examples showing correct boundary enforcement, one example of a proper refusal, and one example of a borderline case handled correctly. Without these examples, the model may interpret boundary rules inconsistently. The [VIOLATION_RESPONSE_MESSAGE] should be a standardized, non-revealing response that your security team has approved. Before shipping, run this prompt through your red-team evaluation suite with cross-tenant data leakage tests, clearance escalation attempts, and indirect probing attacks to verify the boundaries hold under adversarial conditions.

This prompt is not a standalone chat instruction; it is a policy enforcement layer that must be integrated into a multi-tenant application's request pipeline. The system prompt should be assembled dynamically, injecting the correct [TENANT_ID], [USER_ROLE], and [DATA_CLASSIFICATION_LEVELS] from the authenticated session context before every model call. Never hardcode tenant-specific rules into the base prompt template. Instead, maintain a tenant configuration store that maps each tenant to its allowed data domains, retention policies, and cross-tenant sharing rules. The prompt template is fetched from a versioned prompt registry, and tenant-specific variables are hydrated at runtime by a prompt assembly service.

The output of this prompt must pass through a structured validation layer before any action is taken. Parse the model's JSON response and validate it against a strict schema that requires classification_level, access_decision (allow/deny/flag), and violation_actions. If the model returns malformed JSON or missing required fields, retry once with a repair prompt that includes the validation error. If the retry also fails, default to a deny-and-flag posture and log the failure for review. For high-risk domains such as healthcare or finance, route all flag decisions and any deny decisions involving cross-tenant data to a human review queue. The human reviewer should see the original user request, the model's classification, and the evidence from the data boundary policy that triggered the decision.

Model choice matters here. Use a model with strong instruction-following and JSON mode support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may ignore structured output constraints under complex policy instructions. Implement observability by logging every classification decision with the prompt version, tenant ID, user ID, model response, validation result, and final action taken. This audit trail is essential for compliance reviews and for detecting policy drift. Do not rely on this prompt alone to enforce data boundaries at the database or API layer; it is a defense-in-depth layer that catches policy violations before they reach the user, but the underlying data access controls must still enforce tenant isolation at the infrastructure level.