An unmanaged path is a repository path containing infrastructure code that is not yet covered by the platform’s governance model. These paths matter because they create blind spots in inventory, policy enforcement, and drift detection. Discovering them early allows teams to bring all infrastructure code under consistent oversight.
Expanded Definition
An unmanaged path is not simply an unreviewed folder. In NHI and infrastructure governance, it is a code location where infrastructure-as-code, deployment logic, or identity-adjacent configuration exists outside the platform’s control plane, inventory, and policy lifecycle. That means controls such as approval gates, drift detection, secret scanning, and ownership metadata may not apply consistently.
Definitions vary across vendors because some teams use the term for any uncatalogued repository path, while others reserve it for paths that can deploy or modify cloud resources. NHI Management Group treats the term narrowly: if a path can introduce or alter privileged infrastructure state without being enrolled in governance, it is unmanaged. This aligns with the broader risk emphasis in the NIST Cybersecurity Framework 2.0, which expects organisations to know, govern, and monitor critical assets across their lifecycle.
The most common misapplication is labeling a repository as managed because it exists in version control, when the actual deployment path, subdirectory, or pipeline entry point is still excluded from policy enforcement.
Examples and Use Cases
Implementing unmanaged-path discovery rigorously often introduces tooling and review overhead, requiring organisations to weigh faster code delivery against stronger oversight and reduced blind spots.
- A platform team inherits a NHI Lifecycle Management Guide style process, but a new Terraform subdirectory is added outside the registered workspace and never gets scanned.
- A CI/CD pipeline references an older infrastructure path that still provisions service accounts, even though the main repository has been onboarded to governance.
- An engineering group creates a temporary module for emergency remediation, and the path remains active long after the incident closes, bypassing drift reviews.
- A security team maps high-risk code locations to findings in Top 10 NHI Issues and then validates whether the affected path is enrolled in ownership, approval, and secret detection controls.
- Infrastructure code for a third-party integration is stored in a nested path that is not included in the organisation’s policy-as-code ruleset, so privileged changes pass unnoticed.
For implementation standards, teams often compare path onboarding requirements with NIST Cybersecurity Framework 2.0 functions for asset governance and continuous monitoring, then decide which paths must be auto-discovered versus manually approved.
Why It Matters in NHI Security
Unmanaged paths become dangerous because infrastructure code frequently carries NHI material such as API keys, CI tokens, service account references, and deployment privileges. When these paths are invisible to governance, teams lose the ability to prove where secrets live, who can modify them, and whether a change was reviewed before execution. That gap is directly relevant to the risk patterns documented in the Ultimate Guide to NHIs, where weak visibility and secret exposure remain common failure modes. NHIMG reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes undiscovered paths especially hazardous.
From a governance standpoint, unmanaged paths undermine inventory completeness, policy coverage, and incident response. A team may believe secrets scanning is in place while entire deployment branches remain excluded, allowing drift to accumulate and high-risk changes to evade review. Organisations typically encounter the consequence only after an unexpected production change, leaked secret, or failed audit reveals that the path was never brought under control, at which point the unmanaged path becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unmanaged paths create identity and asset blind spots that NHI inventory controls are meant to close. |
| NIST CSF 2.0 | ID.AM-01 | Asset management requires knowledge of repositories and paths that affect governed infrastructure. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust depends on continuous policy enforcement across all execution paths, including code paths. |
| NIST AI RMF | Risk management requires identifying hidden system components that may affect trust and control. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems inherit risk when their tool or code paths bypass governance and oversight. |
Discover every code path that can affect NHI state and enroll it in inventory, ownership, and review controls.
