What is the difference between a package inventory and an agent dependency graph?

How a package inventory differs from an agent dependency graph

A package inventory is a catalogue of the software components an agent uses. It is useful for patching, license tracking, and knowing what is installed. An agent dependency graph goes further, showing how packages, tools, models, credentials, and services connect at runtime, so you can see transitive trust, privilege, and failure paths.

That difference matters because the security question is not only “what is present?” but “what can this agent reach, and through what chain of dependencies?” A flat inventory can tell you a vulnerable package exists; a graph helps you understand whether a compromised component could alter an agent’s behaviour, expand access, or affect downstream services.

In practice, the graph is the better representation when runtime behaviour depends on dynamic tool calls, delegated tokens, external APIs, or model routing. A package list is still necessary, but it does not express the relationships that determine blast radius. That is why SBOM guide material is useful for component visibility, while a dependency graph is the better fit for operational trust analysis.

Why runtime relationships change the security answer

The two artefacts answer different questions. Inventory supports hygiene, such as change tracking and component review. A dependency graph supports risk analysis, because it reveals whether one package, service, or token sits on a critical path to production behaviour. If the chain is broken, altered, or hijacked, the agent may fail closed, fail open, or silently change what it can do.

A graph also captures transitive exposure that a package list hides. For example, a benign-looking library can sit behind a tool wrapper, which uses a service account, which has access to a data store or external API. The security relevance is not the library alone, but the runtime path that gives it influence. That is the difference between knowing the parts and understanding the trust boundary.

This is why supply chain and dependency visibility are central to agent security. A single compromised dependency may not need direct interactive access if it can influence tool selection, credential use, or service calls through the agent’s normal execution chain.

What each view helps you do operationally

Use a package inventory when the task is component management: patch prioritisation, version drift, software licensing, and basic exposure review. Use an agent dependency graph when the task is security architecture, incident scoping, or blast-radius assessment. The graph is also the better source of truth when multiple tools or services are chained together and ownership is distributed across teams.

The two views complement each other, but they are not interchangeable. An inventory can be complete while still missing the key security relationship, because it does not show delegation, runtime invocation, or cross-system trust. A graph can be complete for exposure analysis while still needing the underlying inventory for versioning and remediation planning.

For agentic systems, this distinction becomes sharper when credentials or external services are part of the path. The runtime map is what tells you whether a dependency is merely installed or actually capable of influencing action, access, or output.

Risk and Threat Considerations

The main risk is false confidence. Teams often think a clean inventory means the agent is controlled, but the real exposure sits in the connected runtime path, where a compromised package, tool, or service can change behaviour or reach resources the inventory alone does not reveal.

Failure mechanism: A dependency graph is missing, stale, or too shallow, so transitive trust, delegated access, and downstream service reach are not visible during review or incident response.

Impact: Compromise can spread through hidden runtime paths, causing unauthorised actions, altered outputs, broader access than intended, or delayed containment because responders cannot quickly see what the agent actually depended on.

Practitioner Guidance

What to verify: Treat the inventory as a baseline and verify that the graph includes runtime edges for tools, services, model calls, and any credential path that changes what the agent can do. If an element affects access or behaviour at execution time, it belongs in the graph even if it is not a package.

Decision rule: Use the inventory for patch and license workflows, but use the dependency graph for security decisions, incident scoping, and change approval. If a control decision depends on transitive trust, the graph is the authoritative artefact.

Practitioner takeaway: The inventory tells you what exists; the dependency graph tells you what can actually influence the agent, and that is the difference that matters when you are assessing trust, blast radius, and containment.

Related resources from NHI Mgmt Group

• When does AI agent discovery become more than an inventory problem?
• What do organisations get wrong about AI agent inventory and visibility?
• What should auditors expect in an AI agent evidence package?
• What do teams get wrong about dependency provenance and package trust?