Effective permissions are the missing layer in identity threat analysis

At a glance

What this is: This blog argues that effective permissions, not assigned roles, are the real basis for understanding what a compromised identity can do.

Why it matters: For IAM, SOC, and IGA teams, resolving effective permissions is what turns access review, investigation, and severity scoring from guesswork into defensible decisions.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Exaforce's analysis of effective permissions in SaaS and cloud investigations

Context

Effective permissions are the computed, real-world actions an identity can take after all allows, denies, inheritance paths, and policy constraints are evaluated. In modern IAM, the assigned role is often only a starting point, because the final answer depends on how multiple policy layers interact across SaaS and cloud infrastructure.

That matters directly to identity governance and SOC work. If teams cannot determine effective permissions, they cannot size blast radius accurately, classify high-risk identities consistently, or tell whether an alert involves a read-only account or one that can modify controls and expand access.

In AWS, GitHub, Slack, and similar systems, the permission story is rarely flat. A role may look powerful on paper but be constrained by branch protection, service control policies, resource policies, or inherited denies, which makes the resolved outcome more important than the visible entitlement set.

Key questions

Q: How should security teams determine what a compromised identity can actually do?

A: They should compute effective permissions rather than relying on the role or group shown in the source system. That means evaluating allows, explicit denies, inheritance, resource policies, and role chaining together. The result is a defensible view of real reach that can be used for triage, blast-radius analysis, and access review.

Q: Why do assigned roles create blind spots in cloud investigations?

A: Assigned roles often hide the final policy outcome. In cloud platforms, a role may appear broad, but explicit denies, service control policies, and resource policies can narrow or nullify the actual access. Investigators who stop at the assigned role risk overestimating or underestimating impact, which distorts containment priorities.

Q: How do effective permissions improve identity governance decisions?

A: They make access reviews and admin classifications consistent across systems that use different permission models. Instead of debating labels, teams can review the resolved set of actions an identity can perform and decide whether that access is justified, excessive, or high risk.

Q: What should teams do when an alert involves an identity with unclear privilege scope?

A: They should pause severity scoring until the permission graph is resolved. The first question is not whether the login was suspicious, but whether the identity can modify controls, reach sensitive resources, or chain into higher privilege. That determines whether the alert is informational, material, or urgent.

Technical breakdown

Why assigned roles are not the same as effective permissions

Assigned roles describe what was granted, not what is actually executable after evaluation. Effective permissions are the net result of combining identity-based grants, group membership, resource policies, explicit denies, inheritance, and conditional constraints. In SaaS this may be relatively simple because the model is shallow and role sets are small. In cloud environments, however, the permission graph can span accounts, roles, policies, and service-level controls, so a visible privilege often overstates actual capability.

Practical implication: build investigations and access reviews around resolved privilege, not the role label shown in the console.

Why AWS and similar cloud platforms make permission resolution difficult

Cloud IAM models can contain multiple overlapping policy layers that each affect the final outcome. In AWS, permissions may come from direct policies, groups, permission sets, role assumption, resource policies, and service control policies, and explicit denies override allows. That means two identities with the same apparent role can have very different effective access depending on account structure, policy order, and recursive role chaining. Without resolving that graph, analysts will misread who can modify, read, or delete resources.

Practical implication: assess cloud access through policy evaluation logic, not by inspecting a single role or permission set.

How effective permissions improve threat context and blast radius

Effective permissions turn identity data into operational context. Once teams know what an identity can actually do, they can estimate lateral movement paths, identify cross-account impact, and distinguish a low-risk login from a high-impact compromise. This is especially important when the same person or service appears across multiple systems, because a unified view of access makes severity depend on actual reach rather than on naming conventions or stale entitlement records.

Practical implication: feed resolved permissions into SOC triage so severity reflects real reach, not speculative worst case.

Threat narrative

Attacker objective: The objective is to determine and exploit the identity's real operational reach so the attacker can prioritise high-value actions and maximize damage.

1. Entry begins when an attacker or investigator targets a compromised identity whose visible role suggests more access than it really has, making the first question whether the entitlement set can be trusted.
2. Escalation occurs when overlapping policies, inherited grants, or role chaining are used to discover the identity's true ability to reach additional resources, including cross-account or cross-system paths.
3. Impact follows when the resolved permission set confirms whether the identity can modify controls, access sensitive data, or move laterally, which determines the true blast radius of the compromise.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Effective permissions are now the operational truth of identity security. Assigned access is increasingly an approximation, not an answer, because modern SaaS and IaaS environments combine multiple policy layers, inheritance paths, and explicit denies. That is why blast-radius analysis, access reviews, and SOC triage all fail when they rely on surface entitlements alone. Practitioners should treat resolved privilege as the control plane for risk decisions.

Effective permissions create the missing bridge between IAM and SOC work. IAM teams often optimise for provisioning and review, while SOC teams need to know what compromise actually enables. Those are different questions, but they converge on the same dataset: computed access. When the resolved permission graph is available, an alert can be scored against real reach rather than assumed reach, which improves escalation decisions and reduces false severity inflation.

Permission graphs expose a persistent governance gap: visibility without resolution. Many organisations can list who has access, but cannot reliably answer what that access becomes after denies, inheritance, and chaining are applied. That gap matters because review programs built on incomplete access data create a false sense of control. Practitioners should recognise that incomplete permission resolution is itself a governance failure, not just an engineering inconvenience.

Effective permissions should become the named concept behind identity blast radius. The useful unit of measurement is not the role badge, the group label, or the admin flag, but the computed set of actions an identity can actually execute. That concept applies across human users, service accounts, and machine identities, and it is the most defensible way to connect IAM data to operational risk. Security teams should make resolved permission the default language of investigation and review.

Cross-source identity stitching becomes more valuable when permission data is resolved. A user may look low risk in one application and high risk in another, but the combined picture is what determines compromise impact. This is where identity governance and security operations overlap most directly. Practitioners should use cross-system resolution to identify the identities whose combined access makes a single compromise materially more dangerous.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Effective permission resolution becomes more urgent as identity populations scale, especially when service-account sprawl and cross-account access are already difficult to govern.

What this signals

Effective permissions will become a baseline control for any SOC that wants credible blast-radius analysis. If teams cannot compute real access, they will continue to overreact to harmless alerts and underreact to high-reach compromises. The operational shift is to make resolved privilege part of the incident record, not an optional enrichment step.

The same logic applies to identity governance programmes that now span human accounts, service accounts, and machine identities. As environments fragment across SaaS and cloud, the organisations that can resolve access consistently will have a measurable advantage in audit quality, investigation speed, and containment confidence.

Identity blast radius is the right named concept for this problem. It is the difference between what a user appears to have and what that identity can actually execute after all policy logic is applied. Teams that cannot measure blast radius at the identity level will keep treating access reviews as documentation exercises rather than risk controls.

For practitioners

• Resolve permissions before triage Require SOC analysts to use computed effective permissions when scoring identity alerts, so severity reflects what the identity can actually do across accounts, services, and policy layers.
• Map explicit denies into access reviews Include service control policies, resource policies, and other deny logic in every access review so reviewers do not sign off on access that is visible but not executable.
• Standardise admin definitions on effective reach Define an admin as any identity that can increase its own access or another identity's access, then tag those identities consistently across SaaS and cloud environments.
• Stitch cross-source identity records Unify usernames, roles, and permissions across SaaS and IaaS so investigators can see combined privilege and not underestimate risk from fragmented identity records.

Key takeaways

• Effective permissions are the real unit of identity risk because assigned roles often misstate what an identity can actually execute.
• Cloud and SaaS policy layering makes resolved privilege essential for accurate blast-radius analysis, access reviews, and SOC triage.
• Security teams should base severity, admin tagging, and remediation on computed access, not on labels that hide the policy outcome.

Key terms

• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
• Permission Graph: The combined structure of policies, roles, groups, resource rules, and deny logic that determines what an identity can do. It becomes difficult to reason about as environments scale because access is distributed across multiple control points. Security teams use the graph to resolve privilege rather than guess it.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Exaforce's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how permission evaluation works across AWS, GitHub, Slack, and similar systems
• Screenshots of the effective permission graphs and admin tagging views used in the product
• The remediation workflow that points analysts to the specific policy, role, group, or permission set to change
• Examples of runtime usage signals joined to permission data for better risk scoring

👉 The full Exaforce post shows how permission resolution changes remediation, admin tagging, and severity scoring.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.