Risk Scoring¶

ARX computes a dynamic risk score between 0 and 100 for every agent connector call. The score drives policy verdicts: low scores are permitted, moderate scores may trigger escalation, and high scores lead to denial or mandatory human review. Risk scores are recorded in the audit log alongside every action, providing a continuous quantitative measure of agent risk exposure.

Scoring Algorithm¶

The risk score is the sum of four independent factors, capped at 100:

risk_score = min(operation_risk + connector_sensitivity + session_frequency + target_sensitivity, 100)

Each factor is computed from static lookup tables and runtime context. There are no machine-learning components; the algorithm is deterministic and auditable.

Factor 1: Operation Risk¶

The operation string (e.g., host:isolate, ticket:read) is parsed to extract the verb. If the operation uses colon-delimited syntax (noun:verb), the verb is the segment after the last colon. Otherwise, the first segment before an underscore is used.

Operations with unrecognized verbs receive a default weight of 20.

The weights reflect the blast radius of each operation type. Read operations are low-risk because they do not alter state. Write and update operations carry moderate risk. Destructive operations (delete, remove, quarantine) and containment actions (isolate, contain) carry the highest weight because they can cause immediate operational impact.

Factor 2: Connector Sensitivity¶

Each connector has a static sensitivity weight reflecting the criticality of the system it interfaces with:

Connectors not in the table receive a default weight of 15.

Identity providers (Okta) and network security tools (Palo Alto) carry the highest sensitivity because unauthorized changes to these systems can compromise the entire security posture. Collaboration tools (Slack, Jira) carry the lowest sensitivity.

Factor 3: Session Frequency¶

The number of actions the agent has performed in the current session adds incremental risk. This factor detects runaway loops, compromised agents, or unexpected behavioral patterns.

Session context is passed via the session_context parameter on every intercept call. The SDK tracks the action count for the current execution session and includes it automatically.

Factor 4: Target Sensitivity¶

The sensitivity classification of the target resource adds a context-dependent risk component:

Target sensitivity is determined by the caller based on the specific resource being accessed. For example, an agent reading a low-sensitivity Jira ticket contributes 0 points, while an agent modifying a critical Okta admin group contributes 35 points.

Unrecognized sensitivity values receive a default weight of 10.

Score-to-Verdict Mapping¶

The policy engine uses the risk score in two ways:

Per-Policy Threshold¶

Each policy rule has a configurable risk_threshold (default: 70). When an allow-type policy rule matches an action and the computed risk score meets or exceeds the threshold, the verdict is upgraded to ESCALATE. This allows administrators to set fine-grained tolerance levels per connector and action pattern.

Default Thresholds¶

When no policy rule matches, the engine applies fixed thresholds:

These defaults cannot be changed through the API. They serve as a safety net for agents and connectors that have not yet been covered by explicit policy rules.

Worked Examples¶

Example 1: Low-Risk Read¶

An agent reads a Jira ticket with low sensitivity, 5 prior session actions:

Verdict (default thresholds): PERMIT.

Example 2: High-Risk Containment¶

An agent isolates a CrowdStrike host with high sensitivity, 25 prior session actions:

Verdict (default thresholds): DENY. Even with an allow policy at risk_threshold: 70, this would escalate.

Example 3: Moderate Write¶

An agent creates a ServiceNow ticket with medium sensitivity, 8 prior session actions:

Verdict (default thresholds): ESCALATE. An allow policy with risk_threshold: 60 would permit this action instead.

Example 4: Okta User Deletion¶

An agent deletes an Okta user with critical sensitivity, 3 prior session actions:

Verdict: DENY under any threshold configuration.

Tuning Risk Scores¶

Risk scores are not directly tunable -- the operation weights and connector sensitivity tables are compiled into the application. The primary tuning mechanism is the risk_threshold field on policy rules.

To make a connector more permissive, create an allow policy with a high risk_threshold (e.g., 90). To make a connector more restrictive, create an allow policy with a low risk_threshold (e.g., 30) or use an escalate rule to bypass scoring entirely.

If the built-in weights do not match your organization's risk profile, contact your ARX deployment team to discuss custom weight tables.

Audit and Observability¶

Every risk score is recorded in the audit log as part of the connector.called event metadata. The score is available in the metadata.risk_score field. Use the audit log API to query historical risk scores for trend analysis, anomaly detection, or compliance reporting.