Access Rules

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

Assistant

You can use the Assistant pane on the right side of the policy rule tabs to create access rules by describing conditions in natural language. Start with the Assistant for quick setup, then use the editor for more precise control.

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

You can use the access rules editor on the left to create new rules and update existing 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 and 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 the top-down order as displayed in the AIDR console. 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, combined using AND and OR logic:

1. Enter a rule name.

2. Create a condition.

   1. Create an expression (a single comparison):
      1. Click the expression field on the left 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 is found in a comma-separated list of allowed values.
           • 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 produced a finding.
           • not has - Specified detector rule did not produce a finding.
           • executes - Triggers prompt rule execution as part of this access rule evaluation.
      3. Enter a value against which this expression is evaluated. When you click the value field, the editor may suggest existing values from your data (known user IDs, application names, etc.) or internal lookup tables.
   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 and dropping individual expressions using their six-dot handle on the left.

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:

   • 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.
   • Ignore and Stop - Allow the request and stop policy execution without logging.

   The following table shows the AIDR Findings event values and execution behavior for each action:

   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.

6. Add another rule by clicking + Access rule.

7. Change the execution order by dragging and dropping individual rules using their six-dot handle on the left.

8. Click Update at the bottom of the rule editor to apply changes to the policy.

note:

If you define conditions based on prompt content (prompt.detections), you must also enable the corresponding detectors and configure referenced rules under the Prompt Rules tab. If you reference a detector in access rules without enabling it, the console prompts you to enable it.

Examples

Request metadata

This rule matches requests from user dennis.nedry@ingen.com to the security application, or requests using the DeepSeek model. When matched, it reports the detection and continues to the next rule. If not matched, execution continues to the next rule.

Condition	Operator	Value
Report suspicious activity (rule name)
user.user_id	== ▼	dennis.nedry@ingen.com	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 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 (
    user.user_id == dennis.nedry@ingen.com
    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 only for 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, the request is allowed and policy execution stops 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 app.app_id == ingen-chatbot
  and prompt.detections executes confidential_and_pii_entity.us_ssn

Rule execution order

AIDR evaluates rules in the order they appear.

You can change the order by dragging and dropping rules using their six-dot handle on the left.

Save policy changes

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

Default action

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

tip:

You can test access rules using Policy Testing.