Policy Configuration

On the Policies page, you can define how AI traffic submitted to AIDR is inspected and controlled.

Each policy has a type that corresponds to a collector type. You can assign a policy to any

collector of the matching type that is registered in AIDR and deployed in your environment. Depending on the collector type, the rules defined within a policy can report, block, or transform data at different stages of the AI workflow.

You can use policies to determine which detections are applied to data flowing through the collector and whether any enforcement actions are taken.

Policies can be reused across multiple collectors of the same type. When you update a policy, changes apply to all collectors using that policy.

You can omit policy assignment entirely and use collectors for logging only.

Pre-configured policies

The Policies page displays default policies designed for common use cases. These policies serve as examples and starting points for your configurations.

Edit existing policies or create new ones to match your security requirements.

Create policy

1. On the Policies page, click + Policy.

2. In the Create a Policy dialog, provide:

   • Display name - Policy name as it appears in collector policy selectors

     Based on the display name, a unique policy identifier is generated and shown as Policy Key.

3. Click Save.

This creates a new policy and opens its details page.

To return to this page, click the policy name in the Policies list.

Configure policy rules

Event types

On the policy details page, you can configure rules applied to different event types in the AI application data flow. Then, in a request to AIDR APIs , you can pass the event_type parameter with a value supported by your collector.

Common event types

The input and output event types correspond to incoming (prompt) data and AI system responses. These event types are supported in all collectors, except the MCP collector.

If a collector doesn't specify an event type in its request to AIDR, input is applied by default.

You can specify a collection of policy rules for each event type:

• Input Rules - Inspect and control data sent to AI systems (prompts, tool responses, and similar content). You can use input rules to detect malicious prompts, sensitive data, and other risks before data reaches an AI provider.
• Output Rules - Inspect and control responses from AI systems (model completions, generated content, and similar output). You can use output rules to detect harmful content, leaked sensitive data, and other risks in AI-generated responses.

MCP events

The Agentic collector applies separate policies to different parts of MCP (Model Context Protocol) client-server communications:

• Tool Input Rules - Detect risks in data sent to MCP server tools.
• Tool Output Rules - Detect risks in MCP server responses.
• Tool Listing Rules - Detect risks in tool descriptions received from the MCP server.

Custom event types

The Application collector lets you specify additional event types. On the collector details page, click + Event Type to create rules for a custom event type.

Rules

Each collection of rules for an event type can be based on the request metadata and content exchanged with the AI system:

• Access rules - Evaluate request attributes at runtime to determine whether a request is allowed, denied, or reported.
• Prompt rules - Apply one or more detectors to the content submitted to and received from an AI system and report, block, or transform the data.

When a policy executes:

1. AIDR evaluates configured access rules. When a rule matches:

   • If the rule action is Report, AIDR captures the event and continues evaluation.
   • If the rule action is Block, execution halts and prompt rules are not evaluated.

2. If no access rules block execution, AIDR applies enabled prompt rules:

   • Runs configured detectors on the content.
   • Applies actions defined in the detectors (Block, Report, and detector-specific actions).

Report Only Mode

You can use Report Only Mode to evaluate policy rules and save results in logs without enforcing actions on end users or returning policy evaluation results to the collector.

This allows you to test policies and collect data for analysis without affecting user experience.

Example 200 response in Report Only Mode

{
  ...
  "status": "Success",
  "summary": "The payload has been accepted and will be processed asynchronously",
  "result": {}
}

How it works with existing rules

• Block - The block event is logged, but the request proceeds. Users aren't notified or interrupted.
• Transform/Redact (Replacement, Mask, etc.) - Transformations apply only to logged content for analysis. Users see the original, unmodified data.

The Status field in logs is set to Reported in either case.

Interpreting findings

When Report Only Mode is enabled, the logged content shows what the policy would have done if enforced in real time, not what users actually experienced. You can identify which findings were evaluated versus enforced by examining the Reported status.

Use cases:

• Test new policies in production without user impact.
• Tune detection rules before enforcement.
• Collect baseline data for policy development.

note:

Browser collector Output Rules are always applied in Report Only Mode.

View policy configuration activity

You can view changes in policy configuration on the Configuration Activity tab.

Manage policy options

Click the menu icon (⫶) in the policy list or on the policy details page to access the following options:

• Clone - Create a copy of the policy.
• Rename - Edit the policy name (available for custom policies and modified default policies).
• Delete - Remove or reset policies:
  • For a policy you created - Delete the policy.
  • For a default policy - Reset the policy to its default configuration.