Skip to main content

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:
      3. Enter the comparison value. When you click the value field, the editor suggests values from your data. 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 configuration icon next to the dropdown to configure action settings.

    • 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.

    • Allow and Stop - Allow the request, log the event, and stop policy execution.

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

    ActionStatusSummaryRule detectedRule actionExecution
    ContinuereportedThe operation was completed successfully.falseallowedContinues
    Report and Continuereported<rule-name> matched and reported.truereportedContinues
    Report and Stopreported<rule-name> matched and reported then stopped.truereportedStops
    Block and Stopblocked<rule-name> matched and blocked.trueblockedStops
    Ignore and StopN/AN/AN/AN/AStops
    Allow and Stopallowed<rule-name> matched and allowed then stopped.falseallowedStops
    note:

    The Status and Summary columns show the final event-level values when this is the last rule to execute. If execution continues, subsequent rules or detectors override these values.

  5. In the Else dropdown, select the action to execute when the rule doesn't match. You can also click the configuration icon next to the dropdown to configure action settings.

  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:

Configure action settings​

In the rule editor, click the configuration icon next to the Then or Else action dropdown to open action settings. You can tag events and exclude prompt content from logged events.

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.

Under Tag Event, select from predefined tags or enter a custom tag name.

  • Predefined tags:

    • Critical
    • High
    • Medium
    • Low
    • Information

  • Custom tags:

    Enter a custom tag name in the tag selector and click + or press Enter. You must enter custom tags manually each time - they don't appear as selectable options even if previously used in event 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 and in Next-Gen SIEM. For more information, see Visibility and Monitoring .

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

note:

When you select Ignore and Stop, tags and prompt content settings are unavailable because AIDR doesn't log the event.

Exclude prompt content​

You can exclude prompt content from the logged event while still recording event metadata. Enable Exclude Prompt Content in action settings to omit user request and LLM response body data from the AIDR log.

note:

This setting overrides the collector-level logging configuration for matched events.

Custom block messages​

In browser collector policies, you can assign custom messages that end users see when AIDR blocks or transforms a request. You can reuse custom messages across policies in the same account (CID). Each detector supports one block message and one transform message. These messages apply to all rules with the respective action in that detector.

You can manage custom messages in the Block Message or Transform Message dialog:

  1. Hover over the message icon on the action label - Block, Transform, or Defang - to preview the currently assigned message in a tooltip. You can also access the dialog from the Manage User Messaging menu in the expanded rule.
  2. Click the message icon to open the dialog.
  3. Click the Select message dropdown to display existing messages and available controls. A custom message assigned to the detector displays a CURRENT badge.
    • To assign a message, select one from the list, optionally edit it in the text area, and click Update. The dialog closes.
    • To create a message, click + Create New Message, enter the message text, and click + Save. The dialog closes.
    • To hide the browser extension popup while still performing the action, select Do not show a message.
    • To show the AIDR response summary instead, select Use summary as message.
    • To show a standard redaction message for transform actions, select Use standard redaction message.
    • To set the account-wide default for the message type, Block or Transform, 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 blocks or transforms a request, it determines which message to return:

  1. If the detector has a message assigned, AIDR returns that message.
  2. Otherwise, AIDR returns the default set for that message type.

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

note:

Changes to custom messages or account defaults can take several minutes to propagate because of 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.

ConditionOperatorValue
Report suspicious activity (rule name)
user.id== ▼dennis.nedryAnd ▼ (logical operator) ⊖ (remove expression)
app.app_id== ▼securityAnd + (add expression) ⊖ (remove expression)
Or ▼ (logical operator)
model.model_name== ▼DeepSeekOr + (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
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.
ConditionOperatorValue
Remove PII (rule name)
app.app_id== ▼ingen-chatbotAnd ▼ (logical operator) ⊖ (remove expression)
prompt.detectionsexecutes ▼confidential_and_pii_entity.us_ssnAnd + (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
)

Custom Entity rule reference​

This rule blocks requests that contain competitor references detected by a Custom Entity rule, except for a specific user. The Custom Entity rule uses a regex pattern ([Bb]io[-\s]?[Ss]yn) to match variations of the competitor name, including common misspellings.

The has operator references a specific Custom Entity rule by its identifier (custom_entity.biosyn).

  • When the prompt contains a match for the biosyn Custom Entity rule and the user is not john.hammond, the rule blocks the request.
  • When the condition doesn't match, execution continues to the next rule.
ConditionOperatorValue
Block competitor references (rule name)
prompt.detectionshas ▼custom_entity.biosynAnd ▼ (logical operator) ⊖ (remove expression)
user.id!= ▼john.hammondAnd + (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
prompt.detections has custom_entity.biosyn
and user.id != john.hammond
)

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
    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
    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.

    ConditionOperatorValue
    PII exposed to Contractors (rule name)
    rules.matchedincludes ▼contractors_access_hrAnd ▼ (logical operator) ⊖ (remove expression)
    rules.matchedincludes ▼pii_exposedAnd + (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
    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. 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 normalizes request values before matching. Spaces become 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.

ConditionOperatorValue
Block patient room chatbot users (rule name)
user.groupsincludes ▼custom:patient_room_chatbotAnd + (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
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 Manage Memberships, 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. AIDR applies 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.

ConditionOperatorValue
Block non-DNS Admins (rule name)
user.groupsexcludes ▼entra:d753f19e-0dcc-4697-a878-8faecf5513f8And + (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
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. AIDR applies 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.

ConditionOperatorValue
Block regular users (rule name)
user.idp.entra.department== ▼UsersAnd + (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
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 your changes. 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.

©2026 CrowdStrike. All rights reserved.

PrivacyTerms of UseLegal Notices