Skip to main content

Policy Templates

Industry-specific policy templates give you a compliant enforcement baseline out of the box. Apply a template, then customize specific rules for your organization's needs.

Where to find it in the app​

Dashboard → Policies & Authority → RUNTIME → Default Policy.

The policy management page is the home for everything in this doc. It has a stage tab bar at the top:

  • RUNTIME — the policies that apply when agents actually run (the default and most-used stage)
  • DISCOVERY — policies that apply during discovery scans
  • TRAINING DATA — policies for training-data connectors (if training-data governance is enabled for your organization)
  • GOVERNANCE — org-wide governance thresholds (see Actor Governance)
  • BUNDLES — import / export the whole policy set as a JSON bundle (see Policy Bundles)

Within RUNTIME, the scope tabs are:

  • Default Policy — your organization's active template and the rules that apply org-wide
  • App Context — pick a specific agent / AppContext and override the defaults just for it
  • Data Privacy — appears in TRAINING DATA stage only

The Default Policy tab is where you pick a template and override its defaults. The App Context tab is where you tune rules for a single agent.

Available templates​

Open Policies & Authority → RUNTIME → Default Policy and choose a template from the Policy Template picker at the top of the page. Each template pre-configures default actions across all detection types for the relevant regulatory environment. Thirteen templates ship today; only one is active per organization at a time.

TemplateBest forPosture
DEFAULTGeneral-purpose baselineBalanced: block critical, redact PII/PHI, log everything else
HEALTHCAREHospitals, health-tech, payersHIPAA: block PHI egress, redact at ingress
FINANCIALBanks, fintech, paymentsPCI DSS + GLBA: block financial data both ways; risk-adaptive transactional rules
GOVERNMENTPublic sectorStrict across all classifications; comprehensive audit
EDUCATIONK–12 and higher edFERPA: student records protection; balanced content safety
LEGALLaw firms, in-house counselAttorney–client privilege and litigation hold protections
RETAILE-commerce, omnichannelCustomer data and payment-card protection
CRITICAL_INFRASTRUCTUREEnergy, utilitiesNERC CIP alignment; OT/ICS-aware defaults
DEFENSEDefense contractorsClassified data handling; compartmentalized access
ZERO_TRUSTMaximum lockdownEverything blocked or step-up by default
SANDBOXTesting and evaluationEverything logged, nothing blocked
OPENCLAWOpenClaw-managed agentsCredential, local-file, tool-exec, and model-boundary protections
STARTUPVelocity-first teamsEssential guardrails only; developer-friendly

How to pick​

  • You have a known regulatory regime → use the matching template (HEALTHCARE, FINANCIAL, GOVERNMENT, EDUCATION, LEGAL, RETAIL, CRITICAL_INFRASTRUCTURE, DEFENSE).
  • You're evaluating Rivaro → SANDBOX first, then graduate to DEFAULT or STARTUP once you're comfortable with the detection coverage.
  • You operate agents touching shell, files, or external tools → OPENCLAW adds tool-execution guardrails on top of whatever vertical template you choose.
  • You're in defense, classified work, or maximum-paranoia mode → ZERO_TRUST — every detection blocks or requires step-up unless you explicitly allow it.

You can switch templates at any time. Custom overrides are preserved and continue to take priority over the new defaults — see Switching templates.

How templates work​

A template defines a default action for every detection type across every lifecycle stage. When a detection occurs and there's no custom rule matching it, the template default applies. Templates do not lock you in — every default can be overridden.

Rule override hierarchy​

When a detection occurs, Rivaro resolves the action using this priority order (most specific wins):

  1. AppContext-specific rule — a custom rule scoped to a specific agent/AppContext. Highest priority. Configure under App Context tab.
  2. Organization-wide custom rule — a custom rule that applies to all traffic in your organization. Configure under Default Policy tab.
  3. Template default — the action defined by your active template for this detection type and lifecycle stage.
  4. Fallback — if no rule or template default matches, the action is LOG (observe and record, never block).

Policy actions​

Every rule resolves to one of these actions. Choose the action from the Action dropdown in the rule editor.

ActionEffect
ALLOWAllow content without modification
LOGLog the detection but allow the content through
REDACTMask or remove the sensitive content (content-bearing categories only)
MODIFYTransform action parameters before execution (e.g. cap a refund amount)
STEP_UPRequire additional authentication or human approval before proceeding
DEFERTemporarily suspend the action pending additional context or resolution
QUARANTINEHold content for human review before any release
BLOCKBlock the entire request
RISK_ADAPTIVEResolve the action dynamically at request time — see Risk-adaptive policy below

RISK_ADAPTIVE is a meta-action: instead of committing to one outcome up front, the rule says "evaluate at request time and pick an action based on the actual risk signals."

Creating custom rules​

Organization-wide rule​

To override a template default for all agents in your organization, open Policies & Authority → RUNTIME → Default Policy and click Add rule. Set:

  • Detection type (or risk category — see Policy Scoping)
  • Lifecycle (INGRESS, EGRESS, TRAINING, or DEPLOYMENT)
  • Action

The rule lands in the org-wide section and takes priority over the template default.

AppContext-specific rule​

To override the default for a single agent or AppContext, open Policies & Authority → RUNTIME → App Context, pick the AppContext from the picker, and click Add rule in the rules list. Same fields as the org-wide editor, but scoped to that AppContext only.

Connector rule (training stage)​

If you have the TRAINING DATA stage enabled, switch the stage tab to TRAINING DATA and select a connector. Add rules the same way — they apply only to data scanned through that connector.

Rule fields​

The rule editor exposes these fields:

FieldRequiredDescription
Detection typeYes*Specific detection to match (e.g. PII_SSN). See Understanding Detections for all types.
Risk categoryYes*Broader match — applies to all detection types in this category. Use instead of detection type for category-wide rules.
LifecycleYesINGRESS, EGRESS, TRAINING, or DEPLOYMENT
ActionYesOne of the actions above
Evaluation rulesWhen action is RISK_ADAPTIVENamed evaluation rules. See Risk-adaptive policy.
EnabledNoToggle the rule without deleting it (default: on)
Notification channelNoLink a notification channel to fire when this rule matches

*Either detection type or risk category is required, not both.

Risk-adaptive policy​

Static actions like BLOCK or LOG are deterministic — the same outcome regardless of who's asking, what amount, what context. That works for most categories (PII is PII), but breaks down for behavioral detections where risk depends on a metric or context: a $50 refund is fine, a $50,000 refund is not; a single tool call is fine, 200 tool calls in a minute is not.

RISK_ADAPTIVE solves that. Instead of one fixed action, the rule defines a set of named evaluation rules that are evaluated against live request signals and context features. The engine picks the action dynamically and emits a full audit trail.

Configuring a risk-adaptive rule​

In the rule editor, set Action to RISK_ADAPTIVE. The editor expands to expose an Evaluation rules list where you add one or more named rules. Each rule has a priority (highest first), match conditions, and one of three modes (exact, graduated, expression).

When to use it​

Use RISK_ADAPTIVE for:

  • Graduated transactional limits — refunds, payouts, transfers, balance changes (FINANCIAL template uses this for BEHAVIORAL_VELOCITY_FINANCIAL and AGENT_TOOL_FINANCIAL_PAYOUT)
  • Tool capability gating — AGENT_TOOL_SHELL_EXEC, AGENT_TOOL_FILE_WRITE, AGENT_TOOL_MESSAGING where the action depends on what the tool is doing
  • Velocity / rate-based detections — same action repeated too often
  • Context-dependent thresholds — same content is fine in one role and blocked in another

For purely deterministic categories (PII, credentials, prompt injection patterns), prefer a static action.

Evaluation rule modes​

The editor's mode dropdown produces a rule shape like the JSON below — this is the structure stored for the evaluation rule, useful to reference when troubleshooting or reading bundle exports.

exact mode​

Fire a single action when match conditions are met.

{
  "name": "block_payout_over_limit",
  "priority": 100,
  "mode": "exact",
  "match": {
    "lifecycle": "EGRESS",
    "transaction_amount": { "gte": 10000 }
  },
  "action": "BLOCK",
  "userMessage": "Payouts over $10,000 require additional approval."
}

Match conditions support both string equality ("lifecycle": "EGRESS") and numeric operators (gte, gt, lte, lt, eq).

graduated mode​

Compute a metric and look up the action from a set of ranges. Used for refund/payout amounts, frequency thresholds, etc.

{
  "name": "graduated_refund_amount",
  "priority": 90,
  "mode": "graduated",
  "match": { "lifecycle": "EGRESS" },
  "metric": "transaction_amount",
  "valueType": "absolute",
  "ranges": [
    { "gte": 0,     "lt": 100,   "action": "ALLOW" },
    { "gte": 100,   "lt": 1000,  "action": "LOG" },
    { "gte": 1000,  "lt": 10000, "action": "STEP_UP" },
    { "gte": 10000,              "action": "BLOCK" }
  ]
}

Each range uses gte (lower bound, inclusive) and lt (upper bound, exclusive). Either or both may be set:

  • both set → matches when gte ≤ value < lt
  • only gte → matches everything at or above gte (no upper cap)
  • only lt → matches everything below lt (no lower floor)

Ranges are evaluated in order; first match wins.

valueType is "absolute" (use the raw metric value) or "relative" (default — compute a ratio against a baseline).

expression mode​

Evaluate a SpEL expression against context features. If it returns true, fire the action. Supports arithmetic, comparisons, and logical operators.

{
  "name": "block_overdraft_payouts",
  "priority": 110,
  "mode": "expression",
  "match": { "lifecycle": "EGRESS" },
  "expression": "transaction_amount > account_balance",
  "action": "BLOCK",
  "userMessage": "This payout exceeds the account balance."
}

Required context​

Any rule may declare required context fields. If any are missing from the processing context at evaluation time, the engine returns the onMissingData action (defaults to BLOCK):

{
  "name": "graduated_refund_amount",
  "mode": "graduated",
  "metric": "transaction_amount",
  "requiredContext": ["transaction_amount", "account_balance"],
  "onMissingData": "STEP_UP"
}

This is the failsafe pattern: if you can't measure the risk, fail closed.

Evaluation strategies​

When multiple evaluation rules match, the engine reconciles them using one of these strategies (set in the rule editor's Evaluation strategy field; default is MOST_RESTRICTIVE):

StrategyBehavior
MOST_RESTRICTIVEDefault / zero-trust. Evaluate ALL matching rules, pick the most severe action (BLOCK > QUARANTINE > DEFER > STEP_UP > MODIFY > REDACT > LOG > ALLOW). On unresolvable conflict, defers.
FIRST_MATCHEvaluate rules in priority order, fire the first match. Short-circuits — later rules are not evaluated.
ALLOWLISTDefault-deny. If ANY rule matches, allow. If NO rule matches, block. Use when you want to enumerate exactly what is permitted and reject everything else.
BLOCKLISTDefault-allow. If ANY rule matches, block. If NO rule matches, log. Use to enumerate exactly what is forbidden.
SESSION_CONTEXT_AWARELike MOST_RESTRICTIVE but factors in session security context (actor trust score, recent violation history). Can escalate or de-escalate the base action based on cumulative session signals.
note

ALLOWLIST is default-deny + any-match-allows, not "all rules must match." This is the opposite of how some other policy engines define the term. If you want "all rules must match," use MOST_RESTRICTIVE with carefully-scoped ALLOW rules.

If no rule matches, the engine falls back to the org-wide enforcement bands (Conservative / Balanced / Permissive presets configured per AppContext during the Connect Agent wizard).

Audit trail​

Every RISK_ADAPTIVE evaluation persists an assessment record visible from Actions & Evidence when the decision is shown. The record captures:

  • Composite exposure score (signal + actor + context)
  • Matched band and band source (rule, preset, or org default)
  • Static vs. adaptive action (so you can see when adaptive evaluation escalated or de-escalated the static action)
  • Whether the action was escalated or de-escalated, and why
  • Actor trust score at time of evaluation
  • Full evaluated context features
  • The matched rule name and rule mode

This is the evidence trail an auditor needs to defend any dynamic decision. Violations record their policyMechanism as RISK_ADAPTIVE so you can distinguish "BLOCK because the rule said BLOCK" from "BLOCK because risk-adaptive evaluation resolved to BLOCK."

Templates that ship risk-adaptive rules​

Templates may declare RISK_ADAPTIVE as the default action for specific detection types, and ship the evaluation rules with the template:

TemplateDetection types using RISK_ADAPTIVE
FINANCIALBEHAVIORAL_VELOCITY_FINANCIAL, BEHAVIORAL_VELOCITY_FINANCIAL_COUNT, AGENT_TOOL_FINANCIAL_PAYOUT
OPENCLAW (agent-tool template)AGENT_TOOL_SHELL_EXEC, AGENT_TOOL_FILE_READ, AGENT_TOOL_FILE_WRITE, AGENT_TOOL_MESSAGING

When you switch templates, the shipped evaluation rules become the new defaults — your custom overrides are preserved on top.

Switching templates​

You can switch your active template at any time. Open Policies & Authority → RUNTIME → Default Policy, choose a new template from the Policy Template picker, and confirm. Custom overrides are preserved when switching — they continue to take priority over the new template's defaults.

Viewing your current policy​

The Default Policy tab shows template defaults side-by-side with any custom overrides, grouped by risk category and lifecycle. RISK_ADAPTIVE rules render with an inline expandable panel showing the underlying evaluation rules and their match conditions.

To see the policy as it applies to a specific agent, switch to the App Context tab and pick the AppContext — the panel resolves defaults + overrides for that agent.

Beyond detection-type matching​

The examples above scope rules by detection type and lifecycle. The policy engine actually supports ten scoping dimensions — including risk category, capability surface, surface family, trust-boundary surface/family, intent class, and prompt-template hash. The resolution hierarchy lets a single broad rule cover all detection types in a risk domain or capability surface without having to list each one.

See Policy Scoping for the full taxonomy and resolution order.

GitOps and policy-as-code​

The whole set of organization rules, app-context overrides, and output checks can be exported as a single JSON bundle (rivaro.policy/v1 format) with a SHA-256 checksum, then re-imported with dry-run to preview drift or prune to make the live state match a file in version control. This is how you ship policy through pull requests instead of clicking around the UI.

See Policy Bundles for the export/import workflow, the JSON Schema, and the round-trip guarantees.

Next steps​