Agent Tool Output Sensitive Header Stripping Prompt

This prompt is for security engineers and platform developers who need to sanitize HTTP response headers before they re-enter an agent's context window. The primary job is to remove dangerous or sensitive headers—such as Authorization, Set-Cookie, X-Internal-Routing, and custom API tokens—from tool outputs while preserving headers required for downstream processing, like Content-Type or Retry-After. Use this when your agent makes HTTP requests via tools and the raw response headers could leak credentials, session tokens, or internal infrastructure details into the model's context, logs, or subsequent tool calls.

You should not use this prompt when you need a full HTTP security proxy, when you must modify the response body, or when the tool itself can be configured to strip headers at the transport layer. This prompt is a semantic sanitization layer, not a replacement for network-level controls. It works best when integrated into a tool output post-processing pipeline, where the raw response is intercepted, the headers are extracted, and this prompt is called to produce a cleaned header set before the response is passed to the agent. The prompt expects a structured input containing the original headers, a list of header names to always strip, and a list of headers to always preserve.

Before deploying, define your allowlist and denylist of headers explicitly. The prompt uses these lists to make deterministic stripping decisions, but it also applies heuristic detection for patterns that resemble credentials or internal routing tokens even if they aren't in the denylist. This dual approach catches custom headers like X-Api-Key or X-Forwarded-For that may not be in your initial configuration. Always log the original headers, the stripped headers, and the final output for audit purposes. In high-security environments, require human review when the prompt flags headers it cannot confidently classify. The next section provides the copy-ready template you can adapt to your specific header policies.

This prompt template is designed to be inserted into an agent's tool-output processing pipeline. It receives the raw HTTP response headers from a tool call and returns a cleaned set of headers, with dangerous fields such as Authorization, Set-Cookie, and internal routing tokens removed or redacted. The template uses square-bracket placeholders so you can wire in the specific headers, the tool's identity, and the required output format without modifying the core instruction logic.

textCopy
You are a security-focused output sanitizer for an AI agent. Your job is to inspect the HTTP response headers returned by a tool and strip any sensitive or dangerous values before the headers are passed back into the agent's context.

[CONTEXT]
Tool Name: [TOOL_NAME]
Tool Description: [TOOL_DESCRIPTION]
Risk Level: [RISK_LEVEL]

[INPUT]
Raw Response Headers:
[RAW_HEADERS]

[CONSTRAINTS]
You MUST remove or redact the following header categories:
1. Authentication headers: Authorization, Proxy-Authorization, WWW-Authenticate, Proxy-Authenticate.
2. Session and state headers: Set-Cookie, Cookie, Session-ID, X-Session-Token.
3. Internal routing and infrastructure headers: X-Internal-Route, X-Forwarded-For, X-Real-IP, X-Request-ID, X-Routing-Key, X-Backend-Host, X-LB-Instance.
4. Custom secrets and tokens: any header matching the pattern [CUSTOM_SENSITIVE_PATTERNS].

You MUST preserve the following header categories unless they contain embedded credentials:
1. Standard caching headers: Cache-Control, ETag, Last-Modified, Age, Expires.
2. Content metadata: Content-Type, Content-Length, Content-Encoding, Content-Disposition.
3. CORS and security policy headers: Access-Control-Allow-Origin, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy (inspect for report-uri credentials).
4. Rate limiting headers: Retry-After, X-RateLimit-Remaining, X-RateLimit-Reset.

[OUTPUT_SCHEMA]
Return a valid JSON object with this exact structure:
{
  "tool_name": "string",
  "total_headers_received": number,
  "headers_removed": number,
  "headers_redacted": number,
  "headers_preserved": number,
  "cleaned_headers": {
    "header_name": "header_value"
  },
  "removed_headers": [
    {
      "name": "string",
      "reason": "string",
      "category": "authentication | session | routing | custom_secret"
    }
  ],
  "redacted_headers": [
    {
      "name": "string",
      "original_length": number,
      "reason": "string",
      "redacted_form": "string"
    }
  ],
  "anomalies_detected": [
    {
      "header_name": "string",
      "anomaly_type": "string",
      "description": "string"
    }
  ]
}

[EXAMPLES]
Example Input:
Raw Response Headers:
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
X-Request-ID: abc-123-def
Cache-Control: max-age=3600
Set-Cookie: session=abc123; HttpOnly; Secure
X-Internal-Route: backend-03

Example Output:
{
  "tool_name": "customer-api",
  "total_headers_received": 6,
  "headers_removed": 3,
  "headers_redacted": 0,
  "headers_preserved": 3,
  "cleaned_headers": {
    "Content-Type": "application/json",
    "Cache-Control": "max-age=3600"
  },
  "removed_headers": [
    {
      "name": "Authorization",
      "reason": "Bearer token removed to prevent credential leakage into agent context",
      "category": "authentication"
    },
    {
      "name": "Set-Cookie",
      "reason": "Session cookie removed to prevent session hijacking risk",
      "category": "session"
    },
    {
      "name": "X-Internal-Route",
      "reason": "Internal routing header removed to prevent infrastructure disclosure",
      "category": "routing"
    }
  ],
  "redacted_headers": [],
  "anomalies_detected": []
}

[INSTRUCTIONS]
1. Parse the raw headers into individual name-value pairs. Handle multi-line folded headers per RFC 7230.
2. For each header, classify it against the removal, redaction, and preservation rules in [CONSTRAINTS].
3. If a header value contains an embedded secret (e.g., a token inside a URL in Content-Security-Policy), redact only the secret portion and preserve the rest. Document this in `redacted_headers`.
4. If you detect header injection attempts (e.g., newline characters in header names, duplicate conflicting headers, headers that appear to be user-controlled input rather than server responses), flag them in `anomalies_detected`.
5. If [RISK_LEVEL] is "high", also remove any header not explicitly listed in the preservation rules. If "medium" or "low", preserve unknown headers unless they match a sensitive pattern.
6. Return only the JSON object. Do not include any explanatory text outside the JSON.

To adapt this template, replace the square-bracket placeholders with your actual values. [TOOL_NAME] and [TOOL_DESCRIPTION] provide context that helps the model understand the tool's purpose and adjust its sensitivity. [RAW_HEADERS] should be populated with the exact header string returned by the tool, preserving original casing and ordering. [CUSTOM_SENSITIVE_PATTERNS] accepts a comma-separated list of additional header name patterns your organization considers sensitive, such as X-Api-Key, X-Org-Secret. [RISK_LEVEL] controls the strictness of the preservation rules. Before deploying, run this prompt against the eval harness described in the Testing and Evaluation section to verify it catches the header injection variants and preserves the necessary headers for your specific tool ecosystem.

This prompt is designed to sit as a post-processing filter between any tool that returns raw HTTP response headers and the agent's main reasoning context. The most common integration point is inside a tool-execution wrapper or an MCP server middleware layer. When a tool like web_fetch or api_call returns a response object containing headers, the harness intercepts that output, runs it through the stripping prompt, and only forwards the cleaned header set to the agent. This prevents the agent from ever seeing raw Authorization, Set-Cookie, X-Internal-Routing, or similar dangerous headers that could leak into logs, be repeated in agent output, or be exploited via indirect prompt injection if the agent later echoes header values.

Integration flow: The harness should call the model with the prompt template, passing the raw headers as [RAW_HEADERS] and the configured allowlist as [ALLOWED_HEADER_PATTERNS]. The expected output is a JSON object with cleaned_headers, stripped_headers, and anomalies arrays. After receiving the model response, the harness must validate the output schema before forwarding. Check that cleaned_headers contains only keys matching the allowlist, that every stripped header appears in the stripped_headers array with a reason, and that no sensitive patterns (bearer tokens, sk- prefixes, AWS signature values) remain in the cleaned output. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the retry also fails, block the tool output entirely and return an empty header set with an anomaly logged—never fall through to passing raw headers.

Model choice and latency: This is a structured extraction task with a small input payload, so a fast, cheaper model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) is appropriate. Latency should be measured and kept under 500ms for most header sets. If the tool is on a hot path, consider caching results for identical header structures. Logging and audit: Every stripping operation should produce a structured log entry containing the tool name, timestamp, count of stripped headers, any anomalies detected, and the model's response ID. These logs are essential for security review and debugging agent behavior. Human review triggers: If the anomalies array contains any entry with severity: "high"—such as a detected token leak or an unexpected internal header pattern—the harness should flag the tool call for human review and prevent the agent from acting on the associated response body until approved.

What to avoid: Do not run this prompt on the agent's own generated output—it is strictly for sanitizing external tool responses. Do not use the stripped headers as the only security boundary; defense-in-depth requires that tools also avoid returning sensitive headers in the first place. Do not skip schema validation on the model's output; a malformed JSON response from the stripping prompt could cause the harness to pass raw headers through. Finally, maintain the allowlist configuration in code or a secure config store, not in the agent's system prompt, to prevent prompt injection from modifying the allowlist at runtime.