Identity observability gap is widening beyond access reviews

At a glance

What this is: This recap says identity teams can often certify access, but they still struggle to prove what identities actually did inside applications.

Why it matters: That matters because IAM, IGA, and PAM controls can look effective on paper while leaving execution risk, identity dark matter, and agent activity outside governance visibility.

Context

Identity observability is the ability to see what identities actually do inside applications, not just what access they were granted. The problem space starts when IAM controls document intended access but cannot confirm runtime behaviour.

Orchid Security’s recap frames this as a widening gap between governance and execution. The article argues that the rise of non-human identities and AI agents makes that gap more operationally important, because these actors execute faster than review cycles can keep up.

Key questions

Q: What breaks when access reviews are the primary identity control?

A: The control breaks because access can change, be abused, and disappear between review cycles. Review-based governance produces documentation, but not continuous enforcement. In practice, that means investigators can find clean records even when the environment had excessive access at the exact moment the incident occurred.

Q: Why do identity dark matter identities create governance risk?

A: They sit outside normal joiner-mover-leaver and review workflows, so they can keep authenticating and executing after the organisation has lost sight of them. That makes service accounts, local accounts, and application-specific users a durable source of ungoverned access in otherwise mature IAM environments.

Q: How should security teams prove what identities are actually doing inside applications?

A: They should combine identity governance records with application-layer telemetry, then validate live actions against policy instead of relying on certification alone. The key is to observe actual execution, not just stated entitlement, so the team can confirm who acted, what they did, and whether the behavior matched current intent.

Q: Should organisations prioritise execution observability over another access review cycle?

A: Yes, when the main risk is that live application behaviour no longer matches what access records imply. Another review cycle may certify intent again, but execution observability is what reveals whether non-human identities, agents, or users are actually operating within policy.

Technical breakdown

Why access reviews miss execution behaviour

Access reviews are designed to confirm whether access should exist. They are not built to capture what happened after authentication, whether a local account stayed active, or whether a token persisted beyond its intended use. That makes them a governance artefact, not an execution record. When applications enforce or bypass controls differently from policy, the review process can certify intent while missing the actual runtime path. Identity observability fills that gap by joining application telemetry, identity attribution, and policy context.

Practical implication: treat access reviews as an attestation layer, not proof of runtime control effectiveness.

Identity dark matter and the hidden identity inventory

Identity dark matter is the set of identities that authenticate and execute but never fully enter governance workflows. In this article’s framing, that includes service accounts, local accounts, tokens, application-specific users, and other non-human identities without clear ownership. These identities often sit outside periodic certification because they were created for migrations, integrations, or application-specific functions rather than formal IAM processes. Once they are invisible to governance, they become the default inventory for agents and other runtime actors.

Practical implication: inventory application-executing identities separately from user access lists and reconcile ownership continuously.

Execution observability as the missing control plane

Execution observability means being able to answer who acted, what they did, whether it matched policy, and what should happen next. It shifts identity control from static entitlements to runtime behaviour, which is the point where risk actually materialises. For non-human identities, that means tracing the chain from identity to action to target. For human access, it means verifying that the post-login activity still matches the approved purpose. The article’s core claim is that governance fails when it stops at intent.

Practical implication: add runtime identity telemetry and correlation to IAM, IGA, and PAM workflows so controls can evaluate execution, not just access.

NHI Mgmt Group analysis

Identity governance is now an execution problem, not just an access problem: The article correctly separates what access was approved from what actually occurred inside the application. That distinction matters because the control gap is no longer at provisioning alone; it is at runtime attribution and behavioural proof. Practitioners should read this as a warning that access intent without execution evidence is incomplete governance.

Identity dark matter is the real baseline risk in mature environments: The article’s service accounts, tokens, local accounts, and application-specific users are not edge cases. They are the hidden population that often outlives the governance model built for employees and periodic reviews. That makes identity observability a structural requirement for NHI programmes, not an optional telemetry enhancement.

Access reviews were designed for stable identities, but runtime actors are not stable: The article’s strongest insight is that certification workflows assume identities can be reviewed before or after use in a meaningful window. That assumption weakens when non-human identities execute continuously and agents move faster than review cycles. The implication is a governance model that must validate action, not merely authorise presence.

Identity observability should become the bridge between IAM, IGA, and PAM: IAM defines intent, IGA certifies entitlement, and PAM governs elevated access, but none of them alone proves what happened inside the application. The article is pointing at a missing middle layer that connects policy, behaviour, and accountability. That is the control gap practitioners now need to name explicitly.

Runtime trust debt: The article exposes a growing gap between what identity teams assume is controlled and what applications actually allow to execute. That gap compounds when agents inherit over-permissioned or orphaned identities and act faster than governance cycles can respond. Practitioners should treat runtime trust debt as a measurable programme risk, not a theoretical concern.

What this signals

Identity observability is the control layer that connects policy to runtime behaviour: Security teams that stop at entitlement validation will keep missing the gap between what the IAM stack approved and what the application actually executed. That gap is now where non-human identities and agent workflows create the most governance friction.

Runtime attribution will matter more than certification cadence: If an organisation cannot link an action to a specific identity, owner, and target, it cannot defend accountability when something goes wrong. The practical shift is from asking whether access was approved to asking whether execution can be explained.

Application telemetry is becoming an identity control input, not just an operations signal: Once identity control moves into the execution layer, telemetry stops being a monitoring extra and becomes part of governance evidence. That is the operational change IAM, IGA, and PAM programmes need to plan for.

For practitioners

• Map application-executing identities Build a separate inventory for identities that act inside applications, including service accounts, local accounts, tokens, and app-specific users. Reconcile that inventory against formal IAM records so hidden execution paths are visible.
• Correlate runtime actions to identity ownership Link each significant application action to a human owner, non-human owner, or agent owner, and preserve the chain from identity to tool to target. If ownership cannot be assigned, classify the identity as governance debt.
• Shift reviews from entitlement to behaviour Use access reviews to confirm intent, but add continuous behavioural checks that compare live execution against approved purpose. This closes the gap between what policy says and what the application actually sees.
• Extend PAM into application execution Apply privileged-access controls to the point where elevated actions occur, not only where credentials are issued. That includes monitoring persistent tokens, local admins, and other identities that can act without a fresh approval cycle.

Key takeaways

• The article argues that identity governance is increasingly failing at runtime visibility, not at policy definition.
• Hidden service accounts, tokens, and application-specific identities create an execution layer that periodic reviews do not capture.
• The practical response is to connect entitlement controls to live application behaviour so governance can prove what actually happened.

Key terms

• Identity Observability: Identity observability is a continuous governance approach that correlates identity activity with business context, telemetry, and policy state. Instead of checking access at a single point in time, it tracks what an identity can do, what it did, and why that action matters to the business.
• Identity Dark Matter: Identity dark matter is the hidden mass of old grants, unused credentials, and inherited access that exists in an environment but is not actively understood. In NHI programmes it becomes dangerous because autonomous systems can discover and reuse it at machine speed.
• Execution surface: An execution surface is any system or environment where an identity can actually do work, such as an application, trigger, endpoint, or API. For AI agents, execution surfaces matter because risk appears where action is taken, not only where authentication occurs.
• Runtime Attribution: Runtime attribution is the process of tying an action inside an application to a specific human, non-human identity, or agent and its owner. It matters because accountability depends on proving who acted, through which mechanism, and against which target.

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 IAM programme, it is worth exploring.