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 on the right side of the policy page, 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 on the left, 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 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 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.
      3. Enter the comparison value. When you click the value field, the editor can suggest 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 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. You can also click the tag 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.
   • 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 tag icon next to the dropdown to tag the event.

6. Add another rule by clicking + Access rule.

7. Change the execution order by dragging rules with 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. 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.

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.

A tag icon appears next to both the Then and Else action dropdowns in the rule editor. Click the tag 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 tags from all matched rules 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.

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 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 uses three access rules. The first two rules detect independent risk signals. The third rule checks the rules.matched condition to identify whether both earlier rules matched, and blocks the request when they did.

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"
          }
        }
      }
    }
  }
}

Rule execution order

AIDR evaluates rules in the order they appear.

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

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.