Trade Secret and IP Sensitivity Scoring Prompt

This prompt is an ingress filter for AI middleware and data loss prevention (DLP) pipelines. Its job is to classify unstructured text—such as a user query, a document chunk, or an internal message—for trade secret and intellectual property sensitivity before that text reaches a general-purpose model, a vector database, or an unapproved processing queue. The primary users are IP legal teams defining protection policies, DLP engineers building automated scanning workflows, and security architects who need deterministic routing decisions. The prompt scores content across four categories: proprietary algorithms, source code, unreleased product details, and confidential business information. It outputs a tiered sensitivity score and a routing instruction that a downstream system can act on without further human interpretation.

Use this prompt when you need a pre-processing classification step that prevents protected IP from leaking into AI training data, third-party API calls, or unauthorized internal tools. It is designed for integration into a broader system: a middleware proxy that inspects prompts before they reach an LLM, a batch job that scans documents before ingestion into a knowledge base, or a DLP rule that triggers on specific sensitivity tiers. The prompt expects raw, unstructured text as input and returns a structured JSON classification. You should configure your application to read the routing_instruction field and enforce it—for example, by blocking the request, redirecting to an on-premises model, or quarantining the content for legal review. The prompt does not provide legal advice, nor does it replace a formal IP review process. It is a classification tool that reduces the surface area of accidental exposure.

Do not use this prompt as a standalone legal safeguard. It is not a substitute for data classification policies, access controls, or human review in high-stakes scenarios. The model may miss novel or obfuscated trade secret descriptions, and its confidence scores should be calibrated against your organization's risk tolerance. If you are handling content that is already marked as classified, regulated, or subject to legal hold, you should enforce those controls at the application layer before this prompt ever runs. For maximum safety, combine this prompt with a human review step for any content scored above a MEDIUM sensitivity tier, and log every classification decision for auditability. Start by running a batch evaluation against a labeled dataset of known IP-sensitive and benign documents to establish your own precision and recall baselines before deploying to production.

This section provides a copy-ready prompt template for the Trade Secret and IP Sensitivity Scoring Prompt. The template is designed to be dropped directly into an AI gateway, data loss prevention (DLP) pipeline, or a secure processing middleware. It instructs the model to act as a strict classifier, analyzing the provided content against a defined taxonomy of sensitive categories (proprietary algorithms, source code, unreleased product details, and confidential business information) and assigning a sensitivity tier that dictates how the data must be handled downstream. The prompt is structured to prevent the model from summarizing or reproducing the sensitive content itself, reducing the risk of exfiltration during the classification step.

The following template uses square-bracket placeholders for all dynamic inputs. Before deploying, replace [CONTENT] with the text to be classified. The optional [AUTHOR], [DEPARTMENT], [PROJECT], and [EXISTING_CLASSIFICATION] metadata fields provide additional context that can improve classification accuracy, especially for detecting unreleased product details or confidential business information. The [OUTPUT_SCHEMA] placeholder should be replaced with the strict JSON schema provided in the playbook's introduction, ensuring the model's output is machine-readable and can be parsed by a downstream routing engine.

textCopy
Classify the following content for trade secret and intellectual property sensitivity. Use the sensitivity taxonomy and output schema provided. Do not generate, reproduce, or summarize the content itself. Only output the classification result in strict JSON format.

SENSITIVITY TAXONOMY
- proprietary_algorithms: Describes or references unique algorithms, models, formulas, or computational methods that provide competitive advantage. Includes training procedures, optimization techniques, and novel architectures.
- source_code: Contains or references production source code, configuration files, build scripts, or infrastructure-as-code that is not publicly released under an open-source license.
- unreleased_product_details: Describes features, capabilities, roadmaps, specifications, or performance characteristics of products or services that have not been publicly announced or released.
- confidential_business_information: Contains strategic plans, financial projections, customer lists, pricing, contract terms, M&A activity, partnership negotiations, or other non-public business data.

SENSITIVITY TIERS
- tier_0_none: No trade secret or IP-sensitive content detected.
- tier_1_low: Contains general business information that is not public but would cause minimal harm if disclosed.
- tier_2_medium: Contains specific technical or business details that would advantage competitors if disclosed.
- tier_3_high: Contains core trade secrets, unreleased product specifications, or strategic business data that would cause material harm if disclosed.
- tier_4_critical: Contains crown-jewel IP, source code for core differentiating technology, or pre-announcement M&A/financial data that would cause severe competitive or legal harm if disclosed.

ROUTING INSTRUCTIONS
- tier_0_none: route to standard processing queue.
- tier_1_low: route to internal-only processing queue with access logging.
- tier_2_medium: route to restricted processing queue with encryption at rest and access control.
- tier_3_high: route to air-gapped or on-premises processing only; block cloud processing.
- tier_4_critical: block all automated processing; escalate to human legal/IP review immediately.

OUTPUT SCHEMA
[OUTPUT_SCHEMA]

CONTENT TO CLASSIFY
"""
[CONTENT]
"""

METADATA (if available)
Author: [AUTHOR]
Department: [DEPARTMENT]
Project: [PROJECT]
Existing Classification: [EXISTING_CLASSIFICATION]

To adapt this template for your environment, first integrate the [OUTPUT_SCHEMA] directly into the prompt to avoid external dependencies and ensure the model has the exact format contract. The evidence_fragment field in the schema is critical for auditability; it forces the model to cite the specific text that triggered a detection, enabling human reviewers to quickly validate or overturn the classification. For high-risk deployments, always set the temperature to 0 to maximize determinism and use a model that supports strict JSON mode or structured outputs. Finally, implement a post-processing validation layer that checks the output against the JSON schema and verifies that the routing_instruction is consistent with the overall_sensitivity_tier before the routing decision is executed.

Deploying the Trade Secret and IP Sensitivity Scoring Prompt in production requires a hardened application harness that treats the model output as untrusted input until validated. The core risk is that a misclassification—especially a false negative on tier_3_high or tier_4_critical content—can route proprietary source code, unreleased product specifications, or confidential business strategy to an external model or logging system, creating an immediate data breach. The harness must therefore enforce deterministic validation, auditability, and hard blocks before any downstream system receives the classified content.

Start by wrapping the prompt in a system message that explicitly instructs the model to never echo, summarize, or transform the input content; the only acceptable output is the JSON classification object. Implement a JSON schema validator on the raw model response that checks for required fields (sensitivity_tier, detected_categories, confidence_scores, routing_instruction) and rejects any response that fails validation. On the first validation failure, append the error message to a single retry request—do not loop beyond one retry to avoid latency spikes. Log every classification decision to an immutable audit store with the SHA-256 hash of the input, the output tier, per-category confidence scores, the routing instruction, the model version, and a timestamp. This log must never contain the raw input text; store only the hash to enable later verification without creating a secondary data leak surface.

For any output classified as tier_3_high or tier_4_critical, implement a hard application-layer block that prevents the associated content from being transmitted to any external API, cloud-hosted model, or logging pipeline that does not meet your required processing locality (e.g., on-premises or air-gapped environment). This block must be enforced in code, not in a prompt instruction, because prompt-level controls can be bypassed. Additionally, if the model returns a confidence score below 0.7 for any individual detected category, flag the entire classification result for human review regardless of the overall tier. Route these flagged items to a secure review queue with the input hash and the model's raw output, and do not release the content to any downstream system until a human reviewer confirms or overrides the classification.

Select a dedicated model endpoint with no conversation history enabled and temperature set to 0 to maximize output determinism. Avoid using a general-purpose chat endpoint where prior turns or system state could influence classification behavior. Finally, implement a dead-letter queue for any classification attempt that times out, returns a malformed response after the retry, or throws an exception. Unclassified content must never silently pass through to a default processing pipeline; the dead-letter queue ensures that failures are surfaced to operations teams for diagnosis rather than becoming invisible data leaks. Wire these guardrails together so that the classification path is: validate → classify → validate output → block or route → audit log, with human review and dead-letter queues as the only escape hatches.