Internal Document Leakage Prevention Prompt

This prompt is designed for security engineers and platform architects who need to prevent proprietary internal documents from being summarized, quoted verbatim, or otherwise exposed through an AI model's output. The core job-to-be-done is not just to refuse a direct request like 'show me the secret roadmap,' but to enforce a policy boundary that blocks indirect extraction attempts, such as asking the model to 'rephrase the document I just uploaded' or 'list the key points from the internal wiki page you have access to.' The ideal user is someone integrating this prompt into a Retrieval-Augmented Generation (RAG) system, a document Q&A bot, or an internal copilot where the model has access to a corpus of confidential files. The required context includes a clear definition of what constitutes an 'internal document' (e.g., marked 'Confidential,' located in a specific directory, or containing a specific metadata tag) and a pre-processing pipeline that can attach this classification to the retrieved chunks before they reach the model.

You should not use this prompt as a standalone safety net if the underlying application layer lacks proper access controls. If a user can directly retrieve a sensitive document through a vector search because of missing ACLs, the model's refusal becomes a speed bump, not a security boundary. This prompt is also the wrong tool for redacting PII or financial data from documents that are otherwise safe to share; for that, use a dedicated PII Redaction or Data Masking prompt. Furthermore, do not rely on this prompt to defend against a determined adversary who controls the entire prompt context, such as in a direct model API attack. It is most effective when the user interacts through a constrained application interface where the system prompt is not directly editable. The primary failure mode this prompt addresses is the model's default helpfulness, which often leads it to comply with 'summarize this' requests without evaluating the sensitivity of the source material.

Before implementing this prompt, ensure you have a test suite of known internal documents and a set of adversarial extraction queries. Your evaluation must check for both verbatim text reproduction and the leakage of sensitive facts that have been paraphrased. If the model refuses to summarize a public press release because it shares a keyword with an internal document, your prompt is over-refusing and needs calibration. The next step after reading this section is to review the prompt template and adapt the [INTERNAL_DOCUMENT_DEFINITION] and [POLICY_STATEMENT] placeholders to match your organization's specific data classification taxonomy.

This prompt template is designed to be placed in the system instructions of an AI assistant that has access to internal or proprietary documents. Its primary job is to prevent the model from reproducing verbatim text, exposing confidential facts, or summarizing sensitive material in a way that leaks protected information. The template uses square-bracket placeholders so you can adapt it to your organization's specific document types, classification levels, and acceptable-use policies without rewriting the core logic.

codeCopy
You are an internal document assistant with strict data protection rules. Your primary directive is to prevent the leakage of confidential, proprietary, or classified information from [DOCUMENT_SOURCE].

## Classification Levels
Treat all content from [DOCUMENT_SOURCE] according to these classification levels:
[CLASSIFICATION_LEVELS]

## Allowed Actions
- [ALLOWED_ACTION_1]
- [ALLOWED_ACTION_2]

## Prohibited Actions
You must refuse to perform any of the following actions on documents from [DOCUMENT_SOURCE]:
- Reproduce verbatim text of more than [MAX_QUOTE_LENGTH] consecutive words.
- Expose [SENSITIVE_ENTITY_TYPES] such as names, financial figures, or personal data.
- Summarize content classified as [RESTRICTED_CLASSIFICATION_LEVEL] or higher.
- Reveal the existence or structure of [RESTRICTED_DOCUMENT_TYPES].
- Answer questions that require aggregating data across [AGGREGATION_BOUNDARY].

## Refusal Protocol
When a request violates these rules, respond with:
"I'm unable to fulfill this request because it would expose [POLICY_VIOLATION_TYPE]. [SAFE_ALTERNATIVE_INSTRUCTION]"

## Safe Summarization Rules
When summarizing allowed documents:
1. Abstract concepts without using specific [SENSITIVE_ENTITY_TYPES].
2. Do not preserve the original document's structure or ordering.
3. Use general categories instead of specific names (e.g., "a client" instead of "Acme Corp").
4. If uncertain whether a detail is safe to include, omit it.

## Input
[DOCUMENT_CONTEXT]

## User Request
[USER_REQUEST]

To adapt this template, start by defining your classification levels and restricted document types in the [CLASSIFICATION_LEVELS] and [RESTRICTED_DOCUMENT_TYPES] placeholders. These should map directly to your organization's data governance policy. Next, specify the exact entity types that must never appear in outputs under [SENSITIVE_ENTITY_TYPES]—this typically includes personal names, project code names, financial figures, and internal URLs. Set [MAX_QUOTE_LENGTH] to a low threshold (5-10 words) to prevent verbatim reproduction while still allowing brief, necessary references. The [SAFE_ALTERNATIVE_INSTRUCTION] placeholder is critical for user experience: it should guide the user toward a reformulated request that the system can safely fulfill, such as "Try asking for a general description of the process without specific client details." Before deploying, run this prompt through an eval harness that includes test cases for verbatim extraction, sensitive entity exposure, and boundary-pushing summarization requests.

This prompt is not a standalone safety net; it is a gate that must be wired into a deterministic application harness. The model's refusal is probabilistic, so the surrounding code must enforce hard constraints. The harness should treat the model output as a recommendation that requires post-processing: if the output contains a refusal marker, block the response; if it contains a summary, run it through a verbatim-overlap detector against the source document before surfacing it to the user. The prompt alone cannot guarantee that a future model version will not leak a confidential sentence.

Implement the harness as a three-stage pipeline. Stage 1: Pre-screening. Before the prompt runs, check the user's authorization level and the document's classification label. If the user lacks access or the document is tagged CONFIDENTIAL or INTERNAL, route to a hard refusal without invoking the model. Stage 2: Model invocation with structured output. Call the model with the prompt template and require a JSON response containing a decision field (BLOCK, SUMMARIZE, or REDACT) and a content field. Use response_format: { type: 'json_object' } or equivalent to enforce schema compliance. Set temperature=0 to minimize creative variation. Stage 3: Post-validation. If decision is SUMMARIZE or REDACT, run the content through a substring-matching algorithm (e.g., longest common subsequence) against the source document. If any sequence longer than 5 consecutive words matches verbatim, block the output and log the incident. Additionally, scan the output with a named-entity recognition model for PII, financial data, or internal project codenames. Any hit triggers a block.

For retry logic, implement a single retry with a modified prompt that includes the validation failure reason. For example: The previous response contained verbatim text from the source document. Regenerate the summary without reproducing any sequence of 5 or more consecutive words from the original. If the retry also fails validation, escalate to a human review queue and return a safe fallback message to the user: This document cannot be summarized due to confidentiality constraints. Do not implement more than one retry; repeated failures indicate either a prompt design flaw or a document that is too dense with sensitive phrasing to summarize safely.

Logging is critical for audit and improvement. Log every invocation with: the user ID, document ID, classification label, model decision, validation result, and whether the output was surfaced or blocked. Do not log the full document content or the generated summary in plaintext; use hash-based identifiers for the content and store the actual text in an access-controlled audit store. This separation prevents the logging system itself from becoming a leakage vector. For model choice, prefer models with strong instruction-following and low hallucination rates on structured output tasks. Test across at least two model families to ensure the refusal behavior is not model-specific.

Finally, integrate this harness into your CI/CD pipeline with a regression test suite. Maintain a golden dataset of 50+ confidential document excerpts paired with expected outcomes: hard blocks, safe summaries, and redacted versions. Run these tests on every prompt or model change. Measure two key metrics: leakage recall (did any test case produce verbatim text or sensitive entities?) and over-refusal rate (did the system block a document that should have been summarizable?). A leakage recall above 0% is a release blocker. An over-refusal rate above 10% warrants prompt tuning. Never ship a leakage prevention prompt without automated validation gates.