Role Mining Prompts

Overview

Role mining in Albus follows a layered approach: start broad and add specificity only where the data justifies it. Each prompt uses a birthright threshold — the assignment % above which an app or entitlement should be granted automatically rather than requested. Higher thresholds mean stricter recommendations. You’ll work with two matrix types depending on the app:

An access matrix answers “which apps should this group of people get?” Use it for license-based apps where having the license is the whole story — Zoom, Slack, Notion, 1Password.
A permissions matrix answers “which roles, groups, or entitlements within an app should this group get?” Use it for apps with meaningful internal permission structures — Salesforce, Okta, AWS, GitHub, ServiceNow.

Customize the [bracketed] placeholders to match your environment — use whichever HR attribute names you actually have (Department, Business Unit, Cost Center, Team, Subsidiary, etc.). The example thresholds (80% / 70% / 60%) are a good starting point; adjust higher for stricter policies or lower if you want more apps surfaced as birthright candidates.

Attribute Recommendations

Before building any matrix, ask Albus which attributes in your identity data actually predict access. The /user-attribute-selection skill scores every grouping attribute you have configured and returns a layered birthright, pre-approved and self-service model. It proposes a plan first and waits for your approval before running.

Label	Prompt	Expected Output	Value
Generate the recommendation	`Using /user-attribute-selection which attribute combinations are best for defining access policies?`	A short plan to approve, then a measured analysis of every grouping attribute in your tenant.	Grounds policy design in your own data rather than an assumption about which attributes matter.
Approve the plan (Click Approve CTA)	`This plan looks good, go ahead.`	Albus runs the full analysis and returns the recommended attribute set, a scorecard, and a coverage estimate.	The skill pauses before a long run so you can adjust the scope first.
Add context on the scale you expect	`We are an enterprise organization and I expect a sizable number of access policies. Show me what a finer, team-level attribute adds beyond the top anchor.`	A re-measure on absolute and residual contribution, showing what a finer attribute adds beyond the top anchor.	Albus tailors the analysis to the context you give it. Telling it the scale you are planning for gets you a deeper cut on the team-level layers.
Review the recommendation	`Give me a clear overview of the attribute combinations you recommend for building access policies. Use helpful diagrams eg. mermaid diagrams and explain why an attribute was valid or not.`	The recommended combinations, a diagram of how the layers stack, and the case for and against each attribute.	The reasoning is what you take into a working session, not just the answer.
Save the analysis	`Save the report to my Knowledge Hub.`	The analysis is written to your Knowledge Hub so later threads can read it.	Future conversations reference the same report instead of rerunning the analysis.
Check coverage before building	`What % of access can I cover with layers 1 and 2?`	The share of existing access captured as birthright, pre-approved, and self-service.	Tells you how much a policy set covers before you build a single policy.

Building Access Matrices (app-level)

Label	Prompt	Expected Output	Value
Step 1 — the universal base	`let's do a matrix for the everyone attribute`	A single-column matrix across all active staff, showing the apps nearly everyone already holds.	Establishes the base so every layer after it only shows what it adds.
Step 2 — the top org layer	`yes let's drill into [top-level org attribute]`	The matrix for that layer across your business units.	Albus offers this at the end of the attribute overview, so you can answer in a few words.
Step 3 — the team layer	`let's drill into [team attribute], filter out apps from the layer before`	The team-level matrix, showing only access the layer above did not already grant.	Without the filter each layer repeats the apps above it and you cannot see what the layer contributes.
Step 4 — the carve-outs	`now let's do [carve-out attribute], filter out apps from the layers before`	The carve-out matrix, for example contingent workers or a region.	Completes the layered model. Albus keeps offering the next layer, so you can also just reply next.
Layer 1 — baseline by Employee Type	`Show me an access matrix for users with employee type = FTE with assignment % > 30%. Use birthright threshold of 80%.`	An access matrix for FTEs across all apps, with birthright vs. self-service recommendations.	Establish the company-wide baseline every full-time employee should get on Day 1.
Layer 2 — by department or business unit	`Show me an access matrix for users with [department attribute] = [Department Name] with assignment % > 30%. Use birthright threshold of 80%.` Optional add below: `Exclude apps already marked birthright above.`	An access matrix scoped to the department, showing incremental apps beyond the Layer 1 baseline.	Capture team-specific apps (Engineering → GitHub, Sales → Salesforce) without duplicating the company baseline.
Layer 3 — by team (only if needed)	`Show me an access matrix for users with [team attribute] = [Team Name] with assignment % > 30%. Use birthright threshold of 70%.` Optional add below: `Exclude apps already marked birthright above.`	An access matrix for the team, showing only the long-tail apps unique to that team.	Add team-level granularity for specialized tooling (e.g., Security → Datadog admin) without over-fragmenting policies.
Split by a secondary attribute	`Show me an access matrix for users with [attribute] = [Value] split by [secondary attribute].`	A matrix where rows are apps and columns are the distinct values of the secondary attribute.	Compare access patterns across subsidiaries, regions, or sub-teams in one view.

Building Permissions Matrices (entitlement-level)

Label	Prompt	Expected Output	Value
Permissions matrix — by Employee Type	`Show me a permissions matrix for [App Name] for users with employee type = FTE with assignment % > 20%. Use birthright threshold of 80%. Exclude groups containing '_dl', 'location', or 'all-employees'.`	An entitlement-level matrix showing which groups, roles, or profiles should be birthright across the FTE population.	Define the right level of access inside an app, not just whether someone gets the license.
Permissions matrix — by department or team	`Show me a permissions matrix for [App Name] for users with [department attribute] = [Department Name] with assignment % > 20%. Use birthright threshold of 70%. Exclude entitlements already marked birthright at Layer 1.`	A department- or team-scoped entitlement matrix layered on top of the Layer 1 baseline.	Handle apps like Salesforce where Sales needs profiles other departments don’t, or where one engineering sub-team needs admin roles.
Permissions matrix — filtered by entitlement name	`Show me a permissions matrix for [App Name] filtered to groups with [prefix] in the name.`	An entitlement-level matrix limited to the groups matching that naming pattern.	Cuts a large app down to the entitlement family you care about instead of every group it has.
Find the groups that actually hold the access	`Find user groups with the highest [App Name] assignment percentages.`	Assigned over total per cohort, at both department and cost-centre grain, ignoring groups under ten members.	Scope the matrix to teams that genuinely hold the access rather than reading a wall of self-service.
Lower the bar on sparse access	`Lower birthright % to 20.`	The matrix re-rendered, showing which entitlements qualify at a lower threshold.	Role-specific apps rarely clear 80% in any team. Qualifying only at 20% signals pre-approval, not birthright.
Test whether a finer attribute helps	`Does adding [attribute] as a combo attribute help increase percentages?`	A comparison showing whether the combination concentrates the cohorts or fragments them.	A finer attribute only lifts percentages when it lines up with who holds the access. Usually it does not.

[Optional] Decision Helpers

Label	Prompt	Expected Output	Value
Decide policy depth (5-user rule)	`For my access policies: if only one team in a department has 5+ users and all others have <5, build at department level. If two or more teams have 5+ users, build at department + team level. Show both groups as tree diagrams with user counts.`	Two grouped trees — departments to handle at department level vs. departments to break out by team.	Avoid over-fragmenting (one policy per tiny team) and under-fragmenting (one policy hiding real variance).
Compare attribute granularity	`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.`	A side-by-side or summary showing whether breaking out by team surfaces meaningfully different access.	Know when to stop adding layers — if the deeper level looks the same, don’t build it.

Teaching Albus Your Environment

Label	Prompt	Expected Output	Value
Teach a naming convention	`Remember: any group name containing '_dl' is a distribution list and should be excluded from permissions matrices by default.`	Confirmation Albus has stored the rule; future matrices apply it automatically.	Train Albus on your conventions once instead of repeating exclusions every prompt.
Teach a location pattern	`Remember: groups starting with a country or city name (e.g., 'usa_', 'london_') are location-based distribution lists, not access controls.`	Confirmation the rule is stored.	Filter out noise from location-based groups across every future matrix.
Teach an exclusion rule	`Remember: apps labeled "deprecated" should never appear in birthright recommendations.`	Confirmation the rule is stored.	Keep retired apps out of policy recommendations.
Exclude an app entirely	`Remember: ignore [App Name] and exclude it from matrices.`	Confirmation the app will be filtered from future matrices.	Pull noisy or out-of-scope apps (sandboxes, test environments, internal tools) out of every recommendation.

Gap and Coverage Analysis

Label	Prompt	Expected Output	Value
Identify gaps in existing policies	`Identify potential gaps in existing access policies by analyzing application assignment coverage. Look for apps assigned to 60–90% of [employee group] — that range often indicates a missing policy.`	A table of apps with partial coverage, with coverage % and a suggestion for whether to promote to birthright.	Surface near-birthright apps that should be promoted, and inconsistencies in current assignments.
Top-requested apps segmentation	`For the top 5 most-requested apps in the last quarter, show me recommended access policy segmentation and the rationale for each.`	A breakdown of the top 5 apps with proposed segmentation and reasoning grounded in request data.	Prioritize policy work where it eliminates the most tickets.
Find apps missing access groups	`Looking at my Okta apps, which entitlements are missing a corresponding access group? Use the naming convention "APP-[app name]" to check.`	A list of Okta apps without a backing access group.	Prep work for moving birthright orchestration off of IdP rules and into Lumos policies.

NHI Security

MCP Governance

Lumos AI

Applications & Entitlements

Access Policies & Lifecycle Management

AppStore

Access Reviews

Identity Agent Force

Analytics

Platform Administration

Role Mining Prompts

Overview

Attribute Recommendations

Building Access Matrices (app-level)

Building Permissions Matrices (entitlement-level)

[Optional] Decision Helpers

Teaching Albus Your Environment

Gap and Coverage Analysis

​Overview

​Attribute Recommendations

​Building Access Matrices (app-level)

​Building Permissions Matrices (entitlement-level)

​[Optional] Decision Helpers

​Teaching Albus Your Environment

​Gap and Coverage Analysis

Overview

Attribute Recommendations

Building Access Matrices (app-level)

Building Permissions Matrices (entitlement-level)

[Optional] Decision Helpers

Teaching Albus Your Environment

Gap and Coverage Analysis