Tool Call Redaction for Sensitive Data Prompt Template

This prompt is designed for privacy engineers and AI operations teams who need to share agent tool call logs with external auditors, lower-trust environments, or internal teams without exposing sensitive data. The core job-to-be-done is transforming a raw, potentially dangerous log entry into a structured, redacted record that is safe for distribution while preserving enough detail for debugging and compliance review. The ideal user is someone preparing an evidence packet for a SOC 2 audit, sharing a trace with a vendor's support team, or giving a sanitized log to a development team that does not have production data access. The required context is a raw tool call log entry and a clearly defined redaction policy that specifies which fields to target—such as PII, secrets, or business-sensitive parameters—and the rules for masking or removing them.

You should use this prompt when you need a post-hoc, auditable redaction workflow that produces a detailed audit trail explaining what was removed, why, and under which policy rule. This is not a real-time sanitization guard for live agent execution; do not use it to intercept or block tool calls in flight. It is also not a replacement for a data loss prevention (DLP) system or a cryptographic log integrity solution, though its output can complement both. The prompt works best on structured or semi-structured log entries where sensitive fields are identifiable by key name, pattern, or explicit policy rules. If your logs are entirely unstructured free text, you will need a pre-processing step to extract fields before redaction, or you risk inconsistent results. The output includes a redaction_audit array that makes the redaction decisions transparent and reviewable, which is essential for compliance evidence.

Before using this prompt, ensure you have a versioned redaction policy document that the model can reference. The policy should define entity types (e.g., EMAIL, SECRET_KEY, CUSTOMER_ID), the action to take (e.g., REDACT, HASH, MASK_LAST_4), and a justification string that will appear in the audit trail. If your policy changes, update the prompt's policy input and version the prompt template itself. After generating a redacted record, always run a validation check to confirm that no policy-defined entity type appears in plaintext in the redacted output. For high-risk compliance workflows, a human reviewer should sign off on the audit trail before the redacted log is shared externally. Finally, treat the redacted log as sensitive by default—it still contains operational patterns and timing data that may be valuable to an attacker—and apply appropriate access controls.

This prompt template is designed to be pasted directly into your LLM interface. It accepts a raw tool call log and a redaction policy, then returns a structured, redacted log where PII, secrets, and business-sensitive data have been removed. The output includes a redaction_audit field for each redacted entry, documenting the field, the redaction method, and the policy rule that triggered it. This is essential for preparing logs for external review, lower-trust environments, or compliance archiving where the original sensitive data must not be present.

textCopy
You are a privacy-preserving log redaction engine. Your task is to process a raw agent tool call log and apply a redaction policy to produce a sanitized version suitable for [TARGET_AUDIENCE_OR_ENVIRONMENT].

**INPUT**
- Raw Tool Call Log: [RAW_TOOL_CALL_LOG]
- Redaction Policy: [REDACTION_POLICY_RULES]

**REDACTION POLICY RULES**
The redaction policy is a set of rules that define what to redact and how. Each rule specifies:
- `field_pattern`: A regex or JSONPath expression to match sensitive fields.
- `sensitivity_type`: The category of sensitive data (e.g., `PII`, `SECRET`, `BUSINESS_SENSITIVE`).
- `redaction_method`: The method to use (e.g., `REPLACE_WITH_PLACEHOLDER`, `HASH`, `MASK_PARTIAL`, `REMOVE_FIELD`).
- `placeholder` (optional): The text to use if the method is `REPLACE_WITH_PLACEHOLDER`.

**OUTPUT_SCHEMA**
You must return a valid JSON object with the following structure:
{
  "redacted_log": [
    {
      "tool_call_id": "string",
      "timestamp": "string (ISO 8601)",
      "tool_name": "string",
      "arguments": {},
      "response": {}
    }
  ],
  "redaction_audit": [
    {
      "tool_call_id": "string",
      "field_path": "string",
      "sensitivity_type": "string",
      "redaction_method": "string",
      "policy_rule_id": "string"
    }
  ],
  "summary": {
    "total_tool_calls": "integer",
    "total_redactions": "integer",
    "redactions_by_type": {
      "PII": "integer",
      "SECRET": "integer",
      "BUSINESS_SENSITIVE": "integer"
    }
  }
}

**CONSTRAINTS**
- Do not modify the structure of the original log entries; only redact the values of matching fields.
- If a field matches multiple policy rules, apply the most restrictive redaction method.
- If no redaction is needed for a tool call, still include it in the `redacted_log` array but do not add an entry to the `redaction_audit`.
- The `redaction_audit` must be a complete record of every field that was altered.
- Never include the original sensitive value in the output.

**EXAMPLES**
[FEW_SHOT_EXAMPLES]

**RISK_LEVEL**
[RISK_LEVEL]

To adapt this template, start by defining your [REDACTION_POLICY_RULES] as a concrete JSON array of rule objects. For example, a rule to redact API keys might use a field_pattern of $.arguments.api_key with a sensitivity_type of SECRET and a redaction_method of REPLACE_WITH_PLACEHOLDER using the placeholder [REDACTED_API_KEY]. Provide a few [FEW_SHOT_EXAMPLES] that demonstrate a raw log entry and its corresponding redacted output with the audit record. This is critical for teaching the model the exact mapping between policy rules and their application. Set the [RISK_LEVEL] to HIGH if the log contains secrets or regulated PII, which should trigger a mandatory human review step of the redacted output before it is shared. For lower-risk operational data, MEDIUM may be acceptable with automated validation checks. The [TARGET_AUDIENCE_OR_ENVIRONMENT] placeholder helps the model contextualize the risk, e.g., 'external vendor' versus 'internal staging environment'.

The Tool Call Redaction prompt is designed to sit as a post-processing filter in your agent observability pipeline, not as an inline interceptor that blocks tool execution. After a tool call completes and its raw log record is generated, route the log through this prompt before it reaches any external-facing storage, review interface, or lower-trust environment. This separation ensures that the agent's real-time tool use is never delayed by redaction latency while still guaranteeing that sensitive data never leaves the sanitization boundary. The prompt expects a structured tool call log containing at minimum the tool name, input arguments, output payload, and caller context. It returns a redacted version of that log plus a redaction_audit block documenting every field that was modified, the reason for redaction, and the applied masking rule.

Validation and retry logic must be implemented in the application layer surrounding this prompt. After receiving the model's output, validate that the redaction_audit array is present and non-empty when sensitive fields were expected. Check that every entry in the audit block includes a field_path, redaction_rule, and reason string. If the model returns a redacted log without a corresponding audit entry for a known sensitive field, reject the output and retry with a stronger constraint message appended to the prompt. Implement a maximum of 2 retries before escalating to a human reviewer. For high-sensitivity deployments, add a deterministic post-processing step that scans the redacted output with a regex-based PII detector (email patterns, credit card numbers, SSN formats) as a safety net. If the regex scan finds a match that the model's audit block did not flag, log an alert and quarantine the record. This defense-in-depth approach catches model misses that a single-pass redaction would leak.

Model selection matters for consistency. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, configured with temperature=0 to minimize variance in redaction decisions. The prompt should be called with the response_format or tool-use mode set to produce a JSON object matching the [OUTPUT_SCHEMA] you define. For high-throughput pipelines, batch multiple log records into a single prompt call where each record is a separate object in a logs array, and request a corresponding redacted_logs array in the response. This reduces API overhead but requires careful token budgeting—ensure the combined input plus expected output stays within the model's context window. Log every invocation of the redaction prompt itself: store the raw prompt text, the model's raw response, the validation result, and any retry attempts. This meta-audit trail is essential for proving to compliance reviewers that the redaction system itself is operating correctly and has not been tampered with.

Human review gates should be configured based on the [RISK_LEVEL] parameter passed into the prompt. For low risk, fully automated redaction with sampled QA review of 5% of records is usually sufficient. For medium risk, route any record where the model's audit block contains an uncertain confidence flag or where the redaction rule was contextual rather than pattern-based to a human review queue. For high risk, every redacted record should require human approval before it leaves the sanitization boundary. The review interface should display the original log, the redacted log, and the audit block side-by-side, with clear visual diff highlighting on changed fields. Never log the raw, unredacted tool call to an external observability platform—the redaction prompt is your last line of defense before data leaves your controlled environment. If you need raw logs for debugging, keep them in an encrypted, access-controlled internal store with strict retention policies and ensure the redaction pipeline is the only path to external systems.