> For the complete documentation index, see [llms.txt](https://docs.balkan.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.balkan.id/iam-risk-analyzer/rbac-analyzer/how-it-works-role-mining-and-risk-analysis.md).

# How It Works: Role Mining & Risk Analysis

This page explains the engine behind the RBAC Analyzer — how BalkanID mines roles from live access data and how it scores the risk of every role and every grant. You do not need to understand the internals to use the product, but understanding them helps you interpret confidence, risk, and the ideal-state recommendations with more authority.

### The analysis pipeline

Every run of the RBAC Analyzer reads a real-time snapshot of your access graph — employees and their identities, the connections (roles, groups, policies) those identities hold, the resources and permissions behind each connection, and the behavioral signals (last login, last access) attached to them. From that snapshot it produces three things:

```mermaid
flowchart LR
    A[Live access graph<br/>HRIS + apps + usage] --> B[Role Mining]
    B --> C[Confidence Scoring]
    B --> D[Risk Analysis]
    C --> E[Generated Roles]
    D --> E
    E --> F[Consolidation<br/>Current → Ideal]
    F --> G[Recommendations]
```

1. **Generated Roles:** clusters of access expressed as virtual roles, each named and classified.
2. **A confidence and risk profile:** for each role and each grant.
3. **A consolidation:** a least-privilege *ideal* state derived from your *current* state, with prioritized recommendations.

The analysis is point-in-time. Each time you re-run it, the model is rebuilt from the latest data, so improvements you make in your respective applications show up on the next run.

### Role mining

BalkanID's approach combines both **bottom-up** and **top-down** methodologies to create a robust RBAC system.

#### Bottom-up approach

The bottom-up pass studies the access that already exists and how it is actually used:

* **Data analysis** examines existing entitlement data, including permissions and access levels.
* **Permissive power evaluation** assesses how powerful each permission is, identifying high-risk privileges (e.g. `admin`, `owner`, `delete`, wildcard `*`, manage/escalate verbs).
* **Resource sensitivity assessment** determines the sensitivity of resources based on data classification, wherever available, so that a read on a crown-jewel resource outranks a write on a scratch resource.
* **Behavioral attributes** analyzes user activity such as last login time and frequency of resource usage, wherever available, to understand actual need versus standing entitlement.

#### Top-down approach

The top-down pass studies how your organization is structured:

* **HRIS integration:** incorporates data from Human Resource Information Systems to understand organizational structure (department, job title, manager, reporting lines).
* **Peer grouping:** groups users with similar roles or departments to standardize permissions and reveal what a cohort holds in common.
* **User trust levels**: assigns trust based on factors like tenure, role criticality, and past behavior.

#### Two kinds of mined role

The engine produces two complementary families of role, and the RBAC Analyzer surfaces both:

* **Peer (identity) roles** derived bottom-up from cohorts of identities that share the same access. These answer *"this set of people all hold the same bundle of permissions, so it is a role."* Peer roles are what let BalkanID detect birthrights and over-provisioning even when no group exists in the source system.
* **Structural (group) roles** derived from the connections (groups, roles, policies) that already exist in your applications. These let group-heavy, employee-light — even employee-less — integrations still surface meaningful roles, and they let a peer role be tied back to the source group(s) it most resembles.

{% hint style="info" %}
Because peer roles are mined from access patterns rather than from existing groups, the RBAC Analyzer can recommend roles your IdP does not have yet - and can flag existing groups that no longer match how people actually work.
{% endhint %}

#### Connection classification

As part of mining, every connection is classified as a **group**, a **role**, or a **policy**, and flagged when it is **provider-owned and immutable** (for example, a cloud-provider-managed policy that your team cannot edit). This classification keeps people-container signals applied only to genuine groups and keeps immutable, provider-managed objects out of the adoptable role set so they do not add noise to your recommendations.

### Risk analysis

Mining tells you *what the roles are.* Risk analysis tells you *which access deserves attention.* BalkanID computes risk at two grains — per grant and per identity/role — and rolls it up into bands and factors you can act on.

#### What feeds the risk score

The composite risk score blends several orthogonal signals so that no single dimension dominates:

| Signal                   | What it captures                                                                                                                               |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Privilege power**      | How dangerous the permission itself is — administrative, destructive, escalation-capable, or wildcard access scores higher than a scoped read. |
| **Resource sensitivity** | How sensitive the target is, using data classification where available, so access to crown-jewel resources is weighted up.                     |
| **Dormancy**             | Standing privilege that is not being used — high privilege combined with no recent activity is a classic risk.                                 |
| **Peer outlier**         | Access that an identity holds but its peers do not — an indicator of access drift or over-provisioning.                                        |
| **Access sprawl**        | The breadth of an identity's footprint — how many groups, resources, and privileges it accumulates.                                            |

These signals are decomposable: for any grant or identity you can see *why* it is risky, not just *that* it is.

#### Risk bands

The composite score is mapped to a **risk band** so it reads at a glance:

| Band          | Meaning                                                                  |
| ------------- | ------------------------------------------------------------------------ |
| 🔴 **High**   | Concentrated, powerful, or dormant access that should be reviewed first. |
| 🟠 **Medium** | Elevated access worth a second look.                                     |
| 🟢 **Low**    | Routine access that aligns with peers and usage.                         |

Risk bands appear on individual grants in the Permission Set Explorer and roll up into the Role Risk Factor at the role level and into the Risk Dashboard at the organization level.

### Confidence, risk, and grade — how they relate

The RBAC Analyzer scores roles on three independent axes. Keeping them distinct is important, because a role can be high-confidence and still high-risk, or low-confidence and harmless.

* **Confidence:** *how role-like is this cluster?* It measures peer-cohort cohesion: do the people who share a job title, department, and manager actually share this access? See Role Confidence.
* **Risk:** *how dangerous is this access?* It measures privilege, dormancy, outlier behavior, sprawl, and resource sensitivity. See above. The Role Risk Factor summarizes it per role.
* **Grade (quality):** *should you adopt this role?* The engine's holistic classification (**Recommended**, **Needs review**, or **Noise)** — combines confidence with alignment and support to tell you whether a generated role is ready to operationalize, needs a human look, or is leftover/residual access that did not consolidate cleanly.

{% hint style="info" %}
Confidence and risk are **orthogonal.** They share no inputs. A role can be a confident birthright (everyone in the department holds it) and still be high-risk (it grants powerful, sensitive access). Read both signals together when prioritizing work.&#x20;
{% endhint %}

### From analysis to action

Once roles are mined and scored, BalkanID consolidates your *current* state into an *ideal*, least-privilege state and emits prioritized recommendations what access to keep, reshape, split, merge, or remove. That target and those recommendations are covered in Current State & Ideal State RBAC and Remediation & Best Practices.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.balkan.id/iam-risk-analyzer/rbac-analyzer/how-it-works-role-mining-and-risk-analysis.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.