Monorepo

Expanded Definition

A monorepo is a single source-of-truth repository that houses multiple applications, services, libraries, and shared infrastructure code. In NHI and agentic AI environments, the term matters because the same repository may contain application code, deployment logic, secret references, policy-as-code, and identity-related automation in one place. That concentration can improve consistency, but it also increases the blast radius of a mistaken commit, a weak branch control, or a scanner that cannot keep pace with repository size.

Definitions vary across vendors on whether a large repository must also share a common build system to qualify as a monorepo. For security teams, the practical distinction is less about tooling labels and more about whether one codebase governs many runtime identities, service accounts, and automation paths. When that is true, changes to access control, secret handling, and deployment pipelines must be reviewed as one operational system, not as isolated projects. Guidance from the NIST Cybersecurity Framework 2.0 applies here because integrity and change control become shared concerns across the whole repository.

The most common misapplication is treating each directory as an independent security boundary, which occurs when teams assume repo structure equals privilege separation.

Examples and Use Cases

Implementing monorepo governance rigorously often introduces heavier access review, build, and scan coordination, requiring organisations to weigh developer velocity against broader security assurance.

• A platform team stores service templates, Terraform, and policy modules in one repo so every environment inherits the same identity controls and secret-scanning rules.
• An AI engineering group keeps agent prompts, tool manifests, and deployment code together so changes to execution authority can be reviewed alongside the application logic.
• A security team uses repository-wide dependency and secret scanning because a single change may affect multiple services, CI jobs, and runtime identities at once, reinforcing lessons from the Ultimate Guide to NHIs.
• A fintech organisation maintains one repo for shared authentication libraries, but requires stricter merge approvals because a small code change can alter how many services mint or validate tokens.
• A compliance team maps all code owners to the NIST Cybersecurity Framework 2.0 so accountability is not diluted across dozens of service teams.

In monorepos, the key use case is centralising controls without assuming centralisation alone creates safety.

Why It Matters in NHI Security

Monorepos matter in NHI security because they often contain the code that creates, rotates, and uses machine identities. If repository controls are weak, secrets can be committed, permissions can drift, and privileged automation can spread across many services before anyone notices. NHIMG reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, including code and CI/CD tools, which makes large shared codebases especially sensitive when secret handling is inconsistent. The same risk pattern appears in service account governance: only 5.7% of organisations have full visibility into their service accounts, so a monorepo can become the place where blind spots are introduced or exposed. The Ultimate Guide to NHIs frames this as a lifecycle problem, not just a code hygiene problem.

For practitioners, the operational question is whether the repository makes it easy to enforce least privilege, secret hygiene, and change traceability across every automated workload. That aligns with broader guidance in the NIST Cybersecurity Framework 2.0, especially where governance and access control must scale with code volume. Organisations typically encounter the security cost of a monorepo only after a leaked credential, unintended privilege change, or broken pipeline affects many services at once, at which point monorepo governance becomes operationally unavoidable to address.