Data Exfiltration Guard Prompt for Browser Tools

This prompt is a pre-processor guard for security engineers controlling browser-based agents. It sits at the boundary where a browser tool retrieves arbitrary web content—rendered DOM, hidden fields, URL parameters, and script-accessible data—and inspects that payload before it enters the agent's context window. The job-to-be-done is straightforward: produce a structured content filtering decision that either allows transmission or blocks it, with a clear reason code and a sanitized alternative when safe. The ideal user is a platform security engineer or AI infrastructure operator who already has a browser tool in their agent pipeline and needs a deterministic, auditable gate that prevents sensitive data from leaking into model context, logs, or downstream tool calls. Required context includes the raw page data (HTML, rendered text, or structured DOM extraction), the agent's authorized data scope, and a configurable sensitivity policy that defines what constitutes a blockable finding.

This is not a general-purpose redaction prompt. It is purpose-built for the browser-tool boundary where rendered DOM content, hidden <input> values, data-* attributes, and URL query parameters carry exfiltration risk that static code scanners miss. The prompt expects structured input that includes the page URL, the extracted text or DOM representation, and any metadata about the browsing session. It returns a JSON decision object with a verdict field (allow or block), a reason code drawn from a predefined taxonomy (e.g., PII_DETECTED, SECRET_PATTERN, INTERNAL_HOSTNAME, HIDDEN_FIELD_EXPOSURE), and an optional sanitized_content field when partial redaction is feasible. Do not use this prompt for real-time streaming content, for pages where the agent must interact with PII to complete its task, or as a replacement for network-layer DLP controls. It is a semantic guard, not a firewall.

Before deploying this prompt, ensure your browser tool extracts content in a structured format that the prompt can parse reliably. The prompt's effectiveness depends on the quality of the extraction: if hidden fields or URL parameters are stripped before the prompt sees them, the guard is blind to those vectors. Wire the prompt as a synchronous pre-processing step in your agent's browser-tool pipeline, with a hard block on any block verdict that prevents the content from reaching the model. Log every decision—including the URL, verdict, reason code, and a hash of the blocked content—for audit and debugging. Start with a dry-run mode that logs blocks without enforcing them, tune your sensitivity policy against false positives, and then enable enforcement. The next section provides the copy-ready prompt template you can adapt to your specific data classification taxonomy and browser extraction format.

This prompt acts as a pre-processing guard that sits between a browser tool's output and the agent model's context window. It inspects the raw scraped or rendered page content and produces a structured filtering decision. The goal is to prevent data exfiltration by blocking the transmission of personally identifiable information (PII), secrets, internal hostnames, and other sensitive data before the agent can process or repeat it. The prompt is designed to be called by a guard service or a pre-processing step in your agent orchestration layer, not by the agent itself.

textCopy
You are a data exfiltration guard for browser tool outputs. Your job is to inspect the content retrieved from a web page and decide whether it contains sensitive data that must be blocked before the agent can see it.

## INPUT
[RAW_PAGE_CONTENT]

## CONTEXT
- Source URL: [PAGE_URL]
- Retrieval Timestamp: [TIMESTAMP]
- Agent Identity: [AGENT_ID]
- Data Classification Policy: [CLASSIFICATION_POLICY]

## SENSITIVE DATA CATEGORIES TO DETECT
1. **PII**: Names, email addresses, physical addresses, phone numbers, government IDs, dates of birth, financial account numbers.
2. **Secrets**: API keys, tokens, passwords, connection strings, private keys, certificates, environment variables containing credentials.
3. **Internal Hostnames**: Non-public hostnames, internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), internal domain suffixes.
4. **Session Tokens**: JWTs, session cookies, CSRF tokens, OAuth tokens in page content.
5. **Database Identifiers**: Table names, column names, or query fragments that reveal internal schema.
6. **Infrastructure Details**: Cloud resource IDs, internal service names, cluster identifiers, bucket names not intended for public disclosure.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "decision": "BLOCK" | "ALLOW" | "REDACT",
  "findings": [
    {
      "category": "PII" | "SECRET" | "INTERNAL_HOSTNAME" | "SESSION_TOKEN" | "DB_IDENTIFIER" | "INFRA_DETAIL",
      "severity": "HIGH" | "MEDIUM" | "LOW",
      "matched_pattern": "The specific text that triggered detection",
      "location_hint": "Approximate position in content (e.g., 'line 45', 'footer section')"
    }
  ],
  "sanitized_content": "If decision is REDACT, the content with sensitive data replaced by [REDACTED:<category>] placeholders. If BLOCK, this field is null. If ALLOW, this field contains the original content.",
  "block_reason": "If decision is BLOCK, a concise explanation of why the content cannot be safely passed to the agent. Otherwise null.",
  "confidence": 0.0-1.0
}

## CONSTRAINTS
- Do not pass through any content that matches the sensitive data categories above.
- When in doubt, BLOCK. False negatives are worse than false positives.
- Internal hostnames and IPs must be blocked even if they appear in benign-looking text.
- If the page contains a mix of safe and sensitive content, prefer REDACT over BLOCK when the sensitive portions are clearly isolated.
- Never include the raw sensitive data in the `matched_pattern` field if doing so would leak it into logs. Use a hash or truncated form if the guard service's logging is not secure.
- If the content is empty or the URL is not accessible, return a BLOCK decision with an appropriate reason.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL: "STANDARD" | "ELEVATED" | "CRITICAL"]

To adapt this template, replace the square-bracket placeholders with your runtime values. The [RAW_PAGE_CONTENT] should be the full text extracted by the browser tool, including any hidden fields or dynamically rendered content. The [CLASSIFICATION_POLICY] should reference your organization's data handling rules, such as 'PCI-DSS Level 1' or 'Internal-Only'. The [FEW_SHOT_EXAMPLES] placeholder is critical for production accuracy: include at least three examples showing correct BLOCK, ALLOW, and REDACT decisions with realistic page content. The [RISK_LEVEL] parameter lets you adjust strictness—set to CRITICAL for pages that may contain customer data or authentication contexts. After implementing this prompt, run it through your eval suite using the test cases described in the evaluation section of this playbook before deploying to production.

The Data Exfiltration Guard Prompt is not a standalone chat instruction; it is a pre-context filter that must execute between the browser tool's raw output and the agent's reasoning context. The implementation harness should intercept the scraped or rendered page data, invoke the guard prompt, and act on the structured verdict before any page content reaches the agent's main prompt. This means the guard prompt runs as a synchronous, blocking step in the tool execution pipeline. If the verdict is BLOCK, the harness must discard the page content and return a sanitized error message to the agent, such as 'Content blocked: PII detected.' The agent should never see the raw blocked data, even in error logs.

For production integration, the harness requires three components: a validation layer, a retry policy, and an audit log. The validation layer must parse the guard prompt's JSON output and enforce the schema: {"verdict": "ALLOW"|"BLOCK", "reasons": ["PII"|"SECRET"|"INTERNAL_HOST"|"HIDDEN_FIELD"], "confidence": 0.0-1.0, "blocked_fields": ["..."]}. If the model returns malformed JSON or an unexpected verdict, the harness should default to BLOCK with a reason of VALIDATION_ERROR to fail safely. The retry policy should allow exactly one retry on validation failure with a stricter prompt variant that emphasizes JSON-only output, but no retries on a substantive BLOCK verdict—retrying a block decision risks leaking data through repeated model calls. The audit log must record the URL, timestamp, verdict, reasons, and a hash of the blocked content for compliance review, but never log the raw blocked content itself.

Model choice matters here: use a fast, cheap model for this guard step because it runs on every page load. A small instruction-tuned model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned local classifier) is appropriate. Do not use the same model instance that powers the agent's reasoning, as this creates a risk of context leakage if the guard model's output is accidentally included in the agent's context window. Run the guard prompt in a separate, stateless API call with no conversation history. For high-throughput browser agents, consider batching guard requests or deploying a dedicated inference endpoint with request queuing to avoid adding unacceptable latency to page loads.

Testing this harness requires a dedicated eval suite that goes beyond prompt evaluation. Build a golden dataset of known-safe and known-dangerous page snippets, including edge cases like PII in HTML comments, secrets in inline JavaScript, internal hostnames in data-* attributes, and hidden form fields containing pre-filled sensitive data. For each test case, assert not only the correct verdict but also that the blocked fields list is accurate and that no false positives occur on benign pages containing terms like 'password' in instructional text. Integrate these tests into your CI/CD pipeline as a pre-release gate for any changes to the guard prompt or its parsing logic. Finally, implement a human review queue for low-confidence verdicts (e.g., confidence between 0.5 and 0.8) where the harness routes the page content to a secure review interface for manual classification, feeding those decisions back into the eval dataset to improve future prompt iterations.