Group Policy Visualization

This guide explains how to determine the effective policy enforcement posture for a user group. It covers how the group filter in the Policy Chain editor works, how to distinguish direct group-targeted rules from rules that apply to all users, and how to use the Policy Simulator to audit what actually happens for a user in a given group.

For a conceptual overview of how the Policy Engine evaluates requests and what actions are available, see Policy Engine — User Guide. For chain configuration, combining algorithms, and simulation usage, see Enforcement chain guide.

How group policy works in Arbitex

The Policy Engine does not have a separate “group policy” object. There is one org chain, and all users are evaluated against it. Groups affect policy behavior through rule conditions.

A rule with a user_groups condition fires only when the requesting user is a member of at least one of the listed groups. Rules without a user_groups condition fire for every user regardless of group membership.

This means a group’s effective policy is the set of rules that will fire for a user in that group — which includes:

Direct rules — rules with a user_groups condition that includes this group
Universal rules — rules with no group condition (apply to all users including this group)

There is no inheritance in the traditional RBAC sense. Groups do not inherit from parent groups. A user in the engineering group is only matched by rules that explicitly list engineering in their user_groups condition (or rules with no group condition at all).

Reading the enforcement posture for a group

Step 1: Open the Policy Chain editor

Navigate to Settings → Policies → Policy Chain.

The chain editor shows all packs in chain order.

Step 2: Activate the group filter

Locate the Filter by group field at the top of the chain editor.
Enter the group name you want to audit (e.g., finance, engineering, contractors).

The editor asynchronously fetches each pack’s rules and checks for user_groups conditions matching the entered group name.

Step 3: Interpret the visual state

After the filter loads:

Visual state	Meaning
Highlighted pack	This pack contains at least one rule with a `user_groups` condition that includes the filtered group. Users in this group are directly targeted by rules in this pack.
Dimmed pack	This pack has no rules with a `user_groups` condition matching this group. Its rules still apply to this group — they just apply to everyone equally.
No change (filter cleared)	All packs shown at equal prominence — no filter active.

What “dimmed” means for policy

Dimmed packs are not skipped for the filtered group. A pack being dimmed means none of its rules specifically target this group — but unconditional rules or rules with other condition types (entity_types, content_regex, channel, etc.) in that pack still apply to users in the filtered group.

Example:

A PCI-DSS compliance bundle pack contains a rule:

condition: entity_types=["CREDIT_CARD"]  →  BLOCK

This rule has no user_groups condition. It applies to every user, including users in the engineering group. The PCI-DSS pack will appear dimmed when filtering by engineering — but the rule still fires for engineering users who send prompts containing credit card numbers.

This is intentional behavior. The group filter highlights packs where group membership changes what happens. Packs that treat all users equally are dimmed to reduce visual noise — not because they are irrelevant.

Identifying direct rules vs universal rules

To see the actual rules inside a pack:

In the chain editor, click on a pack card to open the Pack Rule Editor for that pack.
Review each rule’s Conditions column.

Condition state	Rule type	Fires for filtered group?
`user_groups: ["finance", "accounting"]`	Direct — group-targeted	Only if user is in `finance` or `accounting`
`user_groups: ["finance"]` + `entity_types: ["SSN"]`	Direct + additional condition	Only if user is in `finance` AND SSN detected
No `user_groups` condition	Universal	For all users
`entity_types: ["CREDIT_CARD"]` (no `user_groups`)	Universal with other condition	For all users when CREDIT_CARD detected

A rule fires only when all of its conditions are satisfied. A rule with user_groups: ["finance"] and entity_types: ["SSN"] fires for finance users only AND only when SSN content is detected — not for all finance requests.

Auditing effective policy with the Policy Simulator

The group filter gives a structural view — it shows which packs have group-targeted rules. The Policy Simulator gives an execution view — it shows exactly what happens for a specific request from a user in a given group.

Running a group audit simulation

In the Policy Chain editor, set the group filter to the group you want to audit. This pre-populates the group name in session storage.
Navigate to Settings → Policies → Simulator.
Click Use chain filter to populate the User groups field with the filtered group name.
Enter a representative prompt for the type of request this group sends (e.g., a prompt with sensitive content, a routine work query, a prompt triggering a known rule condition).
Select the provider and model this group typically uses.
Click Simulate.

Reading simulation results for group policy

The evaluation trace shows every pack and rule evaluated in sequence:

Rows with a group match badge indicate that the rule’s user_groups condition was a factor in matching. This shows you exactly which group-targeted rules fired.
Rows without a group match badge that still show as matched fired due to other conditions (entity detection, content regex, etc.).
Rows shown as skipped were not reached (in first_applicable mode, because an earlier terminal rule fired).

Run multiple simulations with different prompt content to build a complete picture of the group’s enforcement posture:

Test prompt type	What it reveals
Routine prompt, no sensitive content	Whether the group is subject to unconditional rules (e.g., a “default deny” pack)
Prompt with PII (SSN, credit card)	Whether DLP bundle rules fire for this group and what action they produce
Prompt that should trigger a group exception	Verifies the group’s bypass rules are positioned before blocking rules
Prompt from a different channel (API vs interactive)	Reveals PROMPT rules that only fire in interactive channel

Common group policy patterns

Group exception before a global block

A common pattern is allowing a privileged group to bypass a rule that applies to all others:

Pack 1: "Privileged group exceptions"
  Rule 1: user_groups=["security-team"] → ALLOW

Pack 2: "Global content policy"
  Rule 1: entity_types=["SOURCE_CODE"] → BLOCK

With first_applicable combining algorithm, security team members match Pack 1 Rule 1 and the global block in Pack 2 is never reached. All other users fall through to Pack 2.

To verify this pattern using the group filter:

Filter by security-team → Pack 1 is highlighted (has a direct rule for this group)
Run simulation with prompt containing source code, user groups = ["security-team"] → result should be ALLOW with trace showing Pack 1 Rule 1 as the terminal match

To verify all other users still get blocked: Run simulation with same prompt but empty user groups → result should be BLOCK from Pack 2.

Group-specific routing

Route requests from a specific group to a different model tier:

Pack 1: "Tier routing by group"
  Rule 1: user_groups=["premium"], intent_complexity=["complex"] → ROUTE_TO opus
  Rule 2: user_groups=["basic"] → ROUTE_TO haiku

Group filter behavior: Pack 1 appears highlighted when filtering by either premium or basic. The two rules within the pack have different group targets — the filter shows the pack as relevant but does not distinguish which rule matched. Use the simulator to confirm which rule fires for a given group.

Compliance rules that apply to specific groups

Some compliance requirements apply only to regulated business units:

Pack 1: "Finance DLP"
  Rule 1: user_groups=["finance"], entity_types=["ACCOUNT_NUMBER"] → REDACT

Pack 2: "Global DLP"
  Rule 1: entity_types=["SSN"] → BLOCK

Pack 1 is highlighted when filtering by finance. Pack 2 is dimmed (no user_groups condition) but still applies to finance users. A finance user who sends a prompt with both an account number and an SSN triggers Pack 1 Rule 1 (REDACT, non-terminal) and then Pack 2 Rule 1 (BLOCK).

Checking group membership

The group filter in the chain editor accepts group names. Group names must match exactly what is stored in Arbitex — they are case-sensitive. To find the exact name:

Via UI: Settings → Users → Groups — group names are listed with their exact IDs and display names
Via API: GET /api/admin/groups — returns group list with name and id fields

If the group filter shows no packs highlighted, check that the group name matches exactly (including case and spacing). Groups provisioned via SCIM use the name as provided by the IdP — verify against your IdP’s group name.