An identity trust graph is the network of relationships between users, applications, vendors, tokens, and delegated permissions that defines real access in a SaaS environment. It is more useful than a login-centric view because attackers exploit the links between identities, not just the identities themselves.
Expanded Definition
An identity trust graph is the practical map of how access is actually inherited, delegated, and reused across SaaS, cloud, and automation layers. It goes beyond a login-centric inventory by showing which users, service accounts, applications, tokens, vendor integrations, and delegated scopes can reach data or take action. In NHI governance, this matters because access often persists through relationships rather than direct authentication events.
Definitions vary across vendors, but the common thread is relationship visibility: who trusts whom, what permissions are transitive, and where standing access has accumulated. That makes the concept closely aligned with NIST Cybersecurity Framework 2.0 thinking around access control and asset understanding, even though no single standard governs this term yet. NHI Management Group treats the trust graph as an operational control plane for finding hidden privilege, not just a reporting artifact. The most common misapplication is treating the graph as a one-time diagram, which occurs when teams snapshot identities without tracking token scope changes, vendor delegation, or dormant connections.
Examples and Use Cases
Implementing an identity trust graph rigorously often introduces visibility and data-normalisation overhead, requiring organisations to weigh stronger access assurance against the effort of continuously reconciling identity relationships.
- A SaaS admin reviews all app-to-app OAuth grants to find where one integration can act on behalf of many users, then removes stale scopes after comparing them to the trust graph.
- A security team traces a compromised API key through linked tokens, CI/CD access, and delegated permissions to determine whether the original leak created broader lateral movement risk, as seen in the JetBrains GitHub plugin token exposure.
- Governance teams use Ultimate Guide to NHIs guidance to identify which service accounts still trust long-lived credentials and which ones should be rotated or revoked.
- A vendor risk review maps third-party access chains to reveal when an external tool can inherit access through nested application permissions, then scopes the minimum needed access before contract renewal.
- Incident responders compare the trust graph to logs from the target SaaS app and the NIST Cybersecurity Framework 2.0 access governance outcomes to confirm whether the blast radius reached beyond the initial identity.
Why It Matters in NHI Security
Identity trust graphs are critical because NHI compromise usually spreads through relationships, not passwords alone. When an organisation cannot see delegated trust, it cannot reliably answer which workloads, tokens, or vendors can still exercise privilege after a secret leak, misconfiguration, or offboarding event. NHI Management Group reports that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that a trust graph is meant to expose and reduce.
That visibility becomes especially important for SaaS ecosystems where one exposed token can cascade into multiple systems. It also supports the broader access governance posture described in Top 10 NHI Issues and helps operationalise least privilege after relationships are discovered, not assumed. The graph should be treated as a living control, continuously updated as permissions change and integrations proliferate.
Organisations typically encounter the full impact of an identity trust graph only after a breach review shows that a single compromised token could traverse several delegated relationships, at which point the concept becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Trust graph gaps expose excessive privilege and hidden NHI relationships. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must reflect approved, least-privilege relationships. |
| NIST Zero Trust (SP 800-207) | Policy Engine / Continuous Verification | Zero Trust depends on evaluating each access relationship before granting action. |
| NIST SP 800-63 | IAL/AAL guidance | Identity assurance matters when delegated access chains determine real privilege. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic systems expand trust graphs through tool access and delegated execution. |
Map every identity relationship and remove transitive access that is not explicitly required.
