Confidentiality Boundary Detection Prompt for Enterprise Copilots

This prompt is designed for enterprise AI engineers building copilots that operate across organizational boundaries. It classifies user inputs that could inadvertently expose confidential information from one department, team, or tenant to another. Use this prompt as a pre-processing guard before any retrieval, generation, or tool execution step. It is not a replacement for data access controls, encryption, or tenant isolation at the infrastructure layer. It is a classification layer that detects intent to cross confidentiality boundaries in the prompt itself.

Deploy this prompt when your copilot has access to data or tools scoped to multiple organizational units and a user's natural language request could cause information leakage. For example, a user in the Sales department might ask, 'Summarize the Q4 compensation details for the VP of Engineering,' which would require accessing HR data outside their authorized scope. The prompt classifies this as a boundary_crossing with the specific concern compensation_data_across_departments. Conversely, a request like 'Show me the Q4 sales forecast for my territory' would be classified as within_boundary because it stays within the user's authorized domain. Do not use this prompt when your system operates within a single, flat trust domain where all users have equivalent access, or when you have already implemented strict, attribute-based access control that prevents cross-boundary data retrieval at the API layer.

After classification, wire the output into your routing logic: within_boundary requests proceed to retrieval and generation; boundary_crossing requests should trigger a refusal response explaining the boundary limitation; ambiguous requests should route to a clarification prompt asking the user to specify their authorized context. Avoid using this prompt as your sole defense—combine it with data-layer authorization and audit logging. Regularly evaluate for over-classification that blocks legitimate cross-team collaboration, such as a product manager legitimately requesting aggregated, non-confidential usage data from an engineering system.

This prompt template is designed to be embedded in your enterprise copilot's guardrail layer, sitting between user input and model processing. It classifies whether a request could expose confidential information across organizational boundaries—such as between departments, tenants, or access tiers—and produces a structured verdict that your application can act on before any data retrieval or generation occurs. The template uses square-bracket placeholders that you must replace with your organization's specific boundary definitions, data classification taxonomy, and routing rules.

textCopy
You are a confidentiality boundary detection classifier for an enterprise copilot system. Your job is to analyze user requests and determine whether they could expose confidential information across organizational boundaries.

## ORGANIZATIONAL BOUNDARIES
Confidentiality boundaries in this system include:
[BOUNDARY_DEFINITIONS]

Example boundary definitions:
- Department boundaries: Engineering, Finance, HR, Legal, Executive
- Tenant boundaries: Customer A data vs. Customer B data
- Classification tiers: Public, Internal, Confidential, Restricted
- Geographic boundaries: EU resident data vs. non-EU data
- Partner boundaries: Internal-only vs. partner-shareable

## DATA CLASSIFICATION TAXONOMY
Confidential data types to detect:
[DATA_CLASSIFICATION_TAXONOMY]

Example taxonomy:
- PII: names, emails, phone numbers, addresses, government IDs
- Financial: salary, revenue, budget, pricing, deal terms
- Strategic: roadmaps, M&A, organizational changes, unreleased products
- Legal: contracts, litigation, regulatory findings, attorney-client privileged
- HR: performance reviews, disciplinary actions, health information
- Security: credentials, keys, vulnerability details, incident reports

## INPUT
User request: [USER_REQUEST]

User context:
- Department: [USER_DEPARTMENT]
- Access tier: [USER_ACCESS_TIER]
- Authentication level: [AUTH_LEVEL]
- Current session scope: [SESSION_SCOPE]

## TASK
Analyze the user request and determine:
1. Whether the request explicitly or implicitly asks for confidential information
2. Which organizational boundary would be crossed if the request were fulfilled
3. What specific data classification types are implicated
4. Whether the request is legitimate cross-team work or a boundary violation

## CLASSIFICATION RULES
- A request is a violation if it asks for data the user's access tier cannot access
- A request is a violation if it asks for data from another department without appropriate cross-department authorization
- A request is NOT a violation if it asks about publicly available information or the user's own department data
- A request is NOT a violation if it involves legitimate cross-functional workflows with proper authorization
- When uncertain, classify as REVIEW rather than ALLOW or BLOCK

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "verdict": "ALLOW" | "BLOCK" | "REVIEW",
  "confidence": 0.0-1.0,
  "boundary_concern": "string describing which boundary is at risk, or null if ALLOW",
  "data_types_implicated": ["list of data classification types"],
  "reasoning": "brief explanation of the classification decision",
  "suggested_action": "specific action for the system to take"
}

## CONSTRAINTS
[CONSTRAINTS]

Example constraints:
- Do not process or repeat any confidential information in your reasoning
- If the user request itself contains apparent confidential data, flag as REVIEW immediately
- Prioritize precision over recall: false BLOCK is better than false ALLOW
- For REVIEW verdicts, include specific questions the human reviewer should answer
- Never assume cross-department authorization without explicit evidence

## EXAMPLES
[EXAMPLES]

Example few-shot demonstrations:

Input: "Show me the Q4 revenue numbers for the entire company"
User department: Engineering
Access tier: Internal
Verdict: BLOCK
Confidence: 0.92
Boundary concern: Cross-department financial data access
Data types implicated: ["Financial"]
Reasoning: Engineering user requesting company-wide financial data without demonstrated need-to-know. Revenue data is Finance-department confidential.

Input: "What's the status of the Johnson acquisition deal?"
User department: Corporate Development
Access tier: Confidential
Verdict: ALLOW
Confidence: 0.88
Boundary concern: null
Data types implicated: ["Strategic"]
Reasoning: Corporate Development user with Confidential access tier requesting deal status within their authorized scope.

Input: "Can you summarize the engineering team's Q3 OKRs?"
User department: Product Management
Access tier: Internal
Verdict: ALLOW
Confidence: 0.85
Boundary concern: null
Data types implicated: []
Reasoning: Product Management has legitimate cross-functional need for engineering OKRs. Internal access tier is sufficient for OKR-level information.

After copying this template, replace each square-bracket placeholder with your organization's specific values. The [BOUNDARY_DEFINITIONS] and [DATA_CLASSIFICATION_TAXONOMY] sections are the most critical to customize—they define what your system considers confidential and where the boundaries lie. The [EXAMPLES] section should include 3-5 few-shot demonstrations that reflect your actual boundary scenarios, including both legitimate cross-team workflows and genuine violations. The [CONSTRAINTS] section should encode your organization's risk tolerance: if you prefer false positives (over-blocking) to false negatives (leaking data), state that explicitly. Before deploying, run this prompt against a golden test set that includes edge cases like ambiguous cross-department requests, users with multiple department affiliations, and requests that contain confidential data in the prompt itself. For high-risk deployments, always include a human review path for REVIEW verdicts and log all BLOCK decisions for audit purposes.

Integrating this prompt into a production copilot requires treating it as a pre-processing guard, not an optional check. The prompt should execute synchronously before any user input reaches the main generative model or any tool that could retrieve or act on data. The output is a structured classification that your application code must parse and act on deterministically. Do not rely on the model's refusal text alone—the JSON verdict (boundary_concern, risk_level, rationale) is the contract your routing logic consumes. A risk_level of high or critical should trigger an immediate block with a canned, policy-approved user-facing message, never the model's raw refusal string, which could leak information about your detection logic.

Wire the prompt into your request pipeline with a strict schema validator. The expected output is a JSON object with fields like boundary_concern (enum: cross_tenant, cross_department, privileged_escalation, none), risk_level (enum: low, medium, high, critical), rationale (string), and redacted_input (string). Use a JSON Schema validator in your application layer to confirm the model's output conforms before acting on it. If validation fails, retry once with a repair prompt that includes the raw output and the schema error. If the retry also fails, escalate to a human moderator and log the raw input and output for analysis. For latency-sensitive applications, run this check in parallel with other pre-processing steps, but ensure the main model invocation is gated on a successful, low-risk classification.

Logging and observability are critical for tuning and audit. Log the risk_level, boundary_concern, a hash of the user input, and the model's rationale to your observability platform. Do not log the raw user input if it may contain the very confidential data you are trying to protect. Use the redacted_input field for traceability. Set up alerts on a rising rate of critical classifications, which could indicate an attack or a misconfigured policy. Regularly review a sample of medium risk classifications to check for over-classification that blocks legitimate cross-team workflows. This feedback loop is essential for maintaining user trust and system utility.

Model choice matters. Use a fast, instruction-tuned model for this classification task to minimize latency overhead. A smaller model (e.g., a quantized 7B-13B parameter model) is often sufficient and keeps costs low. Avoid using the same large, general-purpose model that handles the main conversation, as this creates a conflict of interest and a single point of failure. For high-compliance environments, consider running this prompt on a private, locally-deployed model to ensure that the input data never leaves your boundary, even for classification. The prompt template's [CONFIDENTIALITY_POLICY] placeholder should be populated from a central policy service, not hardcoded, to ensure updates propagate instantly.

Finally, build a human review queue for ambiguous cases. When risk_level is medium or the rationale indicates uncertainty, route the interaction to a review interface where a human can see the redacted_input, the model's classification, and decide to allow, block, or redact. This human feedback should be logged and used to create few-shot examples for future prompt iterations, directly improving the model's accuracy on your specific organizational boundaries. Never allow a critical classification to proceed without human intervention, and ensure your application's block page is generic, helpful, and does not confirm the nature of the detected boundary concern to the end user.