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

Why This Matters for Security Teams

When an identity is compromised, the role name in the directory rarely tells the full story. Real-world reach is shaped by inherited group membership, explicit denies, nested roles, resource policies, and delegated trust paths that are easy to miss during an incident. For NHI security, this matters even more because service accounts, API keys, and agent identities often accumulate permissions over time and are reused across systems. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in its Ultimate Guide to NHIs, which is exactly why teams need a defensible way to calculate effective permissions instead of trusting the source record. NIST’s SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control must be evaluated as implemented, not assumed from labels alone. In practice, many security teams discover excessive reach only after an alert shows lateral movement that the original role review never predicted.

How It Works in Practice

Effective permission analysis starts by building the identity’s complete access graph. That means collecting direct grants, inherited membership, nested role assignments, resource-based policies, temporary elevation, and any deny rules that override broader allows. The answer should be computed per resource and per action, because “can read bucket A” and “can write bucket B” are different questions, even when the identity is represented by a single account object. A practical workflow usually includes:

• Resolve the identity across IAM, directory, cloud, SaaS, and PAM systems.
• Expand group and role nesting to expose transitive permissions.
• Apply explicit deny logic before finalizing effective access.
• Include resource policies, trust relationships, and delegation chains.
• Separate standing privilege from just-in-time elevation.
• Score the resulting reach against sensitive assets and active attack paths.

For non-human identities, this is best treated as a continuously refreshed computation, not a quarterly review. The 52 NHI Breaches Analysis shows how quickly credential misuse becomes incident material when hidden permissions are left in place, while the Ultimate Guide to NHIs — Why NHI Security Matters Now ties weak visibility to broader operational exposure. Where teams have automation maturity, they export these effective-permission results into triage, blast-radius analysis, and access review queues. Where they do not, analysts end up reading policy documents manually and still miss cross-account trust. These controls tend to break down when permissions are spread across multiple clouds and SaaS platforms because policy semantics differ and the identity graph is no longer coherent.

Common Variations and Edge Cases

Tighter permission computation often increases operational overhead, requiring organisations to balance precision against speed during incident response. The biggest tradeoff is between a fast approximation and a fully resolved answer. A quick view may be good enough to prioritize containment, but a complete view is needed before revoking access, rotating secrets, or declaring blast radius. Current guidance suggests treating these situations as special cases rather than forcing one universal model:

• Resource policies may grant access even when the source role looks harmless.
• Explicit denies can narrow reach, but only if the engine evaluates them in the same order as the runtime platform.
• Nested roles and role chaining can hide privilege escalation paths that are not obvious in the source system.
• Ephemeral credentials and JIT access can make historical permission snapshots misleading if timing is ignored.
• For agentic workloads, effective permission must reflect what the agent can do at runtime, not just what the account was intended to do.

This is where trust in static IAM reports fails. An access review export can say one thing while a live policy engine says another, especially across federated SaaS, cloud-native permissions, and delegated admin models. The result is that teams should validate the effective-permission engine against a known set of test identities and sensitive resources before using it for incident decisions. There is no universal standard for this yet, but the best practice is evolving toward runtime policy evaluation and continuous recomputation rather than point-in-time role inspection.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How do identity teams fit into application security governance?
• How do security teams know whether enrichment is actually improving governance?
• How should security teams govern mobile apps that sit inside identity workflows?