Security teams should define clear inclusion and exclusion rules for repository paths, then align them with change control, testing, and ownership boundaries. The goal is to automate stack creation without pulling in experimental, deprecated, or unrelated code. That keeps approvals accurate, reduces noisy drift, and helps teams preserve governance while still benefiting from continuous discovery.
Why This Matters for Security Teams
Auto-discovery is useful only when it reliably maps the right code to the right operational boundary. In GitOps workflows, that boundary is easy to blur: a new folder, test harness, or copied service can look like production-ready infrastructure and trigger an unnecessary stack. The result is governance noise, wasted approvals, and drift between what teams think is managed and what actually is.
The risk is not just inefficiency. Unnecessary stacks expand identity scope, increase policy exceptions, and create more places for secrets, permissions, and deployment hooks to accumulate. NHI management becomes harder when discovery rules are too broad, because every extra stack may inherit automation, credentials, and blast radius it does not need. NHI Lifecycle Management Guide and Top 10 NHI Issues both reflect the same operational pattern: over-discovery usually shows up as an identity and control problem before it looks like a tooling problem.
Security teams should treat discovery as a governed intake process, not a blind crawl. NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that configuration management and access control depend on defined scope, ownership, and change authorization, which is exactly what auto-discovery must respect. In practice, many security teams discover scope creep only after a stray path has already generated a live stack and inherited production-grade permissions.
How It Works in Practice
Preventing unnecessary stacks starts with precise repository scoping. Auto-discovery should be constrained by inclusion rules for approved application paths and exclusion rules for experimental branches, archived code, shared libraries, and generated artifacts. That sounds simple, but the control plane needs the same rigor as a deployment pipeline: path rules, ownership metadata, and environment labels should all be evaluated together before a stack is created.
Current guidance suggests treating stack creation as a policy decision, not a file-system event. A strong pattern is to require explicit signals such as a manifest file, an ownership declaration, and a change request that match the intended environment. For teams using GitOps at scale, policy-as-code can enforce these checks before provisioning begins, while change control verifies that the repository path belongs to a known service boundary. This is especially important when infrastructure definitions are reused across multiple repos, because duplication often causes discovery engines to spawn redundant stacks from templates.
- Allow only approved paths, and deny discovery in test, sandbox, and deprecated directories by default.
- Require ownership metadata so every discovered stack maps to a named team and an accountable service.
- Gate stack creation on deployment intent, not just the presence of IaC files.
- Log rejected discoveries so reviewers can tune rules without weakening guardrails.
- Review exception paths on a fixed schedule so temporary allowances do not become permanent.
These controls align well with the NHI Lifecycle Management Guide, because lifecycle governance depends on knowing what should exist before anything is provisioned, and the CI/CD pipeline exploitation case study shows why pipeline scope must be deliberate rather than implicit. NIST SP 800-53 Rev 5 Security and Privacy Controls also supports this approach through configuration management, least privilege, and change authorization expectations. These controls tend to break down when monorepos mix production and experimental code in the same tree because discovery cannot reliably infer intent from path names alone.
Common Variations and Edge Cases
Tighter discovery controls often increase operational overhead, requiring organisations to balance faster automation against more review and maintenance work. That tradeoff becomes sharper in monorepos, shared modules, and platform teams that manage many services from one codebase. There is no universal standard for this yet, but current guidance suggests that the best rule set is the one that is explicit enough to prevent accidental provisioning without forcing teams back into manual stack creation.
Edge cases usually appear when repository structure does not match service boundaries. For example, one directory may contain code for multiple environments, or a single repo may host both production stacks and one-off migration assets. In those environments, path-based discovery alone is too coarse, so teams should layer in ownership files, environment tags, and approval workflow checks. The Ultimate Guide to NHIs — Key Challenges and Risks and the Emerald Whale breach both underscore the same lesson: automation that is broader than governance quickly turns into an access and sprawl problem.
One useful operating model is to give platform teams authority over discovery rules, while application owners approve the boundaries those rules cover. That separation reduces accidental stack creation without creating a bottleneck for every commit. The right answer is not to stop auto-discovery, but to make it strict enough that only clearly owned, clearly intended infrastructure becomes a live stack.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 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 | Scope control prevents discovery from creating unintended non-human identities. |
| OWASP Agentic AI Top 10 | AGENT-03 | Autonomous tooling needs constrained execution and approval boundaries. |
| CSA MAESTRO | GOV-02 | Governance controls should separate intent from automated provisioning actions. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits who and what can trigger stack creation. |
| NIST AI RMF | AI risk governance applies when automation decides what infrastructure to materialize. |
Restrict discovery permissions and validate that new stacks stay within approved access scope.
Related resources from NHI Mgmt Group
- How should security teams implement manager approval workflows for infrastructure access without creating bottlenecks?
- How should security teams add governance to existing Infrastructure as Code pipelines without disrupting delivery workflows?
- How should teams implement automatic discovery for new Terraform code in GitOps workflows?
- How should security teams prevent duplicate Terraform resource definitions from breaking infrastructure changes at scale?
