Data Exfiltration via Tool Output Refusal Prompt

This playbook is for agent platform engineers and security architects who need to prevent sensitive data from leaking through tool-call responses. When an agent calls a database, API, or file system, the raw output can contain PII, secrets, or proprietary business logic. This prompt acts as a post-tool-call inspection layer that decides whether to surface, sanitize, or refuse the output before it reaches the user. Use it when you control the agent loop but cannot guarantee that every upstream tool performs its own output redaction.

The ideal user is an engineer building an agent harness where the model orchestrates tool calls and returns results to an end user or downstream system. You have access to the tool response before it is rendered, and you can insert an inspection step into the agent loop. Required context includes the raw tool output, the tool's declared purpose, the user's authorization level, and any applicable data-handling policies. The prompt is designed to be called synchronously after every tool invocation, with a strict timeout to avoid adding unacceptable latency to the user experience.

Do not use this prompt as a replacement for data-layer access controls, column-level encryption, or tokenization. It is a defense-in-depth guard for the model's output surface, not a substitute for proper data governance. If the tool itself can be modified, prefer output redaction at the tool level. If the data is highly regulated (HIPAA, PCI DSS, ITAR), this prompt should be paired with human review for any output flagged as borderline. The prompt also cannot inspect binary blobs, encrypted payloads, or outputs that exceed the model's context window—those require pre-processing outside the LLM layer.

This prompt template is designed to sit in the post-tool-call inspection step of your agent's execution loop. After a tool returns data—whether from a database query, a file read, an API response, or a retrieved document—this instruction evaluates the raw output for sensitive content before the model surfaces it to the user. The goal is to prevent accidental data exfiltration through tool outputs, which is one of the most common and severe production incident classes in agentic AI systems. The template uses square-bracket placeholders so you can adapt it to your specific data classification policy, tool surface, and risk tolerance without rewriting the core logic.

textCopy
You are a tool-output security inspector. Your job is to examine the raw output returned by a tool before it is shown to the user and decide whether that output contains sensitive, confidential, or disallowed data.

## TOOL OUTPUT TO INSPECT
[TOOL_OUTPUT]

## TOOL NAME AND CONTEXT
Tool called: [TOOL_NAME]
User request that triggered the tool: [USER_REQUEST]

## SENSITIVE DATA POLICY
Apply the following policy when inspecting the tool output:
[POLICY_RULES]

## INSPECTION INSTRUCTIONS
1. Scan the entire tool output for data that matches the policy above.
2. If the output is clean, respond with the exact tool output unchanged.
3. If the output contains sensitive data that can be safely redacted, produce a sanitized version with sensitive fields replaced by [REDACTED] or appropriate placeholder tokens. Preserve the structure and non-sensitive content.
4. If the output contains sensitive data that cannot be safely redacted without losing essential meaning, or if the volume of sensitive data makes redaction impractical, refuse to surface the output. Use the refusal format below.
5. If you are uncertain whether data qualifies as sensitive under the policy, err on the side of refusal.

## REFUSAL FORMAT
When you must refuse, respond with ONLY this JSON structure and no other text:
{
  "action": "refuse",
  "reason": "[BRIEF_REASON]",
  "policy_rule": "[SPECIFIC_POLICY_VIOLATED]",
  "user_message": "[SAFE_USER-FACING_MESSAGE]"
}

## SANITIZATION FORMAT
When you redact, wrap the sanitized output in:
[SANITIZED_OUTPUT_START]
[sanitized content here]
[SANITIZED_OUTPUT_END]

## CONSTRAINTS
- Do not echo the sensitive data in your reasoning or refusal message.
- Do not describe what the sensitive data looks like.
- Do not confirm or deny the presence of specific records, individuals, or values beyond what the policy requires.
- If the tool output is empty or an error, pass it through unchanged.

Adaptation guidance: Replace [POLICY_RULES] with your organization's concrete data classification rules—for example, 'PII includes names, email addresses, phone numbers, and government IDs' or 'Source code from the internal proprietary-repo must not be reproduced verbatim.' Replace [TOOL_OUTPUT] with the actual raw tool response in your agent loop. The [TOOL_NAME] and [USER_REQUEST] placeholders provide context that helps the inspector distinguish between legitimate data access and potential exfiltration attempts. The refusal JSON structure is designed to be machine-parseable so your application layer can trigger logging, alerting, or human review workflows when a refusal occurs. For high-risk domains such as healthcare or finance, add a [RISK_LEVEL] placeholder and adjust the inspection instructions to require stricter redaction or mandatory human review above a threshold.

This prompt is not a standalone chat instruction. It is a security middleware component that sits between tool execution and the user-facing response. In an agent architecture, every tool call—whether it's a SQL query, a file read, an API call, or a browser action—produces raw output. That output must pass through a sanitization gate before the model can summarize it or relay it to the user. This prompt is that gate. It receives the raw tool output and the original user request, and it decides whether to pass the output through, redact sensitive fields, or refuse entirely. The implementation harness must ensure this prompt runs synchronously and unconditionally after every tool call, with no bypass path.

Wire this into your agent loop as a post-tool-call hook. After the agent invokes a tool and receives its response, intercept that response before it enters the model's context window. Construct the prompt by injecting the raw tool output into [TOOL_OUTPUT], the tool name into [TOOL_NAME], and the user's original request into [USER_REQUEST]. The model's response should be a structured JSON object with fields: decision (one of pass, redact, refuse), sanitized_output (if redact), refusal_message (if refuse), and risk_flags (an array of detected concerns). Validate this JSON strictly. If decision is refuse, do not append the tool output to the model's context; instead, surface the refusal_message to the user or escalate to a human reviewer. If decision is redact, replace the raw tool output with sanitized_output before continuing. If decision is pass, proceed normally. Log every decision with the tool name, risk flags, and a truncated hash of the output for audit trails.

For production resilience, implement a fail-closed default. If the sanitization prompt fails, times out, or returns malformed JSON, treat it as a refuse decision. Never default to pass on error. Use a fast, inexpensive model for this gate (e.g., a small fine-tuned classifier or a lightweight LLM call) to keep latency low, but ensure the model is capable of structured output. Add retries with exponential backoff for transient failures, but cap retries at 2-3 attempts to avoid blocking the user. For high-risk domains like healthcare or finance, route all redact decisions to a human review queue before the sanitized output is shown to the user. Finally, build an eval harness that tests this prompt against known leakage patterns: SQL result sets containing PII columns, file contents with embedded secrets, API responses with tokens in headers or bodies, and tool outputs that include system prompt fragments. Run these evals on every prompt change and model upgrade.