TL;DR: Opal Security says access path queries now trace every person's and agent's access back to its source, including inherited access through nested groups, so teams can move straight from a query result into a campaign or audit binder. The underlying problem is that access graphs have outgrown manual tracing, and agent access makes that governance gap harder to ignore.
At a glance
What this is: Opal Security has added access path queries that show how people and agents reach assets through direct and inherited relationships, not just endpoint permissions.
Why it matters: This matters because identity teams need evidence of path-based access, not just role membership, when they scope reviews, prove SoD, and explain how a person or agent reached a sensitive system.
👉 Read Opal Security's introduction to access path queries and graph-based access review
Context
Access path queries are a way to trace how a principal reaches an asset through the actual chain of grants, groups, roles, and entitlements. That matters because modern access is rarely expressed in one place, and the governance problem is increasingly about path analysis rather than simple entitlement lookup.
For identity teams, the issue is not only visibility but auditability. When humans, service accounts, and AI agents can all inherit access through nested structures, programmes that rely on exports or manual comparison lose precision just when reviewers need exact source-to-destination evidence.
Key questions
Q: What breaks when access reviews ignore inherited paths?
A: Reviews lose the ability to explain why access exists, which means inherited privilege, nested groups, and hidden upstream grants can slip past governance. The result is weak audit evidence and false confidence in recertification, because reviewers are judging an endpoint rather than the actual route to reach it.
Q: Why do path-based access queries matter for SoD controls?
A: They let teams test conflicting access conditions against the real authority chain instead of a flat entitlement list. That matters because segregation of duties can be violated by inheritance, not just by obvious direct grants, and the control only works when the review scope matches the actual path to privilege.
Q: How can security teams prove how a user or agent reached a sensitive system?
A: By preserving the full source-to-asset chain, including nested groups, inherited roles, and any intermediary entitlements that contributed to effective access. That gives auditors and incident responders a defensible explanation instead of a manual reconstruction from multiple exports.
Q: Should organisations govern agents and humans with the same access lineage rules?
A: Yes, because the governance problem is the path to reach, not the biology of the principal. If an agent, service account, or employee can reach a sensitive asset, teams need the same lineage evidence and the same review logic to decide whether that access is justified.
How it works in practice
Why access graphs become opaque over time
Access graphs grow hard to reason about because a single effective permission can be assembled from multiple edges: direct grants, group membership, nested groups, role bindings, and app-specific entitlements. Each edge may be valid on its own, but together they create a lineage problem, where the important question is not just what access exists, but how it was assembled. In governance terms, the graph becomes the record of authority, and the path is the proof. Without path-aware queries, teams are forced to reconstruct that proof from exports, tickets, or tribal knowledge. That leaves both reviews and investigations too dependent on manual interpretation.
Practical implication: Model access as a traversable graph so reviewers can see the lineage of authority, not just the final permission.
How access path queries support evidence and segregation of duties
A path query returns the relationship between a principal and an asset, including the intermediate access edges that explain why the relationship exists. That is materially different from a flat entitlement report because it lets a reviewer test conditions such as whether someone with access to a sensitive system also holds elevated access elsewhere. In practice, that turns segregation of duties into a queryable rule, rather than a spreadsheet exercise. It also means audit evidence can show the exact chain that produced access, which is stronger than a snapshot of current entitlements without context.
Practical implication: Use path-based evidence when SoD and audit questions depend on explaining the full route to access.
Why agent access has to be governed with the same path logic as human access
Once agents are in the access graph, the control problem changes from managing only people to managing principals that can be created, scoped, and reused differently from human users. If an agent reaches more than its purpose requires, the issue is often not the endpoint permission itself but the path that granted it through a group, role, or inherited edge. That is why tracing source-to-reach relationships matters for NHI governance: the same effective access can arise from a human, a service account, or an agent, but the governing evidence must be the same. Otherwise, agents become a governance blind spot rather than a separate class of identity.
Practical implication: Apply the same path review standard to agents as to people, then revoke the upstream edge that created excess reach.
NHI Mgmt Group analysis
Access path visibility is now a governance requirement, not a reporting enhancement. Flat entitlement views are no longer enough when effective access is assembled through multiple inheritance layers. The practical consequence is that identity teams must treat path lineage as first-class evidence for reviews, audits, and investigations.
Path-based review is the right unit of control for modern SoD. Separation of duties fails when reviewers can only see endpoint access and not the upstream combination that produced it. A saved query over the access graph is a stronger governance primitive than a static access list because it reflects current state and the exact route to privilege.
Agent access should be governed with the same lineage standard as human access. When agents sit in the same graph as employees and service accounts, the distinction that matters is not whether the principal is human but whether the path to reach a sensitive asset is explainable and reviewable. That aligns with NHI governance as a lifecycle and evidence problem, not merely an inventory problem.
Auditability collapses when access evidence excludes the path. A reviewer who can see only the end state cannot tell whether access was intentional, inherited, or accidental. The named concept here is identity path provenance: the requirement to preserve the chain of authority that led to effective access. Practitioners should treat that provenance as part of the access record itself.
The access graph has become the control surface. The governing question is no longer who belongs to which role in isolation, but which chains of inheritance create reach that cannot be defended in review. That shifts the operating model from periodic cleanup to continuous graph interrogation.
What this signals
Identity path provenance: access governance now depends on preserving the full chain that explains effective access, because endpoint-only views cannot support audit, review, or incident response at scale. Teams that cannot reproduce the route to privilege will struggle to defend it.
The practical shift is toward graph-native governance, where access campaigns, SoD checks, and investigation workflows are driven from path queries rather than static entitlement reports. That matters most where agents and service accounts sit beside people in the same control plane, because the question becomes whether the path to reach is reviewable and revocable.
For practitioners
- Define path-based review scopes Scope access reviews to principal-to-asset paths instead of whole groups or entire applications, so reviewers assess only the reach that matters.
- Preserve access lineage in audit evidence Export the full chain behind each effective permission, including nested groups and inherited edges, so auditors can see why access exists.
- Apply the same query standard to agents Treat AI agents and service accounts as first-class principals in access queries, and trace any excess reach back to the upstream grant or group.
- Turn separation of duties into a saved query Encode SoD checks as reusable queries that compare path results against conflicting access conditions, then publish them for repeated use.
- Use path results to drive revocation Remove the specific upstream edge that created unintended access, rather than only changing the visible endpoint entitlement.
Key takeaways
- Access governance fails when teams can see only the endpoint permission and not the chain that produced it.
- Path-aware queries give auditors and reviewers a defensible explanation for inherited access, nested groups, and SoD conflicts.
- Treating agents as principals in the same graph as people makes access reviews more precise and revocation more targeted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article focuses on tracing and reducing excess access for agents and service accounts. |
| NHI-01 — Improper Offboarding | Inherited access and agent reach must be revoked when the principal or its purpose changes. | |
| Recommendation — Use path queries to identify and remove upstream grants that create overprivileged NHI reach. Review path lineage during offboarding to revoke inherited access before it persists. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Path queries directly support managing and reviewing effective authorisations. |
| Recommendation — Map effective access paths to PR.AA-05 so review evidence reflects actual authorisations. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is about controlling who can reach what through account and group relationships. |
| Recommendation — Audit account and group relationships to remove inherited reach that is no longer needed. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Inherited access paths can enable credential use and movement across sensitive assets. |
| Recommendation — Trace access paths that could support credential access or lateral movement and close the upstream edge. | ||
Key terms
- Access Path: An access path is the route an identity uses to reach a resource, whether directly, through a role, via a group, or through inherited permissions. In NHI governance, access-path analysis matters because machine identities often gain broad access through indirect relationships that are easy to miss.
- Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
- Inherited Access: Inherited access is permission a tool receives from a connected user, service account, or integration rather than from a purpose-built identity. It often hides privilege expansion because the tool appears lightweight while actually operating under broad, durable entitlements.
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
What's in the full announcement
Opal Security's full post covers the operational detail this post intentionally leaves for the source:
- How access path queries are constructed in OpalQuery using principal and asset filters
- How natural language input is translated into access graph queries and then validated against the underlying filters
- How access campaigns are expected to consume query results once that workflow is available
- How Risk Center findings map into the same query-driven access review workflow
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.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org