Skip to main content

​
Overview

The Role Mining Agent, also called the RBAC Agent, analyzes who has access to what across your identities, apps, and entitlements, and proposes birthright and role-based access policies. It is one of the Identity Agent Force agents. For the big picture and how agents work, see the Identity Agent Force Overview. The Role Mining Agent is in beta. Contact your Lumos account team or your CSM to turn it on for your workspace. This guide walks through one full pass, from your first prompt to published policies. Most steps give you one prompt to run and tell you what to expect back. For more prompts and variations, see Role Mining Prompts.

​
How role mining works

The agent reads the identity and access data Lumos already syncs from your HR source of truth, your identity provider, and your connected apps. It works from actual assignments, so its recommendations reflect the access people hold today. You build policies in layers. Start with the broadest group, then add a narrower layer only where the data shows that group holds different access.
  • Access matrix. Shows which apps a group of people share. Use it for apps where having the license is the whole story, such as Zoom or Slack.
  • Permissions matrix. Shows which roles, groups, or entitlements inside one app a group shares. Use it for apps with their own permission structure, such as Salesforce, AWS, or GitHub.
  • Birthright threshold. The share of a group that must hold an app or entitlement before the agent recommends granting it automatically. Access below the threshold is better left requestable.

​
Before you start

  1. Make sure your HR source of truth, your identity provider, and your key apps are connected and synced. The agent can only analyze access it can see.
  2. On the Identity Agent Force page, open the Agents tab and select Create Agent. Choose the Role Mining specialization (see Creating an agent). You need permission to manage Identity Agent Force to see Create Agent.
  3. Open the agent. Its page is a chat (see Chatting with Identity Agents), and every step below is a prompt you run there.

​
Step 1: Find the attributes that predict access

Ask the agent which identity attributes, such as Employee Type, Department, or Team, line up with the access people hold.
The agent proposes a short plan and waits. Approve it, and the agent scores every grouping attribute in your workspace and recommends the layers to build policies on. Before you move on, check how much access those layers cover:

​
Step 2: Build the company-wide baseline

Start with the access nearly everyone holds. This becomes the base that every later layer builds on.
You get an access matrix for all full-time employees. Apps above the threshold are marked as birthright, and the rest as requestable.

​
Step 3: Add the department layer

Run the same matrix for one department, and leave out what the baseline already grants. Replace the [bracketed] placeholders with your own attribute names and values.
You get only the apps this department adds on top of the baseline, such as GitHub for Engineering or Salesforce for Sales. Repeat for each department you want a policy for.

​
Step 4: Add a team layer only where it helps

A team layer is worth building only when teams inside a department hold different access. Ask the agent before you build it.
If the team level looks the same as the department level, stop at the department. If it differs, run the Step 3 prompt with your team attribute.

​
Step 5: Go inside apps with their own permissions

For apps where the role or group matters as much as the license, run a permissions matrix.
You get the roles, groups, or entitlements inside the app that the group shares, with the same birthright and requestable split. If the matrix is full of groups that are not access controls, such as distribution lists, tell the agent once and it leaves them out of later matrices:

​
Step 6: Turn the matrix into draft policies

When a matrix looks right, select Create Policy on the matrix, choose the policies to create, and confirm. You can also ask the agent in chat:
The agent shows each proposed policy for you to review and edit, and creates nothing until you approve it. Either way, each policy is saved as a draft in Access Policies. A draft grants no access.

​
Step 7: Publish and activate one group first

Publish and activate the drafts for one department first. Check that the access it grants is what you expect, then work through the remaining departments.

​
Pick up where you left off

Use Sessions on the agent’s page to reopen an earlier conversation. To save an analysis so later sessions can read it, ask the agent to save the report to your Knowledge Hub.

​
Tune the agent to your environment

  • Teach it your conventions in chat. Tell the agent which groups, apps, or naming patterns to ignore, and it applies them to later matrices. See Teaching the Agent Your Environment.
  • It follows Lumos-managed Skills. The agent uses Skills that Lumos maintains, such as user-attribute-selection. You don’t need to set them up.
Questions? Contact your Lumos account team or open a support ticket.