Introducing Access Path Queries: Trace every person's and agent's access to its source

Access path queries are now generally available in OpalQuery.

Query the actual relationships between principals and what they can reach, including employees, service accounts, and AI agents, along with access inherited through nested groups, and take the results straight into a campaign or an audit binder.

Why we built this

Your access graph gets harder to see clearly as your organization changes. Teams reorganize, people move between roles, and the structures that carry access accumulate along the way. After a few years you have an access graph that is difficult to reason about directly.

Part of that is because access is expressed through several structures at once: direct grants, group membership, nested groups, roles on a resource, entitlements attached to an app. One person’s access to a single database might come from any of them, or from a path that runs through three hops in different systems.

Most teams solve that with tooling around the edges. You write SQL against an export, maintain a dashboard, or file a ticket with the engineer who knows the schema. Those approaches stop scaling as access graphs grow and auditability matters more, especially now that agents and non-human identities are being added to your environment.

So we built access paths into the core platform. You can query these edges with natural language or a simple query builder and act on the results.

How access path queries work

An access path query returns the relationship itself: principal to asset, with direct and inherited access both represented as rows in the result.

You build one by describing each side of the path. The Principal filter scopes who you care about, and the Asset filter scopes what they can reach. Principals can be users, service accounts, or agents. Both take the same filters you already use in OpalQuery: entity type, item type, name, app, tag, IDP status, and admin owner.

Each side also has Advanced Access Filters, which narrow that side by its own access edges. This is what makes separation of duties workable in a single query. Asking for principals who can reach billing-prod and who also hold admin access somewhere else previously meant exporting two result sets and comparing them by hand.

Natural language works the way it does elsewhere in OpalQuery. Describe the path in plain English, check the filters it generates, adjust anything it got wrong, and run it. The filters remain the source of truth, so you can always see what actually executed.

What this changes

Review scoping gets precise. You can scope a review to the specific paths that carry risk rather than to everyone attached to a sensitive resource.

Audit evidence answers the follow-up question. Exports carry the full path instead of just the endpoint, so when an auditor asks how someone ended up with access, the answer is in the row.

Agents are held to the same standard as people. When an agent can reach more than its purpose calls for, you can see exactly which grant or group put it there.

Separation of duties becomes a saved query. Encode the rule once, make the query public, and any admin in your organization can run it against current state.

Investigations get shorter. When you are working an incident, finding out what an identity can reach and how it got there is one query rather than an afternoon of tracing group nesting by hand.

From query to action

Node queries let you query the entities in your access graph. Access paths add the edges between them, which is where most of the risk sits. With both, you can examine the whole graph, direct and inherited, human and agent, without a ticket or an export.

The next step is acting on what a query returns. A path query gives you a precise population, which is exactly what an access campaign needs. Rather than scoping a UAR to an entire resource or group and leaving reviewers to sort out the noise, you will scope it to the paths the query returned, so every row a reviewer sees is there for a reason. The same goes for agents: when Risk Center flags access that goes beyond an agent's purpose, the path behind it is one query away.

Creating an access campaign directly from query results is what we are building next, with JIT and revocation from results after that. The pattern is the same each time: ask a question, get the exact set back, and act on it without leaving the page.

Getting started

Access path queries are available to Opal Admins and Read-Only Admins. Open Queries in the admin sidebar to build one, or check the docs.

For more on how agents fit into the access graph, Sameer Mehta goes deeper on the thinking behind Opal Zero in this Q&A.