Data Boundary Violation Detection Prompt

This prompt is for data platform engineers who need to detect and block requests that would access, process, or expose data outside permitted boundaries before any data operation executes. It sits in the critical path between a user or agent request and the data access layer, acting as a guardrail for tenant isolation, data residency, and classification-level enforcement. The ideal user is an engineer building a multi-tenant SaaS platform, a regulated data environment, or any system where a single cross-boundary data access can create a compliance incident. The required context includes a structured request object containing the user's tenant ID, requested data identifiers, target region, and the user's clearance level. Without this structured input, the prompt cannot make a reliable boundary decision.

Use this prompt when you need a structured, auditable violation alert that identifies the specific boundary crossed, the violating element, and a recommended action. It is designed to produce machine-readable output that your application can act on deterministically—blocking the request, quarantining it for review, or allowing it with an audit log entry. This is not a general safety classifier or a policy violation detector. It focuses narrowly on data boundaries: tenant, region, classification level, and legal jurisdiction over data. Do not use this prompt to enforce acceptable-use policies, detect abusive content, or classify user intent. Pair it with a separate policy violation prompt for those concerns. For example, if a user asks for 'all customer records' without specifying a tenant, this prompt should flag a missing tenant boundary, not a policy violation.

Before deploying, ensure your application layer can inject the required structured context—tenant ID, data location, classification tags—into the prompt's [INPUT] placeholder. If your system cannot reliably provide this context at runtime, the prompt will produce unreliable or overly permissive results. Start by testing against a golden dataset of known boundary violations and legitimate cross-boundary requests to calibrate the prompt's behavior. Avoid using this prompt as the sole enforcement mechanism in high-risk environments; always pair it with application-level access controls and an audit trail that logs every boundary decision for later review.

This prompt template is designed to be pasted directly into your system prompt or as a structured user message. It instructs the model to analyze a given request against a configurable set of data boundaries and produce a structured violation alert. The core logic is to compare the data requested with the permissions of the requesting context, not to judge the intent of the user.

textCopy
You are a Data Boundary Enforcement Guard. Your only job is to analyze a user's data request against a strict set of data access policies. You must determine if the request would access, process, or expose data outside of permitted boundaries.

## INPUT DATA
- **User Request:** [USER_REQUEST]
- **Requesting Context:** [REQUESTING_CONTEXT] (e.g., tenant_id, user_role, region, clearance_level)

## DATA BOUNDARY POLICIES
Evaluate the request against the following policies. A violation occurs if the request matches any policy.

[POLICY_BLOCK]

## OUTPUT SCHEMA
You must respond with a single, valid JSON object conforming to this schema. Do not include any other text.

{
  "violation_detected": boolean, // true if any policy is violated
  "violations": [
    {
      "policy_id": string, // The ID of the violated policy from the POLICY_BLOCK
      "boundary_type": string, // e.g., "tenant_isolation", "data_residency", "classification_level"
      "description": string, // A precise, one-sentence explanation of the violation
      "requested_data": string, // The specific data field or resource that is out of bounds
      "current_boundary": string, // The boundary that applies to the requesting context
      "requested_boundary": string // The boundary the request is attempting to cross
    }
  ]
}

## CONSTRAINTS
- Base your decision ONLY on the provided policies and input data.
- If the request is ambiguous, err on the side of caution and flag a violation.
- If no policies are violated, return an empty violations array.

To adapt this template, replace the placeholders with your application's live values. [USER_REQUEST] is the raw user input. [REQUESTING_CONTEXT] is a structured string containing the user's session metadata. The most critical part is [POLICY_BLOCK], which should be a clear, declarative list of your data access rules. For example: POLICY_1 (tenant_isolation): Users in tenant X cannot access data owned by tenant Y. or POLICY_2 (data_residency): Data classified as 'EU-Citizen' cannot be processed by services in region 'US-East'. After pasting, test the prompt with both clear violations and edge-case requests that are close to the boundary to ensure the model interprets your policies correctly. Always log the full JSON output for audit trails.

The Data Boundary Violation Detection prompt is not a standalone chat interaction—it is a guard function that must sit inline within a data access or query processing pipeline. Before any data retrieval, cross-tenant operation, or cross-region data movement executes, the user's request and the proposed data scope are assembled into the prompt template. The model's structured output determines whether the pipeline proceeds, blocks with an explanation, or escalates for human review. This means the harness must enforce a hard block on violation_detected: true responses and must never allow the model's refusal to be overridden by downstream code without an explicit override audit event.

Wire the prompt into your application as a pre-execution check with the following contract: inputs include the user's original request, the requested data scope (tenant IDs, regions, classification levels), and the user's authorized boundaries from your identity and access management system. Output must conform to a strict JSON schema with fields violation_detected (boolean), boundary_crossed (string enum: tenant, region, classification, none), violation_detail (string), and recommended_action (string enum: block, review, allow). Validate this schema immediately after model response. If parsing fails, retry once with a repair prompt that includes the raw output and the expected schema. If the retry also fails, default to block and log the failure for operations review.

Logging and audit trails are non-negotiable for this use case. Every invocation must record: the user ID, the requested scope, the authorized scope, the model's raw output, the parsed verdict, and the pipeline action taken (blocked, allowed, escalated). For multi-tenant systems, ensure logs are written to a tenant-isolated audit store so that one tenant's violation patterns are not visible to another. For data residency enforcement, the prompt harness itself must run in the same region as the data it is protecting—do not send tenant-scope metadata across region boundaries to a central model endpoint unless that endpoint is deployed regionally. Consider using smaller, fine-tuned models deployed per region if latency or data residency rules prohibit cross-region calls.

Testing this prompt requires a dedicated eval dataset that includes: legitimate cross-tenant requests that should be blocked, same-tenant requests that should be allowed, edge cases where classification levels differ within the same tenant, and adversarial inputs attempting to obfuscate tenant identifiers. Measure both false-positive rate (blocking legitimate access) and false-negative rate (allowing boundary violations). False negatives are the higher-severity failure mode and should trigger immediate pipeline shutdown if detected in production. Run these evals in your CI/CD pipeline on every prompt change, and maintain a golden dataset of known boundary scenarios that must pass before deployment. For high-risk data platforms, add a human review queue for any recommended_action: review output, and ensure the review interface displays the full prompt context, the model's reasoning, and the specific boundary crossed.