Skip to contents

Build a guardrail policy

Source: R/policy.R
build_policy.Rd

build_policy() combines validated shieldr_rule objects with threshold settings for the scanner layer. OWASP LLM Top 10 references are preserved on each rule; see https://genai.owasp.org/llm-top-10/.

Usage

build_policy(
  name = "custom",
  rules = list(),
  thresholds = list(),
  rate_guard = NULL,
  controls = NULL
)

Arguments

name

Policy name.

rules

A list of shieldr_rule objects.

thresholds

Threshold overrides. Missing values are filled from redact_at = 0.4 and block_at = 0.75.

rate_guard

Optional shieldr_rate_guard. When present, secure_chat() checks the guard before chat calls and updates it after successful calls.

controls

Optional controls from policy_controls().

Value

A shieldr_policy.

Details

A policy is intentionally small and inspectable. It contains a policy name, a list of deterministic rules, threshold values, and an optional rate guard. The scanners do not mutate a policy; they read the rule list, create findings, calculate a risk score from finding severities, and then compare that score with the policy thresholds.

controls configures secure_chat() orchestration behavior after a report has already resolved to block. For example, a policy can refuse blocked prompts with a user-facing message, drop blocked RAG rows, or mark blocked output for human review.

Thresholds are merged over the package defaults:

  • redact_at = 0.4

  • block_at = 0.75

Lower thresholds make a policy stricter. Higher thresholds make accumulated findings less likely to escalate. Critical findings and explicit block rules still block regardless of threshold.

Examples

policy <- build_policy(rules = list(rule_pii_email()))
policy
#> llmshieldr policy
#> name: custom
#> rules: 1
#> redact_at: 0.4
#> block_at: 0.75