Skip to main content

Policy Scoping

A policy rule's scope decides what it matches. Most rules only ever need a detection type and a lifecycle stage — those handle the bread-and-butter cases. But when you want to write one rule that governs all data-exfiltration detections, or every refund-like action regardless of which tool performs it, broader scopes let you do that without enumerating thirty detection types.

This page covers how scoping works and how Rivaro decides which rule wins.

Where to find it in the app​

Scope is configured per rule.

Dashboard → Policies & Authority → RUNTIME → Default Policy (org-wide) or App Context (per-agent) → click any rule's Edit action to open the rule editor.

The rule editor has a Scope section with the everyday fields and an Advanced scope expander for the broader axes described below.

To see how a rule's scope actually applies to an agent, open Policies & Authority → RUNTIME → App Context, pick the AppContext, and look at the resolved rule list — the panel shows which rule won for each detection type, along with the scope that matched.

The everyday scopes​

ScopeTargetsUsed for
Detection typeOne specific detection (e.g. PII_SSN)The most precise scope. One detection → one rule.
Risk categoryA whole risk domain (e.g. credentials, external data exfiltration)"Block everything in this risk domain" without enumerating detection types
LifecycleINGRESS, EGRESS, TRAINING, DEPLOYMENTAlways set. Pins the rule to one stage of the pipeline.

Most rules use exactly these. Start here.

Beyond detections — scoping by action, defense, and intent​

Detection-based scoping answers "something sensitive was found." Rivaro also lets you scope a rule to:

  • What the agent is doing — the capability it is exercising, independent of whether anything sensitive was detected. Capabilities are grouped into families (data, records, financial, communication, access, system, regulated), so one rule can govern an entire class of action.
  • What you're defending against — injection, exfiltration, fraud thresholds, content safety, auth boundaries, and behavioral limits. Scoping to a defense pre-populates a sensible evaluation shape you can then adjust.
  • What the agent appears to be trying to do — Rivaro classifies prompt intent, and a rule can fire on the intent alone, before tool resolution. Useful for gates like "deletion intents always require step-up approval."
  • A specific prompt version — a rule can be pinned to one system-prompt template. Change the prompt and the pin no longer applies, which is deliberate: policy stays tied to the prompt version it was written for.

The options available to your organization appear in the Advanced scope dropdowns in the rule editor. For predicates that don't fit any named axis, a Scope constraints field takes a custom JSON condition; it round-trips through bundle export/import unchanged and is visible in the rule's audit metadata. Reach for it last.

Why action-scoped rules matter​

When a brand-new tool shows up — a Salesforce MCP server you've never seen before — Rivaro can classify the verb it represents even if no specific detection type exists for it yet. A rule scoped to that capability governs the new tool from day one, rather than after someone notices it and writes a rule.

Example: refunds capped across every refund-style tool​

In the rule editor: set lifecycle to EGRESS, expand Advanced scope, scope the rule to the refund capability, set the action to RISK_ADAPTIVE, and add a graduated evaluation rule on transaction amount — allow small refunds, require step-up approval in a middle band, block above your ceiling.

That rule applies whether the refund is issued through Stripe MCP, a homegrown billing API, or any future tool that classifies the same way.

Resolution hierarchy​

When a detection or action arrives, the most specific matching rule wins. A rule pinned to an exact detection type beats a rule scoped to a capability, which beats one scoped to a whole risk category. If nothing matches, the active policy template's baseline action for that detection type and lifecycle applies.

If two rules tie at the same level of specificity, the evaluation strategy decides — MOST_RESTRICTIVE (default), FIRST_MATCH, etc.

App-context overlay​

An AppContext-scoped rule wins over an org-wide rule at the same level of specificity. AppContext is a tiebreaker, not a specificity boost: an app-context rule scoped to a risk category does not beat an org-wide rule scoped to an exact detection type.

To see how this resolves for a given agent, open Policies & Authority → RUNTIME → App Context, pick the AppContext, and read the resolved rule list — it shows which rule won and which scope matched.

Practical guidance​

  • Start with detection type + lifecycle. The most specific scope is the easiest to reason about.
  • Use risk category for cross-cutting policies. "Block all credentials at egress."
  • Use capability scoping for action-axis policies. "Refunds over $X require approval, regardless of which tool issues them."
  • Use defense scoping for threat-axis policies. "Tighter injection defense for the auth-handling agent."
  • Reserve intent and prompt-version scoping for narrow cases. Not for everyday rules.

Next steps​