In identity security, an identity graph is a connected model of human and non-human identities, permissions, roles, applications, and resources. It shows how access flows through direct grants, group membership, role inheritance, delegation, OAuth permissions, and application trust.
Instead of answering only, “What permissions are assigned to this account?” an identity graph helps security teams answer:
How can this identity reach that resource?
A contractor might have no direct permission to access a sensitive resource. However, the contractor may belong to a nested group that inherits a cloud role, which grants access to an application connected to that resource.
An identity graph reveals the complete path:
Contractor → Group → Cloud role → Application → Sensitive resource
This connected visibility helps security teams investigate identity risk, reduce excessive access, govern non-human identities, support access reviews, and understand the potential impact of a compromised account.
Terminology note: In customer data and advertising, “identity graph” often describes a system that connects consumer identifiers across devices and channels. This article focuses specifically on identity graphs used for enterprise identity security.
Key Takeaways
- An identity graph connects identities, permissions, roles, applications, and resources.
- It reveals indirect access created through nested groups, inherited roles, delegation, OAuth grants, and trust relationships.
- The graph shows what an identity could access. Activity data is needed to determine what it actually accessed.
- Security teams use identity graphs for investigations, least privilege, access reviews, audit evidence, and non-human identity governance.
- An effective graph depends on broad source coverage, normalized relationships, accurate identity resolution, and current data.
- Offroad’s Access Graph is one component of its broader Identity Fabric, which connects access with activity, ownership, policies, approvals, and business context.
How Does an Identity Graph Work?
An identity graph represents an organization’s identity environment as connected entities and relationships.
The entities often called nodes can include:
- Employees, contractors, partners, and administrators
- Service accounts, workloads, API keys, and machine identities
- OAuth applications and AI agents
- Groups, roles, policies, and entitlements
- SaaS applications, cloud accounts, systems, data, and other resources
- Devices, teams, managers, resource owners, and business units
The relationships often called edges describe how those entities connect. For example:
- A user belongs to a group
- A group inherits a role
- A role grants access to an application
- An application can reach a resource
- A service account is owned by a team
- An OAuth application has been granted a scope
- An identity used a permission
Connecting these relationships allows security teams to follow access across systems instead of reviewing every permission as an isolated record.
A Simple Identity Graph Example
Consider a contractor who appears to have no direct access to a sensitive production resource.
A conventional access report might show the contractor’s immediate permissions and return nothing concerning. An identity graph could reveal that:
- The contractor belongs to a regional engineering group.
- That group is nested inside another group.
- The nested group can assume a production cloud role.
- The cloud role grants access to an application.
- The application can reach the sensitive resource.
No individual relationship necessarily looks dangerous in isolation. The potential exposure becomes visible when the complete path is connected. This is the difference between direct access and effective access. Direct access comes from an explicit grant. Effective access includes every valid route an identity can use to reach a resource.
Why Access Reports Miss Indirect Access
Access reports remain useful for reviewing direct assignments, certifications, and point-in-time access records. The limitation is that access rarely exists in only one system or one layer. Modern authorization is distributed across:
- Identity providers
- Cloud IAM systems
- SaaS applications
- Privileged access platforms
- Identity governance systems
- Custom applications
- OAuth and API integrations
- Workload and service identities
A user may have no direct administrative role while inheriting powerful access through several groups. A service account may appear restricted in its source system while gaining additional reach through a workload role or application trust.
Removing one permission may also fail to eliminate access when an alternative path remains.
An identity graph treats privilege as a relationship problem. It enables teams to ask:
- How can this identity reach a critical resource?
- Which relationship creates the access?
- Are there alternative paths to the same resource?
- Would removing this grant eliminate effective access?
- Where does a low-privilege identity become powerful?
- Who owns the identity, permission, or resource involved?
What Is the Difference Between an Identity Graph and an Access Report?
An access report usually lists identities and their recorded permissions. It is useful for questions such as:
- Which users have a particular role?
- Which applications are assigned to this employee?
- Which entitlements should a manager review?
An identity graph adds the relationships between those records. It helps answer:
- Why does this person have access?
- Which groups and roles create the access?
- What can this identity reach indirectly?
- Would access remain after one grant is removed?
- Which resources are exposed if the identity is compromised?
The two approaches are complementary. Access reports provide an inventory. Identity graphs provide connected context.
Identity Graph Use Cases
Investigating Compromised Identities
When an identity is compromised, investigators need to understand its potential blast radius quickly.
An identity graph can identify the resources the account may be able to reach and the permissions or relationships responsible for that access. Investigators can examine inherited roles, delegated permissions, group memberships, OAuth grants, and application trust without manually reconciling separate reports.
However, reachability is not proof of activity.
The graph shows what the identity could reach. Authentication logs, application events, endpoint telemetry, and other activity data help establish what it actually touched.
Combining both views helps investigators answer:
- Which sensitive resources were potentially exposed?
- Which permissions could the identity use?
- Which resources did it access?
- Was the activity consistent with its expected purpose?
- Which access paths should be contained first?
Enforcing Least Privilege
Least privilege requires more than finding accounts with broad role names. Teams need to compare effective access with actual usage, ownership, business purpose, and current responsibilities.
An identity graph can help identify:
- Permissions retained after a role change
- Temporary access that was never removed
- Redundant paths to the same resource
- Privileges inherited through nested groups
- Unused access without a current justification
- Identities with more access than comparable peers
- Identities or resources without an accountable owner
This turns least privilege from an occasional cleanup project into an ongoing access-management process.
Strengthening Access Reviews
Many access reviews provide reviewers with a list of entitlements but not enough information to make a safe decision.
A useful review should explain:
- Whether the access has been used
- Why it was originally granted
- Who approved or owns it
- Whether it still matches the identity’s role
- What might break if it is removed
- Whether an approved change was completed
An identity graph can assemble the relationships behind an entitlement, helping reviewers evaluate effective access instead of approving isolated rows.
A graph does not make an organization compliant by itself. Defensible review evidence still depends on complete source coverage, current data, documented policies, reliable ownership, approval records, and verified changes.
Governing Non-Human Identities
Service accounts, workloads, API keys, OAuth applications, machine identities, and AI agents often fall outside the lifecycle controls applied to employees.
These identities may:
- Lack a clear owner
- Outlive the project that created them
- Hold long-lived credentials
- Accumulate permissions over time
- Operate through several layers of application trust
- Receive less frequent access reviews
An identity graph can model non-human identities as first-class entities rather than exceptions.
Security teams can use the graph to identify:
- Service accounts with production access but no owner
- OAuth applications with unnecessary write permissions
- Workloads that can assume privileged roles
- AI agents with access beyond their intended purpose
- Tokens connected to retired applications
- Non-human identities with an excessive blast radius
Activity and business context are especially important for these identities. A service account may legitimately operate at unusual hours, while an AI agent may perform thousands of actions during a period in which a human would perform only a few.
Supporting Audit Evidence
Auditors and control owners commonly ask:
- Who can access a sensitive system?
- Why does that access exist?
- Who approved it?
- Does it align with policy?
- Was a requested change completed?
An identity graph can support those requests by showing the path between an identity and a protected resource, including the groups, roles, grants, and trust relationships involved.
It strengthens the explanation behind an access decision, but it does not guarantee compliance. Reliable audit evidence still requires documented controls, complete and current data, approval records, accountable owners, and evidence that changes were implemented.
What Makes an Identity Graph Effective?
An identity graph is only as useful as the data and relationships behind it.
Broad Source Coverage
Relevant data may come from:
- Identity providers
- Cloud IAM environments
- SaaS applications
- HR systems
- Privileged access platforms
- Identity governance systems
- Endpoint and device-management tools
- Ticketing and approval systems
- Security and activity telemetry
- Custom authorization stores
Missing systems create blind spots. Organizations should prioritize sources based on the identities, permissions, and resources most important to their environment.
A Normalized Relationship Model
Every system describes access differently.
One platform may use groups and roles, while another uses policies, scopes, entitlements, tokens, or application-specific grants. Those concepts need to be normalized without removing the details required to explain access accurately.
Accurate Identity Resolution
The same person, service, or application may appear under different identifiers across several systems.
Identity resolution connects those records while avoiding incorrect merges between separate identities. Duplicate accounts, missing owners, stale resources, and incomplete entitlement data can reduce the graph’s accuracy.
Fresh, Queryable Data
Identity relationships change frequently.
Employees move between teams, temporary permissions expire, applications receive new scopes, and cloud roles are modified. A graph built from stale snapshots may be useful for historical reporting but unreliable for incident response or current access decisions.
Activity and Business Context
A broad permission is not automatically inappropriate. Its risk depends on who holds it, why it exists, where it can be used, and whether its usage matches the identity’s expected purpose.
Activity, ownership, policies, approvals, environment, and business context help teams distinguish justified access from access that requires investigation or removal.
What Are the Limitations of an Identity Graph?
An identity graph is not a complete identity-security program.
Its limitations include:
- It can represent only the systems and relationships visible to it.
- It may miss authorization logic embedded inside custom application code.
- Stale or incomplete data can create inaccurate access paths.
- Reachability does not prove that access was used.
- A visible path does not automatically mean the path is exploitable.
- The graph cannot establish business justification without ownership and organizational context.
- Visibility alone does not remediate excessive or dangerous access.
Security teams still need policies, accountable owners, approval workflows, remediation, verification, and recovery procedures.
These limitations are why a graph becomes more valuable when it is connected to activity and business context.
How Offroad Uses an Identity Fabric
Offroad’s Access Graph is one component of its broader Identity Fabric.
The Identity Fabric connects identities, access, permissions, activity, tickets, ownership, approvals, policies, and business context across the organization.
This distinction matters. An Access Graph can show how an identity reaches a resource. Activity helps determine whether the access was used. Ownership, policies, approvals, and business context help determine whether the access or activity makes sense.
Offroad’s AI agents use this connected context to:
- Discover identity posture issues and potential runtime threats.
- Investigate why access exists, how it is used, who owns it, and what might break if it changes.
- Remediate clear, policy-approved issues or route sensitive decisions to the appropriate human.
The agents can help remove unused access, narrow excessive permissions, revoke unnecessary grants, and update downstream records.
For sensitive, ambiguous, or high-impact changes, Offroad prepares the relevant context and routes the decision to an owner or approver rather than making an unsupported assumption.
Offroad also records and verifies actions. Where the underlying system supports it, relevant configuration can be retained so a change can be safely reversed if necessary.
The objective is not simply to visualize relationships. It is to turn fragmented identity data into completed, explainable identity-security work.
Conclusion
An identity graph helps security teams understand how access flows across people, groups, roles, applications, non-human identities, and resources.
Unlike a flat report, it can expose indirect permissions, nested relationships, redundant paths, and application trust. This makes identity graphs useful for investigations, least-privilege programs, access reviews, audit evidence, and non-human identity governance.
The graph is still only a foundation.
Security teams need activity data to understand what happened, organizational context to determine whether access is appropriate, and reliable workflows to remediate and verify issues.
Offroad’s Identity Fabric brings those elements together so security teams can move from identifying identity risk to resolving it.
Frequently Asked Questions
What is an identity graph in identity security?
An identity graph is a connected model of human and non-human identities, permissions, roles, applications, and resources. It reveals how access flows through direct grants, groups, inherited roles, delegation, OAuth permissions, and trust relationships.
Is an identity graph the same as a customer identity graph?
No. In customer data and advertising, an identity graph usually connects consumer identifiers such as email addresses, devices, cookies, and customer records. In identity security, it connects workforce and machine identities to permissions, applications, systems, and resources.
What is the difference between an identity graph and an access report?
An access report generally lists recorded permissions. An identity graph maps the relationships that create effective access, making indirect paths through groups, roles, delegation, and trust easier to understand.
What is the difference between an identity graph and an identity directory?
An identity directory stores identity records and attributes. An identity graph connects those identities to permissions, roles, applications, resources, owners, and activity so teams can analyze access relationships.
Does an identity graph show actual user activity?
Not by itself. An identity graph primarily shows identities and potential access relationships. When connected to activity data, it can help teams compare what an identity could access with what it actually used.
Can an identity graph include service accounts and AI agents?
Yes. Service accounts, workloads, OAuth applications, machine identities, API keys, and AI agents can be modeled with their permissions, owners, activity, and relationships to resources.
How does an identity graph support security investigations?
It helps investigators understand the potential blast radius of a compromised identity and identify the permissions and relationships that create access. Activity data is still needed to establish which resources were actually accessed.
Can an identity graph prove compliance?
No. It can strengthen access-review and audit evidence by explaining why access exists, but compliance also requires documented controls, complete data, approval records, accountable ownership, and evidence that changes were implemented.
What data is needed to build an identity graph?
Relevant sources may include identity providers, cloud IAM platforms, SaaS applications, HR systems, PAM and IGA tools, endpoints, ticketing systems, activity telemetry, and custom authorization stores. Coverage, normalization, identity resolution, and freshness determine how accurately the graph reflects the environment.
.png)
