SaaS knowledge graphs are becoming core to NHI governance

At a glance

What this is: This is an analysis of why a purpose-built SaaS knowledge graph is needed to connect fragmented identity signals and expose NHI and AI-agent access paths.

Why it matters: It matters because IAM and NHI controls fail when they cannot trace how users, tokens, integrations, and AI agents combine into effective access.

By the numbers:

• SaaS risk gets harder to govern when 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Obsidian Security's analysis of SaaS knowledge graphs and secure automation

Context

SaaS sprawl becomes an identity governance problem when access no longer lives in one directory, one tenant, or one entitlement model. The article argues that teams need a relationship-aware data architecture because NHI and AI-agent access paths now cross apps, integrations, and delegated credentials in ways conventional tables and point-in-time views cannot explain.

A knowledge graph is the article's answer to that problem: it models users, accounts, tokens, permissions, and resources as linked entities so teams can trace who owns what, how access was granted, and how risk moves. That framing is consistent with the broader NHI lifecycle problem space in the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide.

Key questions

Q: How should security teams govern SaaS access when identities span many apps?

A: Security teams should govern SaaS access as a relationship problem, not a list problem. The practical approach is to map users, tokens, integrations, roles, and resources into one entitlement model, then use that model for reviews, offboarding, and exception handling. Without that connective tissue, teams will miss inherited privileges and downstream exposure.

Q: Why do AI agents complicate IAM and NHI governance?

A: AI agents complicate IAM and NHI governance because they act through delegated credentials and app integrations rather than through a single human session. Their access can expand through chained permissions, reused tokens, and cross-application workflows. That makes ownership, scope, and expiry controls essential before automation scales.

Q: What is the difference between a SaaS knowledge graph and a SIEM?

A: A SaaS knowledge graph models relationships and current access state, while a SIEM models events and alerts. The graph helps explain who can reach what and why, which is critical for entitlement governance. The SIEM still matters for detection, but it cannot by itself maintain the living access structure SaaS now requires.

Q: When should organisations treat an integration as a privileged identity?

A: Organisations should treat an integration as a privileged identity whenever it can access sensitive data, impersonate users, or move across tenants and apps. If the integration has broad scopes, long-lived tokens, or no clear owner, it belongs in privileged review. The same is true for AI workflows that inherit those capabilities.

Technical breakdown

Why SaaS access paths require a relationship graph

SaaS environments create many-to-many identity relationships that do not map cleanly to row-based reporting. A single person can have multiple app accounts, inherited roles, delegated tokens, and third-party integrations, each with different scopes and lifecycles. A knowledge graph preserves those links as first-class relationships, which means security teams can ask cross-system questions such as who owns a token, which role granted access, and where that access now reaches. That matters because the real risk is not the record itself but the path connecting identities to resources. In NHI terms, the graph becomes the control surface for understanding exposure, not just inventory.

Practical implication: Model identity relationships explicitly so access reviews can follow inheritance, delegation, and downstream exposure without manual correlation.

How multi-hop exposure spreads through integrations and AI agents

Multi-hop visibility is the ability to trace access through several relationship steps, such as user to integration to token to external system. This is critical in SaaS because compromise often rides on delegated access rather than direct logins. When an AI agent or integration inherits broad scopes, the graph can show how a dormant account, an over-permissioned OAuth client, or a reused token expands the blast radius across apps. That is a governance problem, not just a detection problem. The security value comes from being able to reason over chained permissions before an attacker does.

Practical implication: Map transitive access paths so you can limit how far one compromised identity or token can move through the environment.

Why traditional SIEM and cloud graphs miss SaaS identity drift

SIEMs are event-centric and cloud posture tools are infrastructure-centric, so neither naturally models the state of SaaS entitlements over time. SaaS risk often appears as drift, meaning permissions, scopes, and ownership change quietly without a clean incident trail. A purpose-built graph can version those changes, compare current state to prior state, and expose when access outgrows its original approval. For NHI governance, that is the difference between collecting evidence and understanding entitlement behavior. The architecture is designed to explain how privilege accumulates, not just when an event fires.

Practical implication: Use a stateful model to detect entitlement drift, then tie each change back to an owner and a remediation path.

Threat narrative

Attacker objective: The attacker wants to expand a single trusted access path into broad cross-SaaS reach without triggering obvious authentication alarms.

1. Entry occurs when a third-party integration or AI workflow inherits delegated SaaS credentials with more scope than intended.
2. Escalation follows when those credentials are chained across app relationships, allowing access to additional tenants, repos, or data stores.
3. Impact is unauthorized access or data movement through a web of trusted integrations that ordinary event logs do not fully explain.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Purpose-built SaaS graphing is now an identity governance requirement, not an analytics luxury. Security teams cannot govern what they cannot model, and SaaS has outgrown directory-centric assumptions. The article is right to treat users, integrations, tokens, and permissions as a connected system rather than a pile of records. That is the only way to make NHI governance operational at enterprise scale.

Identity blast radius is the right concept for SaaS and agentic environments. The article shows that access risk is not confined to one account or one misconfiguration. It propagates through inherited roles, delegated tokens, and third-party links, especially when AI agents can chain actions across tools. Practitioners should evaluate every identity control by how far it can limit that blast radius.

Static inventory will not keep pace with SaaS entitlement drift. The important question is no longer whether a team can enumerate accounts, but whether it can continuously explain why access exists and how it changed. That shifts the control objective toward relationship-aware lifecycle management, with offboarding, rotation, and review tied to live graph state. Teams that keep treating SaaS access as a snapshot will miss the risk that accumulates between reviews.

AI agent governance belongs inside the same entitlement model as human and non-human access. The article correctly places AI agents alongside users and integrations because their risk emerges from delegated permissions, not from their interface. That means organisations should stop building parallel governance for automation and instead fold it into the same NHI control plane. The practitioner takeaway is simple: one access model, not separate ones for humans, bots, and agents.

A knowledge graph only matters if it drives control decisions. Security teams do not need another visualisation layer. They need a living model that can prioritize orphaned accounts, surface toxic permission combinations, and tell response teams what changed before a breach spreads. The field is moving toward explainable automation, and practitioners should insist that graph outputs connect directly to remediation and policy enforcement.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why entitlement drift persists across SaaS estates.
• For a broader control baseline, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that pair well with graph-based governance.

What this signals

Identity graphing should now be treated as a control dependency for SaaS security programmes. If access state cannot be joined across apps, then reviews, detections, and remediation remain partial. The programme-level response is to align IAM, NHI, and security operations around a shared entitlement source of truth, with each change recorded as a lifecycle event rather than an isolated ticket.

The next governance step is to connect graph insights to policy enforcement. That means using relationship data to drive revocation, scope reduction, and conditional approval, especially where third-party integrations or AI agents have inherited broad access. Teams should expect auditors to ask not only who had access, but how the organisation proved that access was still appropriate.

For practitioners

• Implement relationship-based access reviews Review users, tokens, roles, and integrations as connected paths rather than isolated assets. Prioritise accounts with inherited privileges, cross-tenant links, and dormant ownership so reviews answer who can reach what now, not only who was approved last quarter.
• Inventory AI agents with the same controls as other NHIs Classify AI agents, OAuth clients, and automation workflows as non-human identities with owners, scopes, and expiry expectations. Tie each one to an accountable service owner and require the same approval, review, and offboarding process used for other privileged access.
• Map multi-hop exposure paths across SaaS apps Trace user to integration to token to downstream system relationships so you can see where one compromise could spread. Use those paths to set tighter limits on delegated scopes, especially where third-party integrations can act across multiple tenants.
• Treat entitlement drift as a lifecycle problem Version access state over time and compare it against expected ownership, role, and usage patterns. When access changes without a matching business reason, trigger review, revocation, or re-certification instead of waiting for the next scheduled audit.

Key takeaways

• SaaS identity risk is fundamentally relational, so controls that cannot trace links between users, tokens, integrations, and resources will miss the real blast radius.
• The scale problem is already visible in NHI data, with most organisations still storing secrets outside secure managers and few able to fully see their service accounts.
• Practitioners should operationalise graph-based governance by tying entitlement drift, AI agent access, and offboarding to one living control model.

Key terms

• Knowledge Graph: A knowledge graph is a data model that stores entities and the relationships between them instead of treating records as isolated rows. In security, it helps teams explain how identities, permissions, tokens, and resources connect, which is essential for understanding access paths and risk propagation across SaaS and NHI environments.
• Multi-hop Visibility: Multi-hop visibility is the ability to trace access through several connected relationships, such as identity to integration to token to downstream system. It matters because SaaS and agentic workflows often create indirect privilege paths that are easy to miss in event-only logging or app-by-app reviews.
• Entitlement Drift: Entitlement drift is the gradual change in access rights, scopes, ownership, or settings over time without a clear governance trigger. In NHI and SaaS environments, drift often appears when integrations expand, teams reorganize, or automation inherits access that was never revalidated.

Deepen your knowledge

SaaS knowledge graphs and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a relationship-aware access model for similar SaaS sprawl, it is worth exploring.

This post draws on content published by Obsidian Security: From SaaS Sprawl to a Knowledge Graph Turning fragmented identity signals into a foundation for secure automation. Read the original.