Output Sanitization

Intelligently masks or replaces sensitive information within otherwise safe text, preserving utility while ensuring privacy.

• Named Entity Recognition (NER): Identifies entities like names, addresses, and medical codes for redaction.
• Synthetic Replacement: Replaces a detected PII value (e.g., "John Doe") with a realistic but fake equivalent (e.g., "Jane Smith") to maintain text coherence.
• Differential Privacy Noise: Adds statistical noise to numerical outputs (e.g., salaries, ages) to prevent re-identification while preserving aggregate utility.

Proactive detection techniques that embed traps to identify attempted misuse or data leakage.

• Canary Tokens: Unique, fake pieces of data (e.g., a fake API key sk_test_12345) are inserted into the model's context. If this token appears in the output, it signals a prompt injection or data exfiltration attempt.
• Honeypot Prompts: The system intermittently sends decoy, high-risk prompts to the LLM to monitor if safety guardrails are functioning correctly.
• Use Case: Critical for monitoring adversarial robustness and detecting novel attack vectors in production.

Uses a secondary, smaller, or more controlled LLM to analyze and rewrite the primary model's output.

• Critique-and-Revise: A supervisor LLM critiques the initial output for safety violations and then rewrites it to be harmless.
• Constitutional AI: The model follows a set of principles (a constitution) to self-critique and self-improve its outputs during training and inference.
• Advantage: Can handle complex, contextual safety judgments that are difficult to encode in static rules, aligning with techniques like RLHF and DPO.

This filter targets and removes any code snippets, shell commands, or script blocks that could be executed. It prevents the LLM from inadvertently generating malicious payloads or unsafe instructions.

• Examples: Python scripts with os.system() calls, JavaScript containing eval(), SQL injection strings, or bash commands like rm -rf /.
• Mechanism: Uses pattern matching for code delimiters (e.g., backticks, <script> tags), keyword blocklists for dangerous functions, and syntax parsing to identify code structures.
• Goal: To eliminate the risk of code injection attacks where generated text could be pasted into a terminal or interpreter.

Sanitization scans for and neutralizes hyperlinks that point to known malicious domains, phishing sites, or unverified external resources.

• Process: Extracts all URLs from the text and checks them against real-time threat intelligence feeds or internal blocklists.
• Action: Typically replaces the URL with a warning placeholder, removes it entirely, or rewrites it to pass through a secure proxy for scanning.
• Critical For: Applications where the LLM might retrieve or generate links, such as customer support chatbots or research assistants, to prevent drive-by downloads or credential theft.

This filter redacts sensitive personal data that should not be exposed, even if the LLM inferred or hallucinated it from its training data.

• Common PII Types: Social Security/National ID numbers, credit card numbers, passport details, home addresses, phone numbers, and specific medical record identifiers.
• Techniques: Employs regular expressions for structured data formats (e.g., ###-##-#### for SSNs) and named entity recognition (NER) models for unstructured data like names and locations.
• Compliance: Essential for adhering to regulations like GDPR, HIPAA, and CCPA, which mandate data minimization and privacy protection.

Filters content that instructs or manipulates the user into performing dangerous, unethical, or illegal actions, even if not explicitly violent.

• Scope: Includes instructions for self-harm, creating weapons, bypassing security systems, engaging in financial fraud, or manipulating others (e.g., detailed social engineering scripts).
• Challenge: Requires understanding intent and context, often using safety classifiers fine-tuned to detect manipulative language rather than just explicit keywords.
• Purpose: Mitigates indirect harm and liability by preventing the model from acting as a tool for malicious coordination or exploitation.

Targets textual patterns commonly used in injection attacks against downstream systems, even if they appear benign in plain text.

• Examples: SQL fragments (' OR '1'='1), NoSQL injection strings, LDAP injection patterns, or template engine syntax (e.g., {{ malicious_code }}).
• Rationale: If the LLM output is fed into a database query, log file, or web template, these strings could be interpreted as commands. Sanitization escapes or removes these patterns.
• Defense-in-Depth: Complements input validation by ensuring the LLM itself does not become a vector for second-order injection.

Strips out or normalizes excessive HTML, XML, Markdown, or other markup that could break downstream applications or be used for obfuscation.

• Risks: Overly nested HTML can cause rendering issues or DOM-based XSS if rendered directly by a web client. Hidden metadata or invisible Unicode characters can be used for steganography or to bypass other filters.
• Process: Uses a whitelist approach, allowing only a safe subset of tags and attributes (e.g., <b>, <i>, <p>) and removing all others. Normalizes Unicode to a standard form.
• Utility: Ensures clean, predictable text formatting and closes covert channels that could be used to exfiltrate data or hide malicious payloads.

Guardrails are software layers and policy enforcement systems applied to LLM inputs and outputs. They act as a safety net to prevent undesirable model behavior, such as generating harmful content or leaking sensitive data. Unlike sanitization, which is a post-processing step, guardrails can be applied at multiple stages:

• Input Guardrails: Filter or rewrite user prompts before they reach the model.
• Output Guardrails: Validate, filter, or rewrite model responses before delivery.
• Neural Guardrails: Use a secondary, smaller model to critique the primary model's output in real-time. They are a foundational component for deploying LLMs in regulated or public-facing applications.

Content moderation is the automated or human-in-the-loop process of screening LLM outputs to enforce safety, legality, and policy compliance. It is a broader category that often encompasses output sanitization. Key components include:

• Classifier-Based Filtering: Using ML models (e.g., for toxicity, violence, sexual content) to score and flag outputs.
• Pattern Matching & Blocklists: Detecting and blocking known malicious patterns, URLs, or phrases.
• Human Review Queues: Sending high-risk or uncertain outputs to human moderators for final judgment. While sanitization focuses on removing dangerous elements, moderation may involve complete blocking, rewriting, or logging of the entire output.

PII (Personally Identifiable Information) Redaction is a critical subtype of output sanitization focused on privacy. It involves the automated detection and masking or removal of sensitive personal data from LLM outputs to ensure compliance with regulations like GDPR or HIPAA. Common techniques include:

• Named Entity Recognition (NER): Identifying names, addresses, phone numbers, and social security numbers.
• Pattern Matching: Using regular expressions for credit card numbers, email addresses, and dates of birth.
• Secure Hashing or Tokenization: Replacing PII with secure tokens that can be reversed by authorized systems only. This prevents accidental data leakage when models generate summaries or answers based on private user data.

Structured Output Enforcement is a proactive technique to constrain LLM outputs to a predefined, machine-parsable format, which inherently limits the risk of unsafe free-text generation. It is a form of input-side control that reduces the need for heavy post-hoc sanitization. Key methods include:

• Grammar-Constrained Decoding: Using a formal grammar (e.g., JSON schema, XML DTD) during token generation to force valid structure.
• Output Parsing & Validation: Wrapping the LLM call in code that validates the output against a schema and triggers a retry or fallback on failure.
• Function Calling: Framing tasks as API calls with strict argument definitions. By forcing outputs into a known schema, you eliminate entire classes of sanitization problems related to arbitrary text generation.

A Classifier Chain is an ensemble moderation architecture where multiple specialized machine learning classifiers are applied sequentially or in parallel to validate an LLM output. It is a common implementation pattern for robust content moderation systems that feed into sanitization logic. A typical chain might include:

1. Toxicity Classifier: Flags hate speech or harassment.
2. Bias Detector: Identifies unfair demographic stereotyping.
3. Factuality Scorer: Assesses grounding in provided context.
4. PII Detector: Flags potential personal data leaks. The results from this chain determine the final action: PASS, SANITIZE (triggering specific cleanup routines), or BLOCK. This modular approach allows for precise, risk-based handling.

A Refusal Mechanism is a model's trained behavior to decline to generate outputs for requests that are harmful, unethical, illegal, or outside its operational boundaries. It is a first line of defense that occurs during generation, reducing the burden on downstream sanitization systems. This capability is typically instilled via techniques like RLHF or Constitutional AI. Key aspects:

• Policy Alignment: The model internalizes a set of safety principles.
• Boundary Definition: Clear rules on what constitutes a refused category (e.g., instructions for violence, explicit content).
• Polite Deflection: The model is trained to refuse gracefully (e.g., "I cannot assist with that request") rather than producing harmful content that later needs sanitization. A strong refusal mechanism is essential for reducing the attack surface of an LLM application.