Source Hierarchy

Expanded Definition

Source hierarchy is the policy for deciding which record wins when the same topic exists in more than one place. In NHI and agentic AI environments, that often means resolving conflicts between a system prompt, a governed knowledge base, a runbook, a service catalog, and human-authored exceptions. A strong hierarchy makes answers reproducible, auditable, and safer to operationalise across IT, HR, finance, and service desk workflows.

Definitions vary across vendors on where the hierarchy should live and how deeply it should be enforced. Some implementations treat it as retrieval ranking, while others treat it as a governance rule that constrains what the model may cite or execute. NIST guidance on the NIST Cybersecurity Framework 2.0 reinforces the need for defined, trusted information sources, but no single standard governs source hierarchy yet. In practice, the hierarchy should prefer authoritative, current, and policy-approved sources, then log every override for traceability. The most common misapplication is allowing ad hoc documents or stale wiki pages to outrank governed records when content duplication exists.

Examples and Use Cases

Implementing source hierarchy rigorously often introduces latency and governance overhead, requiring organisations to weigh answer consistency against the cost of maintaining ranked, validated sources.

• A service desk assistant answers password reset questions from the official identity portal before consulting older help articles, reducing contradictory instructions.
• An HR agent uses the policy repository as the top source for leave entitlements, while a departmental FAQ is treated as secondary context only.
• A finance copilot resolves reimbursement rules from the approved expense policy, not from copied guidance in a team workspace.
• An NHI operations workflow prefers the controlled secrets inventory over a cached configuration file, helping prevent outdated credential guidance from driving remediation. The ASP.NET machine keys RCE attack is a reminder that stale or exposed material can become dangerous when treated as authoritative.
• A knowledge agent follows the published access review procedure first, then uses incident notes only to enrich context if the governed source is silent.

Why It Matters in NHI Security

Source hierarchy becomes a security control when conversational systems are allowed to recommend actions, retrieve secrets guidance, or trigger automated tasks. If the hierarchy is weak, a model may surface stale token rotation steps, ignore revocation requirements, or quote an outdated exception as if it were policy. That creates risk across NHI lifecycle operations, especially where service accounts, API keys, and certificates are already overexposed. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and that makes source ordering especially important when multiple documents disagree about where the truth lives.

The same issue appears in incident response. If a revoked credential is still described as active in one repository, operators may keep using it after compromise. A disciplined hierarchy also supports auditability because it shows which source was used, when it was last validated, and whether an override was justified. That trace is essential for governance under frameworks such as the NIST Cybersecurity Framework 2.0. Organisations typically encounter the consequences only after a bad answer, a duplicate policy, or a credential misuse incident reveals that no single source was actually authoritative.

Related resources from NHI Mgmt Group

• Why is DevOps such a significant source of NHI risk?
• Why is hardcoding credentials into source code so dangerous?
• What is the difference between source control leakage and SharePoint secret exposure?
• Why do secrets in source code create NHI governance problems?