Dependency graph

A dependency graph maps the systems, services, and workflows that rely on a non-human identity. It helps responders understand blast radius and operational impact before disabling an identity, which is critical when service accounts or tokens are embedded in production processes.

Expanded Definition

A dependency graph is the operational map of what a non-human identity touches: applications, APIs, databases, queues, pipelines, and downstream automations. In NHI governance, it is more than architecture documentation. It is the evidence used to judge whether disabling a service account, API key, or token will break revenue paths, data flows, or recovery jobs.

Definitions vary across vendors, but the practical meaning is consistent: a useful dependency graph captures both direct dependencies and hidden chains created by scripts, scheduled jobs, CI/CD runners, and autonomous NIST Cybersecurity Framework 2.0 control mappings. It should also show where secrets are stored, where they are replayed, and which systems inherit the identity’s privileges. That matters because many failures are not caused by the identity itself, but by the forgotten process that depends on it.

The most common misapplication is treating the graph as a static diagram, which occurs when teams do not update it after pipeline changes, credential rotation, or new agent integrations.

Examples and Use Cases

Implementing dependency graphs rigorously often introduces maintenance overhead, requiring organisations to weigh faster incident response against the cost of continuous discovery and review.

• A payment service account authenticates a checkout API, a fraud-scoring queue, and a nightly settlement job. The graph shows that revoking the identity without a cutover plan would halt both customer purchases and end-of-day reconciliation.
• An LiteLLM PyPI package breach style event illustrates why dependency mapping matters for software supply chains: if a build token is reused across projects, one exposed secret can create lateral impact far beyond the first package.
• An autonomous agent uses a model endpoint, a retrieval store, and a ticketing API. A dependency graph clarifies which tool calls are mandatory, which are optional, and which permissions can be reduced under Zero Trust design.
• A legacy ETL job depends on a long-lived database credential embedded in a config file. The graph helps responders see why rotating the secret without changing the job would cause a failed data load at the next scheduled run.
• Security teams align the graph with NIST Cybersecurity Framework 2.0 by identifying where access control, monitoring, and recovery planning overlap for each identity-linked workflow.

In practice, this is the difference between “turn it off and see what breaks” and a controlled, auditable remediation path. The LiteLLM PyPI package breach is a reminder that dependency awareness is not just an architecture preference, it is an incident-response requirement when secrets are reused across tooling.

Why It Matters in NHI Security

Dependency graphs are central to blast-radius analysis. Without them, an organisation may overcorrect by disabling an identity that still powers production workflows, or undercorrect by leaving compromised access active because no one can quickly prove what it supports. That is especially dangerous for service accounts embedded in CI/CD, data pipelines, and agentic systems where a single credential may unlock multiple business functions.

The scale of the problem is visible in NHIMG research: only 5.7% of organisations have full visibility into their service accounts, which means most teams are making revocation decisions with incomplete dependency data. That gap also weakens offboarding, secret rotation, and incident containment, even when organisations follow broader guidance such as NIST Cybersecurity Framework 2.0 and Zero Trust Architecture principles.

Dependency graphs also support prioritisation. They show which identities require PAM, where RBAC is too coarse, and where JIT access or ZSP can reduce standing exposure. They become even more important when a breach report arrives and responders need to determine whether a stolen secret reached other systems through an overlooked workflow. Organisations typically encounter the full operational cost of missing dependency data only after a failed rotation, at which point the dependency graph becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does a dependency compromise become an identity incident?
• What is the difference between a SaaS knowledge graph and a SIEM?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?