Skip to main content
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:
  • Allow — the interaction passes unchanged; the decision, confidence score, and reason code are written to the audit log.
  • Deny — reject the interaction and return a configurable explanation to the caller.
  • Mask — remove or mask the offending content and allow the sanitized interaction to proceed.
  • Rewrite — reformulate the offending content into a policy-compliant equivalent, preserving user intent.
In Observation mode, the guard records the outcome it would have applied and marks the event for review, without altering the interaction.

​
Scope Definitions

BeyondGuard’s Context Guard uses scope definitions (control BG-26) to understand the intended purpose of your AI application. When a request or response falls outside the defined scope — for example, asking a customer support bot for legal advice — the guard flags, denies, or rewrites it 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

Prompt Guard can be configured to detect and mask personally identifiable information — both on the way in and before responses reach end users (controls BG-02 and BG-20). 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
  • Card numbers (PAN/CVV) — major card formats with Luhn validation
  • IBAN and account numbers — international bank account formats
  • National ID numbers — including Turkish TCKN and other national identifier formats
  • Passport numbers — international passport number patterns
  • Medical record numbers — common MRN formats used in healthcare systems
You can also define custom PII types for organization-specific formats. Enable or disable individual categories in the Prompt Guard → PII Detection section of your project’s Policies settings. For each enabled category, you can configure whether BeyondGuard masks (replaces with a placeholder), denies (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.