Confidentiality Agreement Compliance Check Prompt

This prompt is designed for legal, compliance, and security operations teams who need to programmatically check whether a proposed AI-generated output, agent action, or data disclosure would violate an existing confidentiality agreement (NDA). The core job-to-be-done is to reduce the manual review burden by having an AI system perform a first-pass compliance analysis, flagging potential breaches before a human reviewer signs off. The ideal user is an AI platform architect or compliance engineer embedding this check into a product workflow, such as a copilot that drafts external communications or an agent that shares data with third-party tools.

To use this prompt effectively, you must provide the full text of the governing NDA as [CONTRACT_TERMS] and the exact proposed disclosure or action as [PROPOSED_DISCLOSURE]. The prompt is most reliable when the NDA terms are well-structured, with clearly defined 'Confidential Information,' exclusions, and duration clauses. It is not a replacement for legal advice. Do not use this prompt for real-time, high-volume triage without a human-in-the-loop review stage. It is also unsuitable for contracts with highly ambiguous or contradictory terms where a model's interpretation could be dangerously wrong.

Before integrating this prompt into a production harness, you must define clear evaluation criteria. Common failure modes include the model missing duration-based restrictions (e.g., a 3-year term that has expired), misinterpreting the scope of excluded information, or failing to flag a disclosure that is technically compliant but violates the spirit of the agreement. Your next step should be to build a golden test set of NDA clauses and proposed disclosures with known violation labels, then run this prompt against that set to calibrate its precision and recall before shipping.

This section provides the core prompt template for the Confidentiality Agreement Compliance Check. It is designed to be copied directly into your prompt management system, IDE, or orchestration layer. The template uses square-bracket placeholders for all dynamic inputs, ensuring a clean separation between the static instruction logic and the variable data that changes per request. Before integrating, map each placeholder to a reliable data source in your application—never hardcode sensitive agreement text or disclosure content into the prompt itself.

textCopy
You are a legal compliance reviewer. Your task is to check a proposed disclosure against the terms of a confidentiality agreement and determine whether the disclosure would violate any clause.

# INPUTS

## CONFIDENTIALITY AGREEMENT
[AGREEMENT_TEXT]

## PROPOSED DISCLOSURE
[DISCLOSURE_TEXT]

## DISCLOSURE CONTEXT
- Recipient: [RECIPIENT_NAME]
- Disclosure Date: [DISCLOSURE_DATE]
- Disclosure Purpose: [DISCLOSURE_PURPOSE]

# CONSTRAINTS
- Only flag violations that are clearly supported by the agreement text.
- If a clause is ambiguous, note the ambiguity and recommend human review.
- Do not invent obligations not present in the agreement.
- Respect temporal limits: if the agreement has expired or a specific clause has a duration that has lapsed, treat that clause as inactive.
- Treat any information explicitly defined as "Confidential Information" in the agreement as protected.

# OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "overall_assessment": "COMPLIANT" | "VIOLATION" | "AMBIGUOUS",
  "findings": [
    {
      "clause_reference": "string (section number or identifier)",
      "clause_summary": "string (brief summary of the relevant clause)",
      "assessment": "COMPLIANT" | "VIOLATION" | "AMBIGUOUS",
      "rationale": "string (explanation of why the disclosure does or does not comply)",
      "suggested_remediation": "string | null (if VIOLATION, suggest a compliant alternative)"
    }
  ],
  "requires_human_review": true | false,
  "human_review_reason": "string | null (if review is required, explain why)"
}

# INSTRUCTIONS
1. Parse the confidentiality agreement to identify all active obligations, definitions, exclusions, and duration clauses.
2. Compare the proposed disclosure against each relevant obligation.
3. For each finding, cite the specific clause and explain your reasoning.
4. If the disclosure would violate a clause, suggest a compliant alternative when possible.
5. If any clause is ambiguous or requires legal interpretation, set requires_human_review to true and explain why.
6. If the overall assessment is VIOLATION, include at least one finding with a remediation suggestion.

To adapt this template, replace each square-bracket placeholder with data from your application context. For [AGREEMENT_TEXT], use the full text of the signed confidentiality agreement, not a summary. For [DISCLOSURE_TEXT], include the exact wording the user or agent intends to share. The [RECIPIENT_NAME], [DISCLOSURE_DATE], and [DISCLOSURE_PURPOSE] fields provide essential context for evaluating scope and permitted-purpose clauses. If your use case involves checking disclosures against multiple agreements simultaneously, extend the template with an array of agreement objects rather than concatenating them into a single text block. Always validate the output JSON against the schema before surfacing results to users or triggering downstream actions—malformed JSON or missing fields can cause silent failures in automated compliance pipelines.

This prompt is designed to be integrated into a legal or compliance review pipeline, not used as a standalone chat interface. The primary integration pattern is an API-based review step that intercepts proposed AI-generated content or agent actions before they are sent to an external party. The application should call the model with the prompt template, parse the structured output, and use the violation_flag field to gate the next action: block, quarantine for human review, or release with suggested modifications.

The implementation harness must enforce strict output validation before any downstream decision is made. After receiving the model response, validate that the JSON conforms to the expected schema, including required fields like violation_flag (boolean), violating_clauses (array of strings), and compliant_alternatives (array of strings). If parsing fails, implement a retry loop with a maximum of two additional attempts, feeding the raw output and the schema error back into the model. If validation still fails after retries, the system must escalate to a human review queue and log the full prompt and raw response for diagnosis. Never default to 'no violation' on a parsing failure.

For high-stakes deployments, the harness should include a confidence threshold check. Instruct the model to include a confidence_score (0.0 to 1.0) in the output. If the score falls below a configurable threshold (e.g., 0.85), the item is automatically routed for human review even if no violation is flagged. This prevents borderline cases from being auto-approved. Additionally, log every decision—including the NDA reference version, the proposed text, the model's reasoning, and the final human or automated decision—to an immutable audit log. This log serves as evidence of the compliance check process for internal governance and external audits. Choose a model with strong legal reasoning capabilities and a large context window to accommodate lengthy NDA documents, and ensure the model is deployed in a tenant-isolated environment to prevent cross-client data leakage.