Data Sharing Agreement Enforcement Prompt for Third-Party APIs

This prompt is designed for vendor risk, procurement, and security engineering teams who need to automate the enforcement of data-sharing agreements (DSAs) before an agent dispatches data to a third-party API. It acts as a pre-flight compliance gate: given the fields an agent intends to send and the approved DSA scope, the prompt produces a structured allow/block decision with field-level justification. Use this when your agent workflow involves external API calls that carry customer data, PII, or proprietary business information, and you need auditable evidence that each outbound payload stays within the contracted data categories. This is not a replacement for legal review or contract management; it is an operational enforcement layer that prevents accidental over-sharing in automated tool-use pipelines.

The ideal user is an engineer or operator embedding this prompt into an agent gateway or middleware layer that intercepts tool calls before they leave your trust boundary. You should have a machine-readable representation of your DSA—typically a JSON schema or structured policy object defining permitted data categories, prohibited fields, and any conditional allowances. The prompt expects two primary inputs: the proposed outbound payload (or a schema of its fields) and the approved DSA scope. It returns a structured verdict that your application can act on programmatically, such as blocking the call, redacting specific fields, or routing to a human approval queue. For high-risk domains like healthcare or finance, always pair this prompt with a human review step for blocked or edge-case payloads, and log every decision for audit trails.

Do not use this prompt as your sole compliance control when the DSA terms are ambiguous, frequently changing, or require legal interpretation of novel data types. It is designed for operational enforcement of clearly defined, machine-readable data categories. If your agreements are still in negotiation or exist only as unstructured text, invest in a contract extraction and normalization step first. Similarly, avoid using this prompt for real-time, latency-sensitive streaming data where the per-call overhead of an LLM gate is unacceptable; in those cases, compile the DSA rules into deterministic, rule-based middleware and reserve this prompt for offline auditing or sampling. Once you've validated the prompt against your agreement taxonomy, proceed to wire it into your tool-calling harness with structured logging and eval checks for field-to-agreement mapping accuracy.

This prompt acts as a pre-flight enforcement gate for any agent tool call that transmits data to a third-party API. It compares the specific data fields the agent intends to send against a structured Data Sharing Agreement (DSA) scope, blocking any field category that falls outside the approved contract. The prompt is designed to be inserted into an agent's tool-dispatch middleware, receiving the proposed API payload and the relevant DSA clauses as input, and returning a structured allow/block/flag decision. It does not make legal determinations; it enforces a pre-defined, machine-readable policy.

textCopy
You are a Data Sharing Agreement enforcement validator. Your task is to compare the fields an agent intends to send to a third-party API against the approved data-sharing scope defined in a contract. You must block any data category not explicitly permitted.

INPUT:
- PROPOSED_PAYLOAD: [PROPOSED_PAYLOAD]
- DSA_SCOPE: [DSA_SCOPE]
- DATA_CLASSIFICATION_TAXONOMY: [DATA_CLASSIFICATION_TAXONOMY]

INSTRUCTIONS:
1. Parse the PROPOSED_PAYLOAD and extract every distinct data field path (e.g., `user.profile.email`, `transaction.amount`).
2. For each field path, map it to a single category from the DATA_CLASSIFICATION_TAXONOMY. If a field cannot be mapped with high confidence, classify it as `UNKNOWN`.
3. Compare the mapped category for each field against the permitted categories listed in the DSA_SCOPE.
4. For each field, produce a verdict:
   - `ALLOW`: The field's category is explicitly listed in the DSA_SCOPE.
   - `BLOCK`: The field's category is not listed in the DSA_SCOPE, or the field is classified as `UNKNOWN`.
   - `FLAG`: The field's category is conditionally permitted, but requires additional context or human approval as defined in the DSA_SCOPE's `conditional_approval` rules.
5. If any field has a `BLOCK` verdict, the overall `dispatch_decision` must be `BLOCK`.
6. If no fields are `BLOCK`, but one or more are `FLAG`, the overall `dispatch_decision` must be `HUMAN_REVIEW`.
7. Only if all fields are `ALLOW` can the `dispatch_decision` be `ALLOW`.

OUTPUT_SCHEMA:
{
  "dispatch_decision": "ALLOW" | "BLOCK" | "HUMAN_REVIEW",
  "field_verdicts": [
    {
      "field_path": "string",
      "mapped_category": "string",
      "verdict": "ALLOW" | "BLOCK" | "FLAG",
      "rationale": "string"
    }
  ],
  "blocked_categories_summary": ["string"],
  "requires_human_review": boolean
}

CONSTRAINTS:
- Do not transmit the PROPOSED_PAYLOAD outside of this analysis.
- If the DSA_SCOPE is empty or unparseable, the dispatch_decision must be `BLOCK`.
- Base your mapping strictly on the DATA_CLASSIFICATION_TAXONOMY. Do not infer categories.

To adapt this template, you must provide three structured inputs. PROPOSED_PAYLOAD is the full JSON body the agent intends to send. DSA_SCOPE is a machine-readable version of your agreement, listing permitted_categories and any conditional_approval rules. DATA_CLASSIFICATION_TAXONOMY is your internal schema mapping field paths or patterns to data categories like PII, PHI, ANONYMOUS_USAGE_STATS, or INTERNAL_IDENTIFIER. The prompt's strength lies in its strict default-deny posture: any field that cannot be confidently mapped to a permitted category is blocked. This prevents data leakage from schema drift or incomplete taxonomies. For high-risk integrations, ensure the HUMAN_REVIEW path triggers a notification to a compliance officer before any data is dispatched.

This prompt is not a standalone chat interaction; it is a policy enforcement point that must sit inline between the agent's tool-calling logic and the outbound API request. The recommended architecture is a pre-dispatch validation middleware inside the agent gateway. Before any third-party API call is serialized and sent over the wire, the gateway intercepts the prepared request payload, extracts the set of fields the agent intends to transmit, and passes both the field list and the relevant Data Sharing Agreement (DSA) scope to this prompt. The prompt returns a structured compliance verdict—either allowed, blocked, or review_required—along with a per-field mapping to the DSA clauses that authorize or prohibit transmission. The gateway must honor the verdict: blocked fields are stripped or the entire call is aborted, review_required calls are queued for human approval, and allowed calls proceed with an audit log entry recording the prompt's decision and the DSA version consulted.

To make this reliable in production, implement a validation wrapper around the prompt's JSON output. The expected schema includes a verdict enum (allowed | blocked | review_required), a field_decisions array mapping each proposed field to an agreement_clause_id and a decision enum (in_scope | out_of_scope | ambiguous), and a rationale string for auditability. Use a JSON schema validator (such as ajv in Node.js or pydantic in Python) to reject malformed responses before they influence the dispatch decision. If validation fails, retry once with a stricter output constraint appended to the prompt; if the retry also fails, default to blocked and log the failure for investigation. This fail-closed posture prevents a broken prompt from silently allowing unapproved data sharing.

For high-throughput agent systems, consider caching DSA scopes at the gateway layer to avoid re-evaluating the same agreement for every API call. The DSA scope—the list of approved data categories and fields—should be stored as a versioned artifact in a policy registry, not embedded in every prompt instance. The prompt receives only the agreement ID and the proposed fields; the gateway resolves the agreement scope from the registry and injects it as the [APPROVED_DATA_SCOPE] placeholder. This keeps the prompt token-efficient and ensures that agreement updates take effect immediately without prompt changes. When an agreement version changes, invalidate the cache and log any in-flight requests that were evaluated against the stale version. For regulated environments, pair this prompt with the Audit Trail Generation Prompt for Sensitive Tool Calls to produce a non-repudiable record of every enforcement decision. Never deploy this prompt without human review for ambiguous verdicts—those are the cases where the field-to-clause mapping is uncertain, and an automated allowed decision creates compliance risk.