Policies are the rules that BeyondGuard’s guards use to evaluate every interaction in your AI stack. You configure what is permitted, what is flagged for review, and what is blocked outright — giving your organization precise control over how AI systems behave in production. Well-tuned policies reduce both risk and noise, ensuring that guards catch genuine threats without disrupting legitimate use.
Policy Concepts
Every BeyondGuard policy is built from three core elements that work together to define guard behavior.
Detection Rules specify the patterns, behaviors, or content types that constitute a violation. BeyondGuard ships with a default rule set covering all OWASP LLM Top 10 categories. You can extend these rules with custom patterns specific to your application domain — for example, detecting references to internal project codenames or restricting queries about competitor products.
Severity Thresholds determine how confident BeyondGuard must be in its detection before raising a threat event. Each detection rule produces a confidence score. The severity threshold you configure sets the minimum score required to trigger a flag. A lower threshold catches more potential threats at the cost of higher false positive rates; a higher threshold is more precise but may miss subtler attacks.
Enforcement Actions define what BeyondGuard does when a violation is detected. The available actions depend on the guard and the operating mode:
- Log — record the event without altering the interaction (available in all modes)
- Flag — log and mark the event for human review
- Block — reject the interaction and return a configurable error response to the caller
- Redact — remove or mask the offending content and allow the sanitized interaction to proceed
Scope Definitions
BeyondGuard’s Prompt Guard and Agent Guard use scope definitions to understand the intended purpose of your AI application. When a user interaction falls outside the defined scope — for example, asking a customer support bot for legal advice — the guard flags or blocks the request based on your enforcement action settings.
Define your application’s scope using a JSON configuration in the Scope section of your project’s Policies settings:
Keep scope definitions specific enough to be meaningful but broad enough to cover natural variations in user language. Overly narrow permitted topic lists will flag legitimate requests; overly broad ones reduce the value of scope-based detection.
PII Detection Categories
Output Guard can be configured to detect and redact personally identifiable information before responses reach end users. The following PII categories are available for detection:
- Names — individual person names detected via named entity recognition
- Email addresses — standard and obfuscated email patterns
- Phone numbers — domestic and international formats
- Credit card numbers — major card formats with Luhn validation
- Social security numbers — US SSN formats including masked variants
- Passport numbers — international passport number patterns
- Medical record numbers — common MRN formats used in healthcare systems
Enable or disable individual categories in the Output Guard → PII Detection section of your project’s Policies settings. For each enabled category, you can configure whether BeyondGuard redacts (replaces with a placeholder), blocks (rejects the response entirely), or flags (logs for review without modifying the response).
Content Policy Thresholds
Sensitivity settings control how aggressively BeyondGuard’s detection rules fire across all guards in a project.
Low sensitivity casts the widest net, flagging interactions with any meaningful indication of a threat. Use low sensitivity during initial Observation Mode deployments when you want maximum visibility into potential risks, or in high-security environments where false positives are preferable to missed threats.
Medium sensitivity balances coverage and precision. It is the recommended starting point for most production deployments. It catches the majority of genuine attacks while keeping false positive rates manageable for operations teams to review.
High sensitivity requires strong evidence before raising a threat event. Use high sensitivity in mature deployments where policies have been carefully tuned against real traffic data, and where false positives would cause significant user-facing disruption.
Allowlists and Blocklists
Allowlists and blocklists let you override BeyondGuard’s default detection behavior with explicit rules for your application.
Allowlists mark specific patterns, tool names, or content strings as always permitted, even if they would otherwise match a detection rule. Use allowlists for known-safe internal tools, approved response templates, or technical content that resembles attack patterns (for example, a security education bot that legitimately discusses injection techniques).
Blocklists mark specific patterns or content strings as always denied, regardless of confidence score. Use blocklists for known-bad patterns specific to your threat environment — for example, the exact text of a social engineering script that has been used against your organization.
Manage allowlists and blocklists in the Policies → Overrides section of your project settings. Both lists support exact string matching, regular expressions, and semantic similarity matching for fuzzy pattern coverage.
Overly strict policies — particularly very low sensitivity thresholds combined with aggressive blocklists — significantly increase false positive rates. Start at medium sensitivity and tune your policies based on real threat event data from Observation Mode before tightening thresholds. Premature enforcement configuration is the most common cause of guard misconfiguration.