Identity Folding™ — Permission Consolidation and Risk Weighting
ACL permissions between any two identities are merged into a single, richer connection that carries a severity classification and a composite risk weight — making the graph cleaner and analysis more accurate.
Requires role: Viewer (graph exploration); Operator (analysis and simulation) Related: Identity Graph — Data Model and Change Simulation | Over-Permission Analytics | Risk Posture Dashboard
Overview
Active Directory security descriptors grant permissions at different scopes — "This object only," "This object and all descendant objects," and so on. When an identity inherits one permission from a parent OU and receives a different explicit grant on the same target, or when separate ACL entries grant distinct rights, the result is multiple permission edges between the same two identities. In practice, roughly 40% of identity-to-target relationships carry more than one permission — combinations like GenericAll + WriteGPLink, GenericWrite + WriteDacl + WriteOwner, or AddMember + ForceChangePassword + WriteDacl are common. Without consolidation, each of those would be a separate arrow in the graph — creating visual clutter and making it harder to assess the true blast radius of a compromise.
Identity Folding™ solves this: all ACL permissions between the same two identities are combined into a single HasPermission connection that carries a full list of the individual permissions, a severity classification (Critical, High, Medium, or Low), and a numeric risk weight. In hybrid environments, Identity Loom™ goes further — weaving on-prem AD DACL permissions and cloud Entra ID grants (abusable app roles, OAuth2 delegated scopes) into the same consolidated model. An identity that has WriteDacl from AD and an abusable AppRoleAssignment from Entra ID appears as a single edge with both permissions represented, rather than two disconnected edges from two different data sources. The graph is significantly less cluttered, analysis queries run faster, and risk-weighted sorting ensures that the most dangerous access paths appear first.
This feature affects the Graph Explorer, over-permission analytics, the Risk Posture Dashboard, critical junction scoring, and change simulation — all of which now work from the same consolidated, weighted permission model.
Prerequisites
- At least one identity sync must have completed (LDAP bridge or Entra ID provider)
- Consolidation happens automatically during every full sync
- No configuration is required — consolidation happens automatically during every sync
What Changes in the Graph Explorer
Fewer, More Informative Edges
If two identities share three ACL permissions, the graph shows one arrow labeled with the most dangerous permission plus a count:
| What you see | What it means |
|---|---|
GenericAll | One ACL permission — full control over the target |
GenericAll +1 | Two ACL permissions — GenericAll is the most severe, plus one other (e.g., WriteGPLink from a different scope) |
ForceChangePassword +2 | Three ACL permissions — ForceChangePassword is the most severe |
Hovering over a consolidated edge shows the full permission list and the calculated risk weight:
HasPermission (Critical)
─────────────────────────
• GenericAll
• WriteGPLink
Weight: HighOverview Mode Sorts by Risk Weight
When viewing the graph in overview mode (no identity focused), the 500 edges shown are now sorted by risk weight from highest to lowest. The most dangerous access relationships appear first, ensuring that critical paths are visible even in large environments rather than being pushed out by lower-risk connections.
Simplified View Controls
The View menu has a single ACL Permissions toggle that shows or hides all HasPermission edges at once, rather than listing each permission type separately. Session edges (HasSession, which represent observed authentication activity) remain a separate toggle because they serve a different purpose.
How Severity Is Classified
Every consolidated permission edge carries a severity tier based on the most dangerous individual permission it contains. If a connection has both GenericAll (Critical) and AddMember (Medium), the edge is classified as Critical — reflecting the worst-case abuse potential.
Severity Tiers
| Severity | Permissions |
|---|---|
| Critical | DCSync, GenericAll, WriteDacl, WriteOwner, AddKeyCredentialLink |
| High | ForceChangePassword, AllExtendedRights, GenericWrite, WriteSPN, ReadLAPSPassword, GetChangesInFilteredSet, WriteAccountRestrictions, WriteGPLink, ReadGMSAPassword |
| Medium | AddMember, AllowedToDelegate, HasSIDHistory, AddSelf, AllowedToAct |
| Low | ReadProperty, WriteProperty |
Critical permissions represent full control or direct credential theft — an attacker with any of these on a Tier 0 target can typically complete a domain compromise without needing any additional steps.
High permissions enable significant privilege escalation — for example, ForceChangePassword lets an attacker reset a target account's credentials, while ReadLAPSPassword exposes the local administrator password stored for a managed machine.
Medium permissions offer limited but meaningful escalation vectors. AddMember can expand group access; AllowedToDelegate enables Kerberos delegation abuse.
Low permissions are tracked for completeness but rarely represent a direct attack path on their own.
How the Risk Weight Is Calculated
Each consolidated edge carries a numeric weight (its Access Gravity™ score) that reflects both the danger of the most severe permission and the breadth of access. Higher severity permissions produce higher weights, and accumulating more permissions on the same edge increases the weight further — but with diminishing returns. One critical permission is already dangerous; seven critical permissions are worse but not seven times worse.
This weight is used to sort edges throughout the platform — higher weight edges are prioritized in the graph overview, in over-permission analysis, and when junction scoring evaluates attack paths.
How This Affects Analysis Features
Over-Permission Analytics
Over-permission analysis counts the total number of distinct permissions carried across all HasPermission edges. An identity with one HasPermission edge carrying five permissions registers a permission count of 5, not 1.
For example, an identity that holds GenericAll + WriteGPLink on one target, GenericWrite + WriteDacl + WriteOwner on another, and ForceChangePassword on a third has 6 distinct permissions across 3 HasPermission edges — accurately reflecting the breadth of its access.
See Over-Permission Analytics for details on how findings are surfaced and investigated.
Risk Posture Dashboard
The over-permission component of the Risk Posture Dashboard uses the same consolidated permission count as the Over-Permission Analytics page, so the numbers shown in the summary card and in the detail drilldown always agree.
Critical Junction Analysis
The junction engine — which identifies identities that act as bridges between low-privilege and high-privilege zones — traverses the graph through HasPermission edges rather than listing every individual ACL permission type separately. This means the junction algorithm automatically captures all current and future ACL permissions without requiring updates each time a new permission type is added.
Change Simulation
When you simulate granting access between two identities, the simulated edge is created as a HasPermission edge in the consolidated format, with the specified permission(s) in the permissions list and an automatically computed severity and weight. When you simulate revoking access, the HasPermission edge between those two identities is marked as tombstoned for the duration of the simulation — all permissions between that pair are considered absent in the simulated view.
Troubleshooting
The graph shows no ACL edges after a sync
Likely cause: The ACL Permissions toggle in the View menu is turned off.
Resolution: Open the View menu and enable the ACL Permissions toggle. This single toggle controls all HasPermission edges.
The graph overview does not show the edge I am looking for
Cause: Overview mode displays up to 500 edges sorted by risk weight. Low-weight edges (Medium or Low severity with few permissions) may not appear if the 500-edge limit is reached by higher-weight paths.
Resolution: Search for one of the two identities involved and use focused mode. Focused mode shows all structural edges and up to 100 inbound and 100 outbound ACL edges for the selected identity, sorted by weight.
A simulation of granting access does not show the expected severity
Cause: Severity is computed from the permissions array. If the simulated grant includes only a Medium-severity permission (such as AddMember), the simulated edge will be classified as Medium, not Critical.
Resolution: Review the permissions listed in the simulation result to confirm which permissions were included. If you need to simulate a Critical-severity grant, specify a Critical-level permission such as GenericAll in the simulation configuration.
Best Practices
- Use focused mode to inspect specific relationships — Hover over a HasPermission edge to see the complete permission list and weight. The label shows only the most severe permission; the full detail is in the tooltip.
- Prioritize Critical-severity edges — In any over-permission or junction analysis, focus remediation effort on identities with Critical or High HasPermission edges first. These represent the direct paths to credential theft and domain compromise.
- Use the ACL Permissions toggle — When investigating structural access paths (group memberships, OU containment, delegation), turn off the ACL Permissions toggle to reduce visual noise. Turn it back on when investigating specific control relationships.