> ## Documentation Index > Fetch the complete documentation index at: https://docs.lumos.com/llms.txt > Use this file to discover all available pages before exploring further. # Role Mining Agent > Follow a step-by-step guide to role mining with the Role Mining Agent (also called the RBAC Agent), from attribute recommendations to published access policies. ## 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](https://docs.lumos.com/kb/identity-intelligence/identity-intelligence-overview.md). **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](https://docs.lumos.com/for-admins/lumos-ai/role-mining-prompts.md). ## 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](https://docs.lumos.com/kb/identity-intelligence/identity-intelligence-overview.md#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](https://docs.lumos.com/for-admins/identity-agent-force/chatting-with-identity-agents.md)), 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. ```text theme={null} Using /user-attribute-selection which attribute combinations are best for defining access policies? ``` 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: ```text theme={null} What % of access can I cover with layers 1 and 2? ``` ## Step 2: Build the company-wide baseline Start with the access nearly everyone holds. This becomes the base that every later layer builds on. ```text theme={null} Show me an access matrix for users with employee type = FTE with assignment % > 30%. Use birthright threshold of 80%. ``` 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. ```text theme={null} Show me an access matrix for users with [department attribute] = [Department Name] with assignment % > 30%. Use birthright threshold of 80%. Exclude apps already marked birthright above. ``` 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. ```text theme={null} Do sub-teams under [Department Name] have meaningfully different access? Compare the access matrix at the department level vs. the team level for this department. ``` 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. ```text theme={null} Show me a permissions matrix for [App Name] for users with [department attribute] = [Department Name] with assignment % > 20%. Use birthright threshold of 70%. ``` 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: ```text theme={null} Remember: any group name containing '_dl' is a distribution list and should be excluded from permissions matrices by default. ``` ## 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: ```text theme={null} Create access policies from this matrix. ``` 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. * To publish and activate a draft, see [Understanding the Access Policy Lifecycle](https://docs.lumos.com/for-admins/access-policies-lifecycle-management/understanding-the-access-policy-lifecycle.md). * To have policy owners review and sign off before you publish, see [Rolling Out Access Policies: Admin Guide](https://docs.lumos.com/for-admins/access-policies-lifecycle-management/rolling-out-access-policies-across-your-org.md). ## 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](https://docs.lumos.com/for-admins/lumos-ai/role-mining-prompts.md#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.