Over-Permission Analytics

Identifies identities with significantly more access than their organizational peers using statistical outlier detection

Requires role: Operator

Related: Risk Posture Dashboard, Stale Identity Detection, Asset Criticality, Attribute Sync Configuration

Overview

Over-Permission Analytics automatically detects identities that hold excessive permissions compared to their colleagues in the same role. Instead of relying on fixed permission thresholds, the system groups identities by type, department, and job title, computes a baseline for each peer group, and flags identities that deviate significantly from their peers.

The analysis evaluates effective permissions — not just the permissions directly assigned to an identity, but also permissions inherited through group memberships (up to 20 levels deep). This means nested group misconfigurations (e.g., "Domain Computers" added to "Domain Admins") are surfaced as findings for the affected members.

This is especially useful for identifying:

• Privilege creep — Users who accumulated access across multiple role changes
• Emergency access grants — Temporary elevated permissions that were never revoked
• Misconfigured service accounts — Service accounts with far broader access than necessary
• Nested group misconfigurations — Unexpected group nesting that grants excessive inherited permissions
• Insider risk — High-access identities that may warrant additional monitoring

The analysis runs entirely on live graph data and requires no pre-configuration. Peer groups are formed automatically from directory attributes synced during LDAP or Entra ID synchronization.

NOTE

Over-permission results are pre-computed after each sync and cached per domain. When you open this page with default settings, results load instantly from the cache. Custom filter combinations (non-default sigma, type filter, or criticality filter) trigger a live query against the graph database.

How It Works

Identity Scope

The analysis evaluates the following identity types:

• User — Human accounts
• Group — Security and distribution groups
• Computer — Machine accounts
• ServiceAccount — On-premises service accounts
• ServicePrincipal — Entra ID application identities

Groups are analyzed the same way as other identity types — their effective permissions include both direct permission edges (e.g., GenericAll, WriteDacl on other objects) and permissions inherited from parent groups via MemberOf nesting (up to 20 levels). Structural relationships like MemberOf are excluded from permission counting, so Groups are only flagged when they hold genuinely excessive non-structural permissions compared to peer groups. Additionally, group permissions are counted as inherited permissions for the actor identities that are members of those groups.

Peer Group Formation

Identities are grouped by four attributes:

• Domain — Identities are only compared against peers in the same domain (security boundary)
• Identity Type — Users are compared to Users, Computers to Computers, etc.
• Department — The department field from Active Directory or Entra ID
• Job Title — The title field (LDAP) or jobTitle field (Entra ID)

For example, all Users in dev.lab with department = "Engineering" and title = "Senior Engineer" form a single peer group. The same department/title combination in contoso.com forms a separate group. This ensures identities in unrelated security boundaries are never compared against each other.

Identities missing these attributes are placed in an "Unknown" peer group and still participate in analysis — this helps identify misconfigured or undocumented accounts.

Permission Counting

The system counts effective permissions for each identity: direct permissions plus inherited permissions from group memberships.

Direct permissions — Access relationships directly assigned to the identity:

• HasPermission — Explicit resource grants
• OwnerOf — Ownership relationships
• HasRole — Role assignments (Entra ID)
• AppRoleAssignment — Application role assignments
• GenericAll, GenericWrite — Full control and write access
• WriteDacl, WriteOwner — Security descriptor modification
• AllExtendedRights — Extended attribute rights
• ForceChangePassword, AddMember — Specific privileges

Inherited permissions — Access relationships held by groups the identity belongs to, traced up to 20 levels of group nesting.

The following relationship types are excluded from counting (they represent structure, not permissions):

• MemberOf — Group membership (used for traversal, not counted as a permission)
• ContainedIn — Organizational structure
• GPLink — Group Policy linkage
• TrustedBy — Domain trust relationships

Detection Sensitivity

For each peer group, the system computes:

• Average — Average number of effective permissions in the group
• Spread — How much variation exists within the group (technically: standard deviation)

An identity is flagged when its permission count is significantly above the peer group average. The Detection Sensitivity slider controls how far above average an identity must be before it's flagged.

Technical detail: The Detection Sensitivity slider maps to a statistical sigma threshold. A sigma of 2.0 (the default, "Moderate" sensitivity) flags identities more than 2 standard deviations above their peer group average. Lower sigma values are more aggressive (flag more identities), higher values are more conservative.

Sensitivity Level	Sigma Value	Description
Very High	0.5 - 1.0	Flags anyone noticeably above average
High	1.0 - 1.5	Flags moderate deviations, useful for initial audits
Moderate	1.5 - 2.5	Balanced detection (recommended for routine use)
Low	2.5 - 3.5	Only flags significant deviations
Very Low	3.5 - 5.0	Only flags extreme cases

Peer Group Size Filter

To ensure statistical reliability, peer groups smaller than the minimum peer group size (default: 3 members) are excluded from analysis. This prevents false positives from tiny groups where variation is expected.

Accessing the Analysis

1. Log in as an Operator or Admin
2. Open the navigation menu (☰) and select Over-Permissions under Analysis

The analysis runs automatically when you open the page. Results refresh every 5 minutes or when you change filter settings.

Understanding the Summary

At the top of the page, three summary cards provide an at-a-glance overview:

Total Findings

The number of identities flagged as over-permissioned at the current sensitivity level.

Avg Excess Permissions

The average number of permissions above the peer baseline across all flagged identities. A value of +18.5 means flagged identities have, on average, 18.5 more effective permissions than their peers.

Top Affected Groups

The peer groups with the highest concentration of findings. Each entry shows:

• Peer group name (e.g., "User / IT / Helpdesk Technician")
• Finding count / total group size (e.g., "5 / 12")

If the same group appears repeatedly, it may indicate a systemic access hygiene issue in that department or role.

Filtering and Tuning

Detection Sensitivity Slider

Adjust how aggressively the system flags identities:

• More findings (left) — Lower threshold, catches more identities including borderline cases
• Fewer findings (right) — Higher threshold, only catches extreme deviations

The current sensitivity level is displayed as a label (Very High, High, Moderate, Low, Very Low). Changes to the slider are debounced — the query reruns 500ms after you stop moving it.

Identity Type Filter

Restrict analysis to a specific identity type:

• User — Standard human accounts
• Group — Security and distribution groups
• Computer — Machine accounts
• ServiceAccount — On-premises service accounts
• ServicePrincipal — Entra ID application identities

Leave set to All Types to analyze all identity types together. Each type is compared within its own peer groups, so Users are never compared against Computers.

Min Peer Group Size

Minimum number of members required for a peer group to be included in analysis. Default is 3.

• Increase to 5-10 if you want to exclude small teams where high variation is normal
• Decrease to 2 if you have a small organization and want to analyze all peer groups

Reading the Results Table

Each row represents a single over-permissioned identity. Columns include:

Column	Description
Identity	Clickable name — click to focus the identity in the graph view
Type	Identity type (User, Group, Computer, ServiceAccount, ServicePrincipal)
Criticality	Criticality level (LOW, MEDIUM, HIGH, CRITICAL)
Permissions	Total effective permission count (direct + inherited)
Peer Avg	Average permission count for the peer group
Deviation	How far above the peer average this identity is. Higher = more extreme. Includes a visual bar for quick comparison.
Peer Group	Peer group name and size (e.g., "User / Engineering / Senior Engineer (24)")

Results are sorted by deviation score (highest first), with a secondary sort by criticality to prioritize high-impact findings.

Expanding a Row for Details

Click any row to expand it and see:

Permission Breakdown Chart: A horizontal bar chart showing the identity's permission count for each relationship type (HasPermission, GenericAll, etc.). Bars exceeding the peer average are highlighted in orange, making it easy to spot which specific permissions are excessive.

Excess Permissions: The number of permissions above the peer baseline (calculated as Permission Count - ceil(Peer Average)).

Direct / Inherited / Groups:

• Direct — Permissions assigned directly to this identity
• Inherited — Permissions inherited through group memberships
• Groups — Number of groups this identity belongs to (up to 20 levels of nesting)

High inherited permission counts often indicate group nesting issues worth investigating.

Peer Group Spread: How consistent the peer group's permissions are. A high spread means wide variation within the group; a low spread means the group is tightly controlled.

Tier: Asset criticality tier (if assigned by the criticality engine).

View in Graph Button: Navigates to the full graph view with the identity focused, allowing you to inspect the specific access paths and decide which permissions to revoke.

Example Use Cases

1. Quarterly Access Review

Scenario: You need to prepare a list of accounts for access review before an audit.

Steps:

1. Set sensitivity to Moderate (default)
2. Filter Type to User
3. Review the top 20 findings
4. For each finding, expand the row to check if inherited permissions are the primary driver
5. For confirmed over-permissions, use the graph drill-down to identify which specific permissions to revoke

2. Service Account Audit

Scenario: Identify service accounts with excessive privilege that could be exploited if compromised.

Steps:

1. Set sensitivity to High (more aggressive, since service accounts should be tightly scoped)
2. Filter Type to ServiceAccount or ServicePrincipal
3. Review findings sorted by deviation
4. Expand each row to see which ACL permissions (GenericAll, WriteDacl) are excessive
5. Work with app owners to reduce permissions to least-privilege

3. Nested Group Misconfiguration Detection

Scenario: Detect unintended group nesting that grants excessive inherited permissions (e.g., "Domain Computers" added to "Domain Admins").

Steps:

1. Set sensitivity to Moderate
2. Filter Type to Computer to see machines with unexpected admin access
3. Look for findings with high Inherited counts — these indicate permissions via group nesting
4. Expand rows and check the permission breakdown for admin-level access types (GenericAll, WriteDacl)
5. Use the graph view to trace the MemberOf chain and identify the misconfigured group nesting

4. Insider Threat Monitoring

Scenario: Identify high-access users in sensitive departments for heightened monitoring.

Steps:

1. Set sensitivity to Low (focus on significant deviations only)
2. No type filter (include all identities)
3. Look for findings in Finance, Legal, or HR peer groups
4. Cross-reference with the Criticality column — HIGH or CRITICAL findings are highest risk
5. Flag for additional logging, MFA enforcement, or periodic re-certification

5. Debugging "Unknown" Accounts

Scenario: You see many findings in "Unknown" peer groups.

Steps:

1. Expand rows in that group to see which identities are missing directory attributes
2. Investigate whether these are:
   • Orphaned accounts — Former employees or decommissioned services
   • Misconfigured accounts — Missing department/title in Active Directory
   • External identities — Guest accounts or service principals without organizational metadata
3. Either populate the missing attributes in your directory or exclude these identities from analysis using the Type filter

Interpreting Peer Group Baselines

High-Variation Groups

If a peer group has a high spread (e.g., peer average of 10 with spread of 8), it indicates inconsistent access within that role. This could mean:

• Poorly defined role — The job title doesn't correspond to a consistent set of responsibilities
• Multiple seniority levels — Mixing junior and senior staff in the same title
• Legacy access — Some members retained old permissions after role changes

Consider splitting the group by additional attributes (e.g., manager, cost center) or reviewing whether the department/title taxonomy needs refinement.

Zero-Variation Groups

If all members of a peer group have identical permission counts, the spread is zero and no findings will be flagged. This is normal for:

• Service account groups — Service accounts in the same role often have identical access by design
• New hires — Recent batch hires with identical onboarding templates
• Tightly controlled groups — Compliance-managed roles with strict access templates

Configuration Options

All analysis parameters are controlled via the UI filter bar. There are no persistent configuration files or settings — each query is stateless.

Troubleshooting

No findings detected at any sensitivity level

Cause: Your organization may have highly uniform access patterns, or directory attributes (department/title) are missing for most identities.

Resolution:

1. Check that at least 50% of identities have populated department and title attributes in your directory
2. Run a test sync to ensure these attributes are being ingested
3. Try lowering the minimum peer group size to 2 to include smaller peer groups

Too many findings (100+ at moderate sensitivity)

Cause: Wide variation in access patterns, or peer groups are too coarse-grained.

Resolution:

1. Move the sensitivity slider toward "Fewer findings" to focus on only the most extreme cases
2. Increase the minimum peer group size to 5 or 10 to exclude small, high-variance groups
3. Consider refining department/title taxonomy in your directory for more precise peer grouping

"Unknown" group dominates results

Cause: Many identities are missing department and/or title attributes.

Resolution:

1. Populate missing attributes in Active Directory or Entra ID
2. Use the Type filter to exclude orphaned or external identities if they skew results
3. For service accounts without organizational metadata, filter to ServiceAccount type and analyze separately

Query timeout or slow response

Cause: Custom filter parameters trigger a live query instead of reading from the pre-computed cache.

Resolution:

1. Use default settings (no custom filters) to load from the pre-computed cache instantly
2. Apply a Domain filter — this serves from the per-domain cache directly
3. If custom filters are needed, apply a Type filter to reduce the search space
4. Check the Sync Metrics panel for the "Analytics" phase duration — this shows how long pre-computation takes per domain

Deviation score shows as 0.0 for some identities

Cause: The peer group has zero variation (all members have identical permission counts).

Resolution: This is expected behavior. No findings will be flagged from that peer group because there is no baseline variation. This typically occurs in:

• Service account templates
• New hire batches
• Highly controlled compliance roles

Best Practices

1. Run quarterly access reviews — Use moderate sensitivity to identify access creep before audits
2. Combine with criticality filtering — Focus on HIGH/CRITICAL identities first to prioritize remediation
3. Check inherited permissions — High inherited counts often reveal group nesting issues worth fixing at the source
4. Use peer group insights — If a peer group has many findings, investigate whether the baseline (not just the findings) is too permissive
5. Track trends over time — Rerun the analysis monthly to track whether access hygiene is improving or degrading
6. Integrate with access reviews — Export findings to your IAM ticketing system or send to department managers for attestation
7. Don't ignore "Unknown" groups — Identities without directory metadata may be orphaned accounts or misconfigurations worth investigating

Limitations

• Attribute quality dependency: The analysis is only as good as your directory hygiene. Organizations with poor department/title data will have less meaningful peer groups.
• Equal weighting of permission types: All permission types count as 1. A GenericAll permission grants far more access than a HasRole permission, but both count equally toward the total. Future versions may support weighted permission counting.
• Point-in-time analysis: Results reflect the graph state as of the last sync. There is no historical tracking of when identities became over-permissioned (this is a planned feature).
• Domain-scoped peer groups: Peer groups are scoped by domain. Identities in separate AD forests or disconnected Entra tenants are never compared. Cross-forest peer comparison (via trust relationships) is planned for a future release.
• Group nesting depth limit: Inherited permissions are traced up to 20 levels of group nesting. This exceeds any realistic AD environment but is not truly unbounded.

Related Features

• Stale Identity Detection — Identifies unused accounts that should be disabled
• Critical Junction Analysis — Finds high-risk compromise paths in the graph
• Asset Criticality Engine — Assigns criticality tiers to prioritize over-permission findings
• Change Simulation — Test the impact of revoking excessive permissions before making changes

Support

If you encounter issues with Over-Permission Analytics or have questions about interpreting results, contact your GraphnAI support team or consult the platform documentation at docs.graphnai.com.