> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beyondguard.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Output Guard: Prevent Data Leakage and Harmful AI Responses

> Output Guard inspects every model response before delivery, blocking data leakage, toxic content, IP violations, and dangerous code from reaching users.

Every other guard in the BeyondGuard stack focuses on what goes into your model — but what comes out matters just as much. Output Guard is the last line of defense before a model response reaches your end users. It inspects every generated response in real time, evaluating it for sensitive data, harmful content, intellectual property violations, dangerous code, and brand integrity issues. A response that passes all upstream controls can still cause harm if the model inadvertently — or deliberately, under adversarial influence — produces output it should not. Output Guard ensures that even in those cases, nothing damaging is delivered.

## What Output Guard Detects

Output Guard evaluates model responses across five threat categories.

* **Data Leakage / PII:** Sensitive personal or business data included in a model response — names, email addresses, phone numbers, financial identifiers, healthcare data, or internal business information — that should not be surfaced to the requesting user or logged in plaintext.
* **IP Violation:** Model outputs that reproduce copyrighted text, trademarked content, or licensed code verbatim, exposing your organization to intellectual property liability.
* **Toxic and Harmful Output:** Offensive, harassing, discriminatory, or otherwise harmful content — including content that is harmful in the specific context of your application even if it would not be universally classified as toxic.
* **Dangerous Code:** Generated code that contains malicious behavior (backdoors, data exfiltration, destructive operations) or serious security vulnerabilities (SQL injection, command injection, hardcoded credentials) that would put users or systems at risk if executed.
* **Brand Integrity:** Responses that contradict your brand guidelines, make unauthorized claims about your products or services, misrepresent your organization's positions, or otherwise violate your defined business rules for model behavior.

## How Output Guard Works

Output Guard intercepts model responses after generation and before delivery, running them through a post-generation inspection pipeline.

<Steps>
  <Step title="Response Capture">
    After your model generates a response, Output Guard captures it before it is returned to the user or consumed by the next step in your pipeline. For streaming responses, Output Guard buffers the stream and evaluates the complete response prior to final delivery.
  </Step>

  <Step title="Multi-Category Evaluation">
    The response is evaluated across all enabled threat categories simultaneously. PII detection uses entity recognition and pattern matching. IP violation detection compares response content against reference fingerprints. Toxicity evaluation uses content classifiers tuned to your configured policy. Code analysis uses static analysis to identify dangerous patterns. Brand integrity checks compare the response against your registered brand rules.
  </Step>

  <Step title="Enforcement Action">
    Based on evaluation results and your configured thresholds, Output Guard takes the appropriate enforcement action: **deliver** (no issues detected), **redact** (mask identified sensitive content and deliver the modified response), or **block** (reject the entire response and return a safe fallback). See the next section for guidance on choosing between redaction and blocking.
  </Step>

  <Step title="Audit Logging">
    Every evaluated response — whether delivered, redacted, or blocked — is recorded in the BeyondGuard audit log with its evaluation scores, matched patterns, enforcement action, and (for redacted responses) the original and modified versions. This log supports compliance reporting and incident investigation.
  </Step>
</Steps>

## Configuring Output Guard

Enable and configure Output Guard from the BeyondGuard Control Plane.

<Steps>
  <Step title="Open Your Project">
    Navigate to the [Control Plane](https://app.beyondguard.io) and select the project you want to protect.
  </Step>

  <Step title="Open the Guards Tab">
    Inside your project, select the **Guards** tab from the left navigation panel.
  </Step>

  <Step title="Enable Output Guard">
    Locate **Output Guard** in the guard list and toggle it to **Enabled**.
  </Step>

  <Step title="Configure PII Detection">
    Under **PII Settings**, select the PII categories you want Output Guard to detect and act on. Categories include personal identifiers (name, email, phone, address), financial data (account numbers, card numbers), healthcare identifiers, and custom patterns you define via regex or named entity rules.
  </Step>

  <Step title="Set Content Policy Thresholds">
    Under **Content Policy**, configure the sensitivity thresholds for toxicity, IP violation, and brand integrity checks. Each category can be tuned independently. Review the Observation Mode detections from your application before finalizing thresholds for Enforcement Mode.
  </Step>

  <Step title="Configure Code Analysis">
    Under **Code Analysis**, enable dangerous code detection and select the vulnerability categories you want flagged: malicious behavior, injection vulnerabilities, hardcoded secrets, and insecure patterns. You can scope code analysis to specific programming languages if your application generates code in a known set of languages.
  </Step>

  <Step title="Register Brand Rules">
    Under **Brand Integrity**, enter the business rules, prohibited claims, and brand guidelines that model responses must comply with. Rules can be entered as natural-language statements or as structured policy documents.
  </Step>

  <Step title="Choose Enforcement Actions per Category">
    For each threat category, configure whether violations should trigger **Redaction** or **Blocking** (see the next section). You can set different enforcement actions for different categories and different severity levels.
  </Step>

  <Step title="Save and Deploy">
    Click **Save Configuration**. Output Guard begins inspecting all model responses on this project immediately.
  </Step>
</Steps>

## Operating Modes

Output Guard supports two operating modes. You can switch between them at any time from the Control Plane without downtime.

|                         | **Observation Mode**                                                                              | **Enforcement Mode**                                                                                                         |
| ----------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **What it does**        | Inspects every model response and logs detections, but always delivers the full response to users | Inspects every model response and actively redacts or blocks based on your configured policy                                 |
| **Effect on users**     | No impact — all responses are delivered unchanged regardless of detections                        | Responses with policy violations are redacted or blocked before delivery; users receive a safe modified or fallback response |
| **Best used for**       | Baselining violation frequency, tuning thresholds, evaluating Output Guard before go-live         | Production enforcement once thresholds are tuned and enforcement actions are configured per category                         |
| **Audit logging**       | Full — all detections and evaluation scores recorded                                              | Full — all decisions (deliver, redact, block) recorded, including original content for redacted and blocked responses        |
| **False positive risk** | Zero user impact even if misconfigured                                                            | High-sensitivity settings may redact or block valid content                                                                  |

<Tip>
  Start in Observation Mode to understand the baseline violation rate for your application. Review the logged detections before configuring enforcement actions — some categories such as brand integrity are highly application-specific and require careful threshold tuning before enforcement to avoid blocking legitimate responses.
</Tip>

## Redaction vs. Blocking

When Output Guard detects a policy violation, it can respond in one of two ways. Choosing the right enforcement action for each threat category balances security with user experience.

<Tabs>
  <Tab title="Redaction">
    Redaction masks the violating content within the response while preserving the rest of the model's output. The user receives a modified but still useful response.

    **How it works:** Identified sensitive content — a PII value, a flagged phrase — is replaced with a token such as `[REDACTED]`, `[PII REMOVED]`, or a custom placeholder you configure. The rest of the response is delivered unchanged.

    **Best for:**

    * PII and sensitive data: the user's question can still be answered without exposing the specific sensitive value
    * Minor brand integrity issues: a response that is mostly correct but contains a single non-compliant claim can be corrected rather than discarded

    **Example:** A response that includes a customer's email address retrieved from context is delivered with the email replaced by `[REDACTED]` — the user still receives a complete, coherent answer.
  </Tab>

  <Tab title="Blocking">
    Blocking rejects the entire model response and returns a safe fallback message to the user. No part of the original response is delivered.

    **How it works:** Output Guard discards the generated response entirely and substitutes a pre-configured fallback — for example, "I'm sorry, I can't help with that request." The original response is preserved in the audit log for review.

    **Best for:**

    * Toxic and harmful content: partial delivery of a harmful response is still harmful
    * Dangerous code: a code snippet with a backdoor cannot be safely partially redacted
    * Severe IP violations: responses that reproduce substantial copyrighted text should not be partially delivered

    **Example:** A response that contains step-by-step instructions for a harmful action is blocked entirely, and the user receives a neutral fallback message. The full original response is recorded in the audit log.
  </Tab>
</Tabs>

<Tip>
  Use Redaction for PII so your users still receive a complete, useful response — masking a phone number or email address does not reduce the value of most answers. Use Blocking for toxic content and dangerous code, where delivering even a portion of the flagged response creates unacceptable risk. When in doubt, review your Observation Mode logs to understand the nature of the violations your application produces before committing to an enforcement strategy.
</Tip>
