Policies

A policy is a rule that turns checks into a verdict. It's a tree of conditions plus an action: when the conditions match an evaluation, the action becomes the verdict.

Policies are the v3 replacement for v2 environments. Where v2 leaned on fixed environment thresholds, v3 lets you write your own AND/OR conditions over any check and pick the verdict to apply.

Anatomy of a policy

• Name and description: for your own reference in the dashboard.
• Type: development or production. A development policy is evaluated only for traffic from a development API key, and a production policy only for production keys. That lets you test rules without touching live traffic.
• Enabled: turn a policy on or off without deleting it.
• Event types: which actions the policy applies to: login, signup, or access.
• Conditions: a nested AND/OR tree of comparisons over checks, lists, and metadata.
• Action: the verdict to produce when the conditions match.
• Priority: decides which policy wins when more than one matches. The highest-priority match takes effect.

What conditions can check

Condition fields line up with the check inventory, grouped by category:

• Device: device_count, computer_device_count, tablet_device_count, mobile_device_count, device_id.
• Network: impossible_travel, is_new_ip, ip_country, ip_is_vpn, ip_is_proxy, ip_is_tor, ip_is_hosting, concurrent_sessions.
• User: is_new_user, is_email_verified, is_phone_verified, user_age_days, is_suspended, in_list (see Lists), user_external_id, user_email, metadata.
• Email: email_is_disposable, email_is_webmail, email_is_invalid, email_is_accept_all.
• Fingerprint: is_new_fingerprint, fingerprint_user_count.
• Velocity: event_count over a sliding window.
• Device integrity (native SDKs): jailbroken_ios, rooted_android, is_simulator, is_emulator, debugger_attached, ui_testing.
• Group: group, the user's assigned group (if you use groups).

Conditions match on checks, not risks. Risks are scored separately and recorded on the evaluation for review. Matching a policy directly on a risk score or severity is coming soon.

How matching works

When an evaluation runs, Rupt walks every enabled policy whose type matches the calling API key's environment and whose event type matches the action, in priority order, and tests each one's conditions against the derived checks. The highest-priority match wins; ties break toward the older policy. Order your rules so the most specific ones sit above the broad catch-alls.

The winning policy's action becomes the evaluation's verdict. If nothing matches, the verdict is allow.

Practical guidance

• Start broad and narrow as you learn. A first login policy that challenges when impossible_travel is true catches a lot with very few false positives.
• Reach for specific checks when you want a surgical rule: deny on is_simulator in native flows, or challenge once device_count crosses a threshold.
• Keep development and production policies separate by type. The dashboard shows both side by side, and only the set matching the calling key is evaluated.