Feb 22, 2026 · Shawki Aladdin · Access Control · 4 min read
Most engineering teams assume something that is not actually true. They believe they can restrict access to specific folders inside a repository. In practice, they cannot. On platforms like GitHub and GitLab, permissions are granted at the repository level. If a user can access the repository, they can see the entire directory tree. That works fine for small teams. It breaks down in monorepos.
Most engineering teams assume something that is not actually true.
They believe they can restrict access to specific folders inside a repository.
In practice, they cannot.
On platforms like GitHub and GitLab, permissions are granted at the repository level. If a user can access the repository, they can see the entire directory tree.
That works fine for small teams.
It breaks down in monorepos.
In a monorepo, folders often represent:
Separate products
Internal infrastructure
Sensitive algorithms
Compliance bound components
Future roadmap initiatives
But the permission model does not recognize folders as security boundaries.
It recognizes only the repository.
That means a contractor working on one feature can technically browse everything else.
Even if they never misuse it, the exposure exists.
And exposure is risk.
To avoid overexposure, many organizations split their monorepo into smaller repositories.
This creates:
CI duplication
Dependency fragmentation
Cross repo coordination complexity
Slower refactoring
You end up redesigning architecture to compensate for a permission limitation.
That is not sustainable.
The real issue is structural.
Git was designed around the repository as the smallest control unit.
Modern organizations, however, organize work by directories within a shared repository.
There is a mismatch between how code is structured and how access is controlled.
As companies scale, this mismatch grows into a governance gap.
Security frameworks emphasize least privilege.
People should only see what they need to do their job.
In many growing engineering organizations, that principle is quietly violated every day.
Not because teams are careless.
But because the tools were never built for directory level isolation.
If your monorepo is growing, the question is simple:
Are you scaling your architecture with control?
Or are you scaling your risk along with it?
The Monorepo Security Illusion Monorepos are often praised as the ultimate engineering accelerator. One repository.Shared libraries.Atomic commits.Cross-team refactoring. From a productivity standpoint, it makes sense. From a security …
Modern Code Governance Software development has scaled. Access control has not. Engineering teams today operate in monorepos, shared service architectures, and multi-team environments. Collaboration is faster than ever. …
Most engineering leaders worry about external threats. Very few worry about internal overexposure. Yet in many growing organizations, dozens or hundreds of developers have visibility into parts of the codebase they do not need to see. Not because of bad intent. Not because of poor discipline. But because of how repository permissions work. And that creates a silent cost.
Modern engineering teams love monorepos. One repository. Multiple services. Shared libraries. Unified CI. Faster collaboration. But there is a security problem hiding inside this convenience. When your organization scales beyond a small team, repository-level permissions stop being enough. And that is where most companies quietly lose control of their source code exposure.