Outlier Detection

Configure outlier detection settings to identify anomalous access patterns in Access Reviews.

Early Access Feature: Outlier Detection is currently in Early Access and available via API only. The feature and API are subject to change. Contact your Veza Customer Success Manager to enable this feature for your tenant.

Configure outlier detection to automatically identify and flag anomalous access patterns during Access Reviews. The Manager-Centric algorithm compares each user's access to their peer group and detects access held by fewer than a specified threshold percentage of peers, helping reviewers focus on unusual or potentially risky permissions.

How Outlier Detection Works

The Manager-Centric outlier detection algorithm uses statistical analysis to identify rare access patterns:

Peer Grouping: Users are grouped based on configurable properties (default: users sharing the same manager)
Statistical Analysis: For each destination (resource/permission) in the review, Veza calculates what percentage of the peer group has access using the Wilson score confidence interval method at 95% confidence
Threshold Comparison: Access paths where the statistical lower bound is at or below the configured threshold are flagged as outliers
Reviewer Visibility: Flagged items are highlighted in the reviewer interface with explanations indicating the access is rare within the peer group

Default Behavior

By default, outlier detection uses:

Grouping: Users with the same manager (manager_idp_unique_id property)
Threshold: 15% (access held by ≤15% of peers is flagged as an outlier)

Example Scenario

Consider an Access Review for Okta groups:

100 users report to Manager A
95 of them have access to the "Engineering-All-Hands" group
5 users have access to the "Admin-Production-Access" group

Given a 15% threshold:

"Engineering-All-Hands" access (95% of peers) is not flagged, as this is normal access
"Admin-Production-Access" (5% of peers) is flagged as an outlier, as this is rare access

The reviewer sees a warning on those 5 rows that this access is anomalous within the peer group — no more than 15% of peers with shared characteristics have it.

API Endpoints

Administrators can customize outlier detection using APIs:

Get Outlier Detection Configuration

GET /api/private/workflows/access/global_settings/manager_centric_config

Retrieve the current outlier detection configuration, either globally or for a specific review configuration.

Parameters

Name

Type

Required

Description

workflow_id

string

query

Review configuration ID. If specified, returns the configuration for that specific review configuration. If omitted or empty, returns the global configuration.

Example: Get Global Configuration

curl 'https://your-organization.vezacloud.com/api/private/workflows/access/global_settings/manager_centric_config' \
  -H 'Authorization: Bearer YOUR_BEARER_TOKEN' \
  -H 'Content-Type: application/json'

Example: Get Configuration for Specific Review

curl 'https://your-organization.vezacloud.com/api/private/workflows/access/global_settings/manager_centric_config?workflow_id=8ae1c414-3a76-46cb-950a-925316b3f264' \
  -H 'Authorization: Bearer YOUR_BEARER_TOKEN' \
  -H 'Content-Type: application/json'

Response

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "manager_idp_unique_id"
      }
    ],
    "threshold": 0.15
  }
}

Set Outlier Detection Configuration

PUT /api/private/workflows/access/global_settings/manager_centric_config

Update the outlier detection configuration globally or for a specific review configuration.

Parameters

Name

Type

Required

Description

workflow_id

string

Review configuration ID. If specified, applies settings only to that configuration. If omitted, updates the global default.

value

object

Yes

Configuration object

value.grouping_properties

array

Array of property references defining how to group users into peer groups. If empty, uses population-wide comparison. See Grouping Properties below.

value.threshold

number

Yes

Threshold percentage (0.0 to 1.0) below which access is considered an outlier. For example, 0.15 means access held by ≤15% of peers is flagged.

Example: Set Global Configuration

curl -X PUT 'https://your-organization.vezacloud.com/api/private/workflows/access/global_settings/manager_centric_config' \
  -H 'Authorization: Bearer YOUR_BEARER_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "value": {
      "grouping_properties": [
        {
          "property_name": "department",
          "target": "TARGET_NODE_SOURCE"
        },
        {
          "property_name": "location",
          "target": "TARGET_NODE_SOURCE"
        }
      ],
      "threshold": 0.1
    }
  }'

Example: Set Configuration for Specific Review

curl -X PUT 'https://your-organization.vezacloud.com/api/private/workflows/access/global_settings/manager_centric_config' \
  -H 'Authorization: Bearer YOUR_BEARER_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "8ae1c414-3a76-46cb-950a-925316b3f264",
    "value": {
      "grouping_properties": [
        {
          "property_name": "manager_idp_unique_id"
        }
      ],
      "threshold": 0.2
    }
  }'

Response

{}

Grouping Properties

Grouping properties define how users are organized into peer groups for outlier analysis. You can specify properties from:

Source nodes (the users/identities in the review)
Destination nodes (the resources/permissions being reviewed)
Enriched/joined nodes (additional data joined to the query, such as manager information from an IdP)

Property Reference Schema

Each property reference has these fields:

Field

Type

Required

Description

property_name

string

Yes

The name of the property to group by (e.g., "department", "location", "manager_idp_unique_id")

target

enum

Where the property comes from. Options: TARGET_NODE_UNSPECIFIED (default, assumes source), TARGET_NODE_SOURCE, TARGET_NODE_DESTINATION, TARGET_NODE_JOINED

joined_node_alias

string

Conditional

Required when target is TARGET_NODE_JOINED. The alias of the joined node from the review query's JoinNodeSpec

Target Node Types

SOURCE Node Properties

Properties from the source entities in the review (typically users/identities).

Common source properties:

department - User's department
location - User's location
manager_idp_unique_id - User's manager identifier (default)
is_active - Whether the user account is active
employee_type - Employee classification (e.g., full-time, contractor)

Example:

{
  "property_name": "department",
  "target": "TARGET_NODE_SOURCE"
}

DESTINATION Node Properties

Properties from the destination entities (resources/permissions being reviewed).

Common destination properties:

classification - Resource classification level
data_sensitivity - Data sensitivity level
owner - Resource owner
environment - Environment (prod, dev, test)

Example:

{
  "property_name": "classification",
  "target": "TARGET_NODE_DESTINATION"
}

JOINED Node Properties (Enrichment)

Properties from enriched/joined metadata from another data source. These require the review query to include a JoinNodeSpec that joins additional data (such as manager information from an IdP).

Example:

{
  "property_name": "department",
  "target": "TARGET_NODE_JOINED",
  "joined_node_alias": "manager"
}

This groups all users by their manager's department, requiring the review query to join the manager data with the alias "manager".

Configuration Examples

Example 1: Default Manager-Based Grouping

Groups users by manager with a 15% threshold (default configuration):

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "manager_idp_unique_id"
      }
    ],
    "threshold": 0.15
  }
}

Use case: Identify access that's unusual compared to direct peers reporting to the same manager.

Example 2: Department and Location Grouping

Groups users by both department and location with a 10% threshold:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "department",
        "target": "TARGET_NODE_SOURCE"
      },
      {
        "property_name": "location",
        "target": "TARGET_NODE_SOURCE"
      }
    ],
    "threshold": 0.1
  }
}

Use case: Identify access that's rare among users in the same department and office location.

Example 3: No Grouping (Population-Wide)

Compares each user to the entire population with 5% threshold:

{
  "value": {
    "grouping_properties": [],
    "threshold": 0.05
  }
}

Use case: Flag extremely rare access across the entire organization, regardless of role or department.

Example 4: Resource Classification Grouping

Groups by destination resource classification with a 20% threshold:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "classification",
        "target": "TARGET_NODE_DESTINATION"
      }
    ],
    "threshold": 0.2
  }
}

Use case: Identify unusual access patterns within resources of the same classification level.

Example 5: Manager's Department (Enrichment)

Groups by the manager's department (requires query enrichment) with a 15% threshold:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "department",
        "target": "TARGET_NODE_JOINED",
        "joined_node_alias": "manager"
      }
    ],
    "threshold": 0.15
  }
}

Use case: Identify access that's unusual among users whose managers are in the same department, useful in matrix organizations.

Use Cases

Finance Audit Compliance

Scenario: Reviewing access to financial systems where SOX compliance requires attention to outlier access.

Configuration:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "department",
        "target": "TARGET_NODE_SOURCE"
      }
    ],
    "threshold": 0.05
  }
}

Users with access held by ≤5% of their department peers are flagged for additional scrutiny.

Engineering Production Access

Scenario: Reviewing production system access where most engineers shouldn't have admin rights.

Configuration:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "team",
        "target": "TARGET_NODE_SOURCE"
      },
      {
        "property_name": "environment",
        "target": "TARGET_NODE_DESTINATION"
      }
    ],
    "threshold": 0.1
  }
}

Identifies engineers with production access that is unusual within their team, considering the environment.

Role-Based Access Review

Scenario: Reviewing access where job role should predict permissions.

Configuration:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "job_role",
        "target": "TARGET_NODE_SOURCE"
      }
    ],
    "threshold": 0.15
  }
}

Flags access held by ≤15% of users with the same job role, indicating potential role creep or over-provisioning.

Cross-Department Anomaly Detection

Scenario: Detecting access patterns that are unusual for an entire department.

Configuration:

{
  "value": {
    "grouping_properties": [
      {
        "property_name": "department",
        "target": "TARGET_NODE_SOURCE"
      },
      {
        "property_name": "location",
        "target": "TARGET_NODE_SOURCE"
      }
    ],
    "threshold": 0.08
  }
}

Identifies access held by ≤8% of users in the same department and location, flagging potentially inappropriate cross-functional access.

Important Considerations

Configuration Scope: Settings can be applied globally (affecting all new reviews by default) or per-review configuration. Review-specific settings override global settings for reviews created from that configuration.

Property Availability: Grouping properties must exist in your access review query results. If a specified property doesn't exist for source/destination/joined nodes, outlier detection may not function as expected. Verify property names match your data schema.

Statistical Confidence: The algorithm uses the Wilson score confidence interval at 95% confidence level to ensure statistically sound outlier detection even with small peer groups. Peer groups with fewer than 3 members are excluded from outlier analysis to maintain statistical validity.

Threshold Tuning: Start with the default 15% threshold and adjust based on your organization's risk tolerance:

Lower thresholds (5-10%): More sensitive, flags only the rarest access
Higher thresholds (20-25%): Less sensitive, flags more broadly uncommon access

After implementing Outlier Detection, monitor reviewer feedback and adjust accordingly.

Enrichment Requirements: When using TARGET_NODE_JOINED properties, ensure your Access Review query includes the corresponding JoinNodeSpec with the matching alias. See Access Reviews Configuration for enrichment configuration.

Access Reviews Settings - Overview of all Access Reviews settings
Access Reviews Configuration - Complete Access Reviews documentation

PreviousReview Row Grouping NextSystem Audit Logs

Last updated 3 days ago

Was this helpful?

How Outlier Detection Works

Default Behavior

Example Scenario

API Endpoints

Get Outlier Detection Configuration

Parameters

Example: Get Global Configuration

Example: Get Configuration for Specific Review

Response

Set Outlier Detection Configuration

Parameters

Example: Set Global Configuration

Example: Set Configuration for Specific Review

Response

Grouping Properties

Property Reference Schema

Target Node Types

SOURCE Node Properties

DESTINATION Node Properties

JOINED Node Properties (Enrichment)

Configuration Examples

Example 1: Default Manager-Based Grouping

Example 2: Department and Location Grouping

Example 3: No Grouping (Population-Wide)

Example 4: Resource Classification Grouping

Example 5: Manager's Department (Enrichment)

Use Cases

Finance Audit Compliance

Engineering Production Access

Role-Based Access Review

Cross-Department Anomaly Detection

Important Considerations

Related Documentation