Cross-Tool Data Leakage Prevention Prompt

This prompt is for security engineers and platform operators who need to prevent sensitive data from flowing between tools with different trust levels in an agent workflow. It acts as a guard, classifying the output of a high-sensitivity tool and blocking its transfer to the input of a lower-trust tool. Use this when your agent has access to both a PII-laden customer database and a public-facing summarization API, or when an internal document store feeds a code generation tool. The prompt is an in-context enforcement layer that catches logical data flow violations before they happen, inserted between tool calls in a multi-step agent execution.

This prompt is not a replacement for network-level controls or data loss prevention (DLP) software. It does not encrypt data at rest, scan network packets, or enforce operating system permissions. Instead, it operates at the application layer, inspecting the semantic content of tool outputs and making a classification decision before that content is passed to the next tool's input. The ideal user is someone who already has infrastructure controls in place but needs an additional, context-aware enforcement point that understands the meaning of the data flowing through the agent's reasoning loop. You should deploy this prompt when you have a clear mapping of tool sensitivity levels, a defined data classification taxonomy, and a known set of downstream tools that must not receive data above a certain classification threshold.

Do not use this prompt as your sole defense against data exfiltration. It is a logical guard, not a cryptographic one. If an attacker compromises the agent's execution environment or the model itself is adversarial, this prompt can be bypassed. It is also not suitable for real-time streaming data where per-message classification latency would be prohibitive. Before implementing, ensure you have defined your tool trust tiers, documented which data classes are prohibited from crossing which boundaries, and established a logging mechanism to capture denial events for audit. The next section provides the copy-ready prompt template you will adapt to your specific tool topology and classification rules.

This prompt acts as a gate between two tool calls. Before passing output from a source tool into the input of a destination tool, the prompt evaluates the sensitivity classification of the source data against the trust level of the destination tool. If the data is too sensitive for the destination, the prompt blocks the transfer and generates a denial log entry instead of forwarding the data. Use this as a middleware call in your agent orchestration layer, not as a one-off chat instruction.

textCopy
You are a data leakage prevention gate. Your job is to prevent sensitive data from flowing between tools with different trust levels.

SOURCE TOOL: [SOURCE_TOOL_NAME]
SOURCE TOOL TRUST LEVEL: [SOURCE_TRUST_LEVEL]
SOURCE TOOL OUTPUT: [SOURCE_OUTPUT]

DESTINATION TOOL: [DESTINATION_TOOL_NAME]
DESTINATION TOOL TRUST LEVEL: [DESTINATION_TRUST_LEVEL]

SENSITIVITY CLASSIFICATION RULES:
- PII: Any personally identifiable information including names, emails, phone numbers, addresses, SSNs, government IDs, IP addresses, device IDs.
- SECRETS: API keys, tokens, passwords, connection strings, private keys, certificates, credentials of any kind.
- INTERNAL: Internal system paths, hostnames, database names, table schemas, error stack traces, configuration values, internal URLs.
- CONFIDENTIAL: Business data marked confidential, financial figures, customer lists, proprietary algorithms, unreleased product details.
- PUBLIC: Data safe for external consumption with no sensitivity constraints.

TRANSFER RULES:
- Data classified as PII or SECRETS may NEVER be transferred to any destination with a trust level lower than HIGH.
- Data classified as INTERNAL or CONFIDENTIAL may only be transferred to destinations with trust level MEDIUM or HIGH.
- Data classified as PUBLIC may be transferred to any destination.
- If the destination trust level is UNKNOWN, treat it as LOW and block all transfers except PUBLIC data.

OUTPUT SCHEMA:
Return a JSON object with exactly these fields:
{
  "decision": "ALLOW" | "BLOCK",
  "sensitivity_classification": "PII" | "SECRETS" | "INTERNAL" | "CONFIDENTIAL" | "PUBLIC",
  "detected_sensitive_fields": ["list of specific field names or data types found"],
  "block_reason": "explanation if blocked, null if allowed",
  "sanitized_output": "the source output with sensitive fields redacted as [REDACTED], or null if blocked entirely",
  "audit_log_entry": "timestamped summary of decision for compliance records"
}

CONSTRAINTS:
- Never output the raw source data if the decision is BLOCK.
- If the decision is ALLOW, the sanitized_output field must still redact any PII or SECRETS found.
- Do not invent sensitivity classifications. Only use the five listed.
- If uncertain about classification, default to the higher sensitivity level and BLOCK.

Adapt this template by adjusting the sensitivity classification rules to match your organization's data handling policy. Replace the five classification levels with your internal taxonomy if needed. The trust level comparison logic should map to your tool inventory: assign every registered tool a trust level at registration time, and pass those levels into the prompt as variables. For high-throughput pipelines, cache the classification results per source-output hash to avoid re-classifying identical payloads. Wire the BLOCK decision to your alerting system so security engineers can review blocked transfers within your incident response SLA.

This prompt is designed to sit between tool execution and context assembly. In practice, you run it as a post-invocation filter—after a tool returns data but before that data is injected into the agent's working context or passed as input to another tool. The harness calls the classification prompt with the tool output, the source tool's declared sensitivity level, and the target tool's trust tier. The prompt returns a structured verdict: ALLOW, BLOCK, or REDACT. Your application code must enforce that verdict, not merely log it. If the verdict is BLOCK, the harness should inject a sanitized placeholder (e.g., [DATA BLOCKED: sensitivity mismatch]) into the agent context and write a structured denial record to your audit log. If REDACT, apply the returned redaction map before forwarding the data.

Validation and enforcement are critical because the model can hallucinate a permissive verdict. Implement a post-response validator that checks: (1) the verdict field is exactly one of the three allowed enum values, (2) a BLOCK verdict includes a non-empty block_reason and policy_reference, (3) a REDACT verdict includes a valid redaction_map with field paths that exist in the original output, and (4) the sensitivity_classification matches one of your predefined tiers. If validation fails, default to BLOCK and log the validation error. Never fall open. For high-throughput pipelines, cache classification results for identical (tool_output_hash, source_sensitivity, target_trust) tuples with a short TTL to reduce latency and cost, but invalidate the cache when sensitivity policies change.

Model choice and retries matter here. This is a classification task with a structured output schema, so use a fast, cheaper model (e.g., GPT-4o-mini, Claude Haiku) with response_format set to json_schema or the equivalent structured output mode. Set temperature=0 to minimize verdict drift. Implement a single retry on validation failure with the validation error message appended to the prompt as [PREVIOUS_VALIDATION_ERROR]. If the retry also fails validation, block the transfer and escalate to the on-call channel. Wire the denial log into your existing observability stack—every BLOCK event should generate a metric increment and an optional alert if the block rate exceeds a threshold. Do not rely on the prompt alone for security; it is one layer in a defense-in-depth strategy that should also include tool-level IAM policies, network segmentation, and egress filtering.