Access Rules

You can configure access rules in a policy to evaluate request attributes at runtime and allow, block, or report requests.

Assistant

In the Assistant tab, you can create access rules by describing conditions in natural language. You can start with the Assistant for quick setup, then refine rules in the editor.

To submit a rule request:

1. Describe the rule you want in the Assistant input field.
2. Press Enter or click the arrow button to submit your request.

Access rules editor

In the access rules editor, you can create and update rules, including those created by the Assistant.

Add access rule

If you see the No Access Rules Enabled section on the event type tab, click + Create first access rule to open the rule editor.

After you create the first rule, the section label changes to Execute Access Rules. The rule appears as a movable card.

Click the pencil icon to open the rule editor and update the rule.

Click + Access rule to add more rules.

note:

AIDR evaluates access rules sequentially and independently, in top-down order. Each rule produces its own result, and any rule with a Stop action halts execution.

Edit access rule

In the rule editor, you can create one or more conditions based on request attributes. Combine conditions with AND and OR logic:

1. Enter a rule name.

2. Create a condition.

   1. Create an expression (a single comparison):
      1. Click the attribute field to view available attributes.
      2. Select a comparison operator for:
         • Request metadata attributes:
           • == - Value equals the specified string exactly. Use @null to match null or missing values, or @empty to match empty strings.
           • != - Value does not equal the specified string. Use @null to exclude null or missing values, or @empty to exclude empty strings.
           • > - Value is greater than the specified number.
           • >= - Value is greater than or equal to the specified number.
           • < - Value is less than the specified number.
           • <= - Value is less than or equal to the specified number.
           • in - Value matches one of the values in a comma-separated list.
           • contains - Value contains the specified text as a substring.
           • not contains - Value does not contain the specified text as a substring.
           • matches - Value matches the specified RE2 regular expression pattern.
           • not matches - Value does not match the specified RE2 regular expression pattern.
         • Prompt content-based:
           • has - Specified detector rule produces a finding.
           • not has - Specified detector rule doesn't produce a finding.
           • executes - Triggers prompt rule execution as part of this access rule evaluation.
         • Rules matched reference:
           • includes - Specified rule appears in previously matched rules.
           • excludes - Specified rule does not appear in previously matched rules.
         • Group membership:
           • includes - Subject belongs to the selected group.
           • excludes - Subject does not belong to the selected group.
         • Identity provider attributes (user.idp.entra.<attribute>, user.idp.ad.<attribute>):
           • Standard comparison operators (==, !=, contains, not contains, matches, not matches, in)
      3. Enter the comparison value. When you click the value field, the editor suggests values from your data or from internal lookup tables. Suggested values include known user IDs and application names.
   2. Add another expression to the condition:
      1. Click Or + or And + next to an existing expression.
      2. Select an AND or OR logical operator to combine expressions.
   3. Change the execution order by dragging expressions with their six-dot handle.

3. Add another condition to the rule:

   1. Click Add Condition +.
   2. Select an AND or OR logical operator to combine conditions.

4. In the Then dropdown, select the action to execute when the rule matches. You can also click the adjustment icon next to the dropdown to tag the event.

   • Continue - Proceed to the next rule without flagging this rule as a detection.

   • Report and Continue - Flag this rule as a detection and continue to the next rule.

   • Report and Stop - Flag this rule as a detection and stop policy execution.

   • Block and Stop - Block the request, flag this rule as a detection, and stop policy execution.

     See Block messages for details on customizing a Block action response in browser collector policies.

   • Ignore and Stop - Allow the request and stop policy execution without logging.

   Each action produces these AIDR Findings event values and execution behavior:

   Action	Status	Summary	Rule detected	Rule action	Execution
   Continue	Reported	The operation was completed successfully.	false	allowed	Continues
   Report and Continue	Reported	Execute matched and reported.	true	reported	Continues
   Report and Stop	Reported	Execute matched and reported.	true	reported	Stops
   Block and Stop	Blocked	Execute matched and blocked.	true	blocked	Stops
   Ignore and Stop	N/A	N/A	N/A	N/A	Stops

5. In the Else dropdown, select the action to execute when the rule doesn't match. You can also click the adjustment icon next to the dropdown to tag the event.

6. Click + Access rule to add another rule.

7. Change the execution order by dragging rules with their six-dot handle.

8. Click Update to apply changes to the policy.

note:

• If you define conditions based on prompt content (prompt.detections), you must also enable the corresponding detectors. Configure referenced rules in the Execute Prompt Rules section. For details, see Prompt Rules . If you reference a detector in access rules without enabling it, the console prompts you to enable the detector.

• The rules.matched attribute references other access rules by their identifier. AIDR populates this attribute as each rule executes. A rule can reference only rules that appear earlier in the execution order. For an example, see Rules matched reference.

• The user.groups, app.groups, and model.groups attributes represent group membership. Use these attributes with the includes or excludes operators to match requests by group.

  For user.groups, group values include a prefix that identifies the source:

  • custom: - Groups managed in AIDR (for example, custom:patient_room_chatbot)
  • entra: - Groups synced from Microsoft Entra ID (for example, entra:d753f19e-0dcc-4697-a878-8faecf5513f8)
  • ad: - Groups synced from Active Directory (for example, ad:f369484c076c43ceab6fa1cc1e240a9f)

  Application and model groups are always custom and use the custom: prefix.

  For an example, see Group membership. To create and manage groups, see Memberships in Settings.

Tag events

You can tag events with custom labels to classify them for filtering and analysis. Tags apply regardless of whether AIDR reports or blocks the event. Use tags for severity levels, compliance exceptions, or custom workflows.

An adjustment icon appears next to both the Then and Else action dropdowns in the rule editor. Click the icon to open the tag selector. You can select from predefined tags or type a custom tag name.

• Predefined tags:

  • Critical
  • High
  • Medium
  • Low
  • Information

• Custom tags:

  Type a custom tag name in the tag selector and click + or press Enter. You must type custom tags manually each time - they don't appear as selectable options even if present in logs.

Tags appear in the AIDR Findings table under the TAGS column and in event logs under the Tags field. You can filter events by tag values on the Visibility and Findings pages.

When multiple rules match a request, AIDR combines their tags into a single, deduplicated list in the event log.

note:

When the action is Ignore and Stop, tags are unavailable because AIDR doesn't log the event.

Block messages

In browser collector policies, you can assign a custom block message to display to end users when AIDR triggers a Block action. Block messages apply across the account (CID). You can reuse them across policies.

You can manage custom block messages in the BLOCK MESSAGE dialog:

1. Hover over the message icon in the Block action label to preview the currently assigned message in a tooltip.
2. Click the message icon to open the BLOCK MESSAGE dialog.
3. Click the Select block message dropdown to display existing messages and available controls. A currently assigned message displays a CURRENT badge.
   • To assign an existing message, select one from the EXISTING BLOCK MESSAGES list, optionally edit the message in the Block Message text area, and click Update. The dialog closes.
   • To create a new message, click + Create New Block Message, enter the message text in the Block Message text area, and click + Save. The dialog closes.
   • To show the AIDR response summary instead, select Use Summary as Block Message.
   • To set the account-wide default, click the star icon next to a message. A filled star indicates the current default.
   • To delete a message, click the trash icon (🗑️) next to it. You cannot delete a message that is currently assigned or set as the account default.

When AIDR triggers a Block action, it determines which message to return:

1. If the rule has a block message assigned, AIDR returns that message.
2. Otherwise, if the account has a default block message set, AIDR returns the default.
3. Otherwise, AIDR returns the response summary field.

The display_message field in the API response returns the resolved message text.

note:

Changes to block messages or the account default can take several minutes to take effect due to caching.

Examples

Request metadata

This rule matches requests from user dennis.nedry to the security application. The rule also matches requests that specify the DeepSeek model. When matched, it tags the event as High and reports the detection, then continues to the next rule. If the rule doesn't match, execution continues to the next rule.

Condition	Operator	Value
Report suspicious activity (rule name)
user.id	== ▼	dennis.nedry	And ▼ (logical operator) ⊖ (remove expression)
app.app_id	== ▼	security	And + (add expression) ⊖ (remove expression)
Or ▼ (logical operator)
model.model_name	== ▼	DeepSeek	Or + (add expression) ⊖ (remove expression)
Add Condition +
Then ≡ High Report and Continue ▼ Else ≡ Continue ▼
🗑️ | Cancel | Update

+ Access rule

After you click Update, the rule editor closes and displays the rule definition in a structured format:

if (

then ≡ High | Report else Continue

user.id == dennis.nedry

and app.app_id == security

)

or model.model_name == deepseek

Request metadata and prompt rules

This rule executes the US Social Security Number prompt rule from the Confidential and PII Entity detector. The access rule applies only to requests from the ingen-chatbot application.

• When the request matches the ingen-chatbot condition, AIDR applies the action configured for the US Social Security Number prompt rule. The access rule then reports the detection and continues to the next rule.
• When the condition doesn't match, AIDR allows the request and stops policy execution without logging.

Condition	Operator	Value
Remove PII (rule name)
app.app_id	== ▼	ingen-chatbot	And ▼ (logical operator) ⊖ (remove expression)
prompt.detections	executes ▼	confidential_and_pii_entity.us_ssn	And + (add expression) ⊖ (remove expression)
Add Condition +
Then ≡ Report and Continue ▼ Else ≡ Ignore and Stop ▼
🗑️ | Cancel | Update

After you click Update, the rule editor displays the rule definition as:

if (

then Report else Ignore and Stop

app.app_id == ingen-chatbot

and prompt.detections executes confidential_and_pii_entity.us_ssn

)

Rules matched reference

This Output event type example demonstrates three access rules. The first two rules detect independent risk signals. The third rule evaluates the rules.matched condition to determine whether both earlier rules matched. When both match, the third rule blocks the request.

Neither signal alone warrants blocking. Contractors legitimately access the HR chatbot, and some PII may be allowed for permanent employees. The combination of both signals - a contractor account and exposed PII in the same request - warrants blocking.

• Rule 1 - Contractors access HR (contractors_access_hr):

  This rule matches when contractor accounts access the HR chatbot. When matched, it reports the detection and continues to the next rule.

  if (

  then Report else Continue
  user.id matches ^contractor
  and app.app_id == hr-chatbot
  )

• Rule 2 - PII exposed (pii_exposed):

  This rule matches when the model response contains PII entities, such as email addresses, phone numbers, or person names. When matched, it reports the detection and continues to the next rule.

  if (

  then Report else Continue
  prompt.detections has confidential_and_pii_entity.email_address
  or prompt.detections has confidential_and_pii_entity.phone_number
  or prompt.detections has confidential_and_pii_entity.person
  )

• Rule 3 - PII exposed to Contractors (pii_exposed_to_contractors):

  This rule matches when both earlier rules matched - indicating a contractor receives a response containing PII through the HR chatbot. When matched, it blocks the request.

  Condition	Operator	Value
  PII exposed to Contractors (rule name)
  rules.matched	includes ▼	contractors_access_hr	And ▼ (logical operator) ⊖ (remove expression)
  rules.matched	includes ▼	pii_exposed	And + (add expression) ⊖ (remove expression)
  Add Condition +
  Then ≡ Block and Stop ▼ Else ≡ Continue ▼
  🗑️ | Cancel | Update

  After you click Update, the rule editor displays the rule definition as:

  if (

  then Block else Continue
  rules.matched includes contractors_access_hr
  and rules.matched includes pii_exposed
  )

Example response from AIDR APIs

{
  ...
  "status": "Success",
  "summary": "PII exposed to Contractors matched and blocked.  Contractors access HR matched and reported.  PII exposed matched and reported.  Confidential and PII Entity was detected and reported.",
  "result": {
    "blocked": true,
    "transformed": false,
    "policy": "k_t_boundary_output_policy",
    "detectors": {
      "confidential_and_pii_entity": {
        "detected": true,
        "data": {
          "entities": [
            {
              "action": "reported",
              "type": "PHONE_NUMBER",
              "value": "555-555-5555"
            },
            {
              "action": "reported",
              "type": "EMAIL_ADDRESS",
              "value": "ed.regis@ingen.com"
            },
            {
              "action": "reported",
              "type": "PERSON",
              "value": "Ed Regis"
            }
          ]
        }
      }
    },
    "access_rules": {
      "contractors_access_hr": {
        "detected": true,
        "matched": true,
        "action": "reported",
        "name": "Contractors access HR",
        "attributes": {
          "app": {
            "app_id": "hr-chatbot"
          },
          "user": {
            "id": "contractor.dennis.nedry"
          }
        }
      },
      "pii_exposed": {
        "detected": true,
        "matched": true,
        "action": "reported",
        "name": "PII exposed",
        "attributes": {
          "app": {
            "app_id": "hr-chatbot"
          },
          "user": {
            "id": "contractor.dennis.nedry"
          }
        }
      },
      "pii_exposed_to_contractors": {
        "detected": true,
        "matched": true,
        "action": "blocked",
        "name": "PII exposed to Contractors",
        "attributes": {
          "app": {
            "app_id": "hr-chatbot"
          },
          "user": {
            "id": "contractor.dennis.nedry"
          }
        }
      }
    }
  }
}

Group membership

The following examples show group membership conditions for custom and external identity provider groups.

Custom groups

AIDR matches group members against the following request parameters, where a match on either field satisfies the condition:

• User groups - user_id and extra_info.user_name
• Application groups - app_id and extra_info.app_name
• Model groups - model and llm_provider

AIDR converts request parameters to tuple identifier format before matching and replaces spaces with underscores. For example, Jeffrey Goines matches Jeffrey_Goines.

This rule blocks requests from users who belong to the patient_room_chatbot group. It uses the user.groups attribute with the includes operator to check group membership.

Condition	Operator	Value
Block patient room chatbot users (rule name)
user.groups	includes ▼	custom:patient_room_chatbot	And + (add expression) ⊖ (remove expression)
Add Condition +
Then ≡ Block and Stop ▼ Else ≡ Continue ▼
🗑️ | Cancel | Update

After you click Update, the rule editor displays the rule definition as:

if (

then Block else Continue

user.groups includes custom:patient_room_chatbot

)

When this rule matches, the API response includes the access rule result:

Example response from AIDR APIs

{
  ...
  "summary": "Patient room Chatbot matched and blocked.",
  "result": {
    "blocked": true,
    "access_rules": {
      "patient_room_chatbot": {
        "detected": true,
        "matched": true,
        "action": "blocked",
        "name": "Patient room Chatbot"
      }
    }
  }
}

When you click the value field for a group membership expression, the editor opens a group browser. The group browser shows tabs for each available source:

• Custom - Click Browse Custom Groups to select a group managed in AIDR.
• Entra ID - Click Browse Entra ID Groups to select a group synced from Microsoft Entra ID.
• Active Directory - Click Browse Active Directory Groups to select a group synced from Active Directory.

For app.groups and model.groups, the only available option is Browse Custom Groups.

Browse Custom Groups opens the Manage Memberships dialog, where you can create groups or manage group members directly, using the + Create Group and Manage Members buttons.

For more information, see Memberships in Settings.

External identity provider groups

For Entra ID and Active Directory users synced through Falcon Identity Protection, AIDR resolves group membership by matching request user_id and extra_info.user_name values against the synced user's email, user principal name, and user ID, and uses the first match.

This rule blocks requests from users who do not belong to a specific Entra ID group. It uses the user.groups attribute with the excludes operator to check external group membership.

Condition	Operator	Value
Block non-DNS Admins (rule name)
user.groups	excludes ▼	entra:d753f19e-0dcc-4697-a878-8faecf5513f8	And + (add expression) ⊖ (remove expression)
Add Condition +
Then ≡ Block and Stop ▼ Else ≡ Continue ▼
🗑️ | Cancel | Update

After you click Update, the rule editor displays the rule definition as:

if (

then Block else Continue

user.groups excludes entra:d753f19e-0dcc-4697-a878-8faecf5513f8

)

When this rule matches, the API response includes the access rule result:

Example response from AIDR APIs

{
  ...
  "summary": "Block non-DNS Admins matched and blocked.",
  "result": {
    "blocked": true,
    "access_rules": {
      "block_non_dns_admins": {
        "detected": true,
        "matched": true,
        "action": "blocked",
        "name": "Block non-DNS Admins"
      }
    }
  }
}

Identity provider attributes

You can create access rule conditions based on user attributes synced from external identity providers. AIDR resolves the user's identity provider record by matching the request user_id and extra_info.user_name values against the synced user's email, user principal name, and user ID, and uses the first match.

To create a condition based on an identity provider attribute:

1. Click the attribute field and select User > idp attributes.
2. Select entra id or active directory.
3. Select a specific attribute (for example, department).
4. Select a comparison operator.
5. Enter the comparison value.

The attribute path in the rule expression is user.idp.entra.<attribute> for Entra ID or user.idp.ad.<attribute> for Active Directory.

The following rule blocks requests from users whose Entra ID department attribute equals Users.

Condition	Operator	Value
Block regular users (rule name)
user.idp.entra.department	== ▼	Users	And + (add expression) ⊖ (remove expression)
Add Condition +
Then ≡ Block and Stop ▼ Else ≡ Continue ▼
🗑️ | Cancel | Update

After you click Update, the rule editor displays the rule definition as:

if (

then Block else Continue

user.idp.entra.department == Users

)

When this rule matches, the API response includes the access rule result:

Example response from AIDR APIs

{
  ...
  "summary": "Block regular users matched and blocked.",
  "result": {
    "blocked": true,
    "access_rules": {
      "block_regular_users": {
        "detected": true,
        "matched": true,
        "action": "blocked",
        "name": "Block regular users"
      }
    }
  }
}

For more information, see Users in Settings.

Rule execution order

AIDR evaluates rules in the order they appear.

You can change the order by dragging rules with their six-dot handle.

Save policy changes

After you change a policy, click Save Changes in the bar at the bottom of the page to apply them. If you navigate away without saving, AIDR prompts you to save or discard your changes.

Default action

If no access rules match, AIDR evaluates configured prompt rules.

tip:

Test access rules in the Sandbox on the policy page, or in the Playground on the Application collector page.