Derived relations expose multi-hop context in knowledge graphs

At a glance

What this is: This is a product update about custom multi-hop derived relations in a knowledge graph, with the key finding that indirect asset relationships can now be surfaced directly on an asset page.

Why it matters: It matters because IAM, NHI, and data governance teams often make decisions on incomplete relationship data, and hidden dependencies can undermine access review, lineage, policy enforcement, and AI oversight.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Collibra's post on derived relations for knowledge graph context

Context

Knowledge graphs are only useful when the relationship model reflects how governance decisions are actually made. In practice, the risk is not the direct link you can already see, but the indirect dependency that determines lineage, policy impact, or control ownership several hops away.

Derived relations are Collibra's answer to that problem for data governance workflows. They let administrators define reusable multi-hop paths so an asset page can surface distant relationships without forcing users to click through every intermediate object.

That shift matters most where data governance, access governance, and AI oversight intersect. A hidden dependency between an asset, a policy, and a downstream AI use case can change how teams classify risk, assign accountability, and prove control coverage.

Key questions

Q: How should teams use multi-hop relationships in a knowledge graph for governance decisions?

A: Use multi-hop relationships to surface the dependencies that matter for lineage, policy scope, and accountability, not just to make diagrams richer. The useful test is whether the path changes a review, approval, or classification decision. If it does, model it as governed metadata and expose it on the asset page where the decision happens.

Q: Why do indirect relationships matter in data governance and access governance?

A: Indirect relationships often carry the real control impact because policies, ownership, and downstream dependencies are rarely one hop away. When teams only see direct links, they miss the context that determines compliance scope, remediation priority, and accountability. Multi-hop visibility closes that gap by making hidden dependencies decision-relevant.

Q: What should teams check before publishing derived relationships in a knowledge graph?

A: Check that the path has clear business meaning, a named owner, and a stable interpretation in both directions. If the relation can be read two different ways by reviewers, it will create governance confusion even if the graph logic is correct. Validation should focus on whether users would take the right operational action from the surfaced path.

Q: How can knowledge graphs help with AI governance and traceability?

A: They can expose the indirect links between AI use cases, data assets, policies, and approvals that are otherwise buried across several objects. That matters because AI oversight fails when reviewers cannot see which assets support a model, which policies apply, or where accountability sits. Graph-based traceability turns those hidden links into audit-ready context.

Technical breakdown

Multi-hop relation paths in a knowledge graph

Derived relations are configurable relationship paths that traverse more than one edge in a knowledge graph. Instead of storing only direct links, the platform can calculate a path from a head asset type to a tail asset type using a mix of direct and derived relations. The key architectural idea is that the relation is not manually copied into every object. It is computed from the path definition, which makes the resulting connection reusable across asset pages and widgets. This is useful where lineage, policy scope, or dependency mapping spans several intermediate assets.

Practical implication: model the path once, then expose it on the asset types where governance decisions depend on that indirect relationship.

Head, tail, role, and co-role define the path semantics

A derived relation type starts with a head asset type and a tail asset type, then assigns role and co-role names for navigation in both directions. Those labels matter because they determine how users interpret the relationship when they move from source to target and back again. The path can also fork and rejoin, as long as every sub-path ends at the correct tail asset type. That makes the construct flexible enough for non-linear lineage patterns without turning the graph into a set of one-off exceptions.

Practical implication: define relation semantics deliberately, or governance users will see technically correct paths that do not mean what they expect.

Asset-page widgets turn graph logic into usable context

Once a derived relation type or derived attribute type is assigned to an asset type, the platform adds a widget to the asset page and queries the graph at view time. That means the relationship is resolved dynamically for the current asset, rather than hard-coded into a separate report or diagram. This design matters because it moves from static documentation to interactive context delivery. For governance teams, the real value is not the graph itself but the ability to expose the right dependency at the point where a user is evaluating an asset.

Practical implication: place derived relations on the asset types that drive review, certification, and policy decisions, not just on catalog objects used for reference.

NHI Mgmt Group analysis

Derived relations solve a visibility problem, not a lineage problem. Traditional direct lineage already captures obvious dependencies, but governance decisions often hinge on indirect relationships that sit several hops away. That is why this feature matters to data governance and access governance alike: the missing context is usually not absent data, but unmodelled dependency depth. Practitioners should treat multi-hop relationship design as a governance control surface, not a convenience feature.

Relationship visibility without semantic discipline creates false confidence. If the head, tail, role, and co-role model is loose, users may see a path that is technically valid but operationally misleading. The practical risk is misclassification of policy scope, ownership, or downstream impact because the graph is surfacing connection, not interpretation. Teams should assume that every derived relation becomes a governance statement the business may act on.

AI governance increases the value of hidden-path discovery. AI use cases often depend on assets that are separated from policy, training data, or approval artifacts by multiple object hops. When those links stay buried, oversight becomes partial and accountability becomes hard to prove. The implication for practitioners is that knowledge graph design must support AI traceability as part of broader data and identity governance, not as a separate reporting exercise.

Multi-hop context should be governed like a control, not just rendered like a view. A derived relation widget can make buried dependencies easy to see, but visibility alone does not guarantee correct entitlement, policy, or lifecycle decisions. The field should be thinking about relationship definitions as governed objects with ownership, review, and change control. Practitioners should treat derived relations as part of their operating model, not a presentation layer add-on.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• Derived relationship visibility should be read alongside Ultimate Guide to NHIs , 2025 Outlook and Predictions, which frames where identity and governance programmes are headed next.

What this signals

Derived relations point to a wider governance shift: organisations are moving from cataloguing objects to governing relationships. That matters because the decisions that break control assurance often sit in the gaps between direct assets, not on the assets themselves. For teams managing NHI, IAM, or AI oversight, the next maturity step is to treat hidden dependencies as first-class governance data.

Relationship depth is becoming operationally relevant to identity security. If a policy, approval, or ownership record sits several hops away from the asset being reviewed, the control may exist in theory but not in practice. Practitioners should expect more pressure to prove relationship context at the point of access review, certification, and audit.

With only 5.7% of organisations having full visibility into their service accounts, according to the Ultimate Guide to NHIs, the lesson is not just about machine identity. It is also about how incomplete relationship models distort the evidence base for access governance, lifecycle management, and AI traceability.

For practitioners

• Define governance-critical multi-hop paths explicitly Map the indirect relationships that drive policy scope, ownership, lineage, and downstream impact, then create derived relation types for those paths instead of relying on ad hoc navigation.
• Assign relation semantics with business meaning Review head asset type, tail asset type, role, and co-role with the governance owner before publishing the path so the relation reads correctly in both directions.
• Add derived relations to the asset types used in review workflows Place the widget on the objects that reviewers, analysts, and approvers actually inspect, so the indirect dependency appears where decisions are made.
• Treat derived relations as governed metadata Document ownership, change approval, and periodic validation for each path so hidden relationships do not drift into misleading control evidence.

Key takeaways

• Derived relations make indirect dependencies visible, which is essential when governance decisions depend on context several hops away.
• The main risk is not missing connectivity but misreading connectivity, so relation semantics need ownership and review.
• Teams should treat graph-based relationship definitions as governed metadata that supports lineage, policy scope, and AI traceability.

Key terms

• Derived Relation: A derived relation is a computed relationship in a knowledge graph that connects two assets through one or more intermediate hops. It is defined by a path, not by a single stored edge, so the resulting connection can be reused and displayed wherever the governed asset appears.
• Head Asset Type: The head asset type is the starting object class for a derived relation path. It tells the platform where the relationship begins, which matters because governance context is often anchored in the source asset before the system walks toward the target asset.
• Tail Asset Type: The tail asset type is the destination object class in a derived relation path. It determines what kind of asset should be surfaced at the end of the multi-hop journey, helping the graph expose the context that users need for lineage, compliance, or accountability decisions.
• Co-Role: A co-role is the reverse-facing name for a relation when you traverse a path from tail to head. It gives the relationship a meaningful label in both directions, which is important when users inspect lineage or governance context from either side of the graph.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Collibra: Connecting the dots on how derived relations unlock complex connections in your knowledge graph. Read the original.