When repositories merge, access tends to be the union of every team that had it. Each team gets write access to code that is not theirs. Decide access from ownership instead: grant the narrowest role, use CODEOWNERS and required reviews to control who approves what, and review the list after the move.
Why permissions spread
GitHub grants access to a repository, not a folder. Its documentation describes organization repository roles from Read through Triage, Write, Maintain and Admin. Write is described as for contributors who actively push to the project. Once a team has Write on the monorepo, it can push a branch that changes any directory.
The same documentation set for secure use of Actions notes that any user with write access to a repository has read access to all secrets configured in that repository. So a payments secret stored at repository level is readable by people who only ever worked on the marketing site.
A simple access map
- List every team and its old repositories.
- For each team, write down the directories it owns in the monorepo.
- Give each team Write only if it opens branches and pushes directly. Others can use Triage or Read and contribute from forks, if your policy allows it.
- Keep Maintain and Admin small. Admin can change settings, rules and secrets.
- Record the result in a table the team leads sign off on.
| Role | Fits | Watch for |
|---|---|---|
| Read | Auditors, adjacent teams | Can see all code and history |
| Triage | Support, product | No push access |
| Write | Engineers on owning teams | Reads all repo secrets |
| Maintain | Team leads | Manages repo, not destructive actions |
| Admin | Platform owners | Security and deletion settings |
Use review rules to narrow the effect
You cannot hide directories, but you can control approvals. The CODEOWNERS documentation says code owners must have write permissions, and teams must have explicit write access. With "Require review from Code Owners" enabled, a pull request that changes owned code needs approval from an owner. That turns broad write access into narrow merge authority. The protected branches documentation also describes requiring that the most recent reviewable push be approved by someone other than the person who pushed it.
Remember the limits. Review rules do not stop a person with Write from reading secrets or from changing workflow files unless those files are owned too. See CODEOWNERS for workflows and release files.
When to keep a repo separate
If a directory needs a smaller audience, such as code under a contract or unusually sensitive logic, a separate repository is the cleaner control. Sparse checkout is a convenience, not access control, which we explain in sparse checkout is not access control. The tradeoffs are covered in monorepo or separate repos: a security decision guide.
Review after 30 days
Access drifts. Schedule a review a month after the move and compare who has Write against who actually pushed. Safeguard's compliance and evidence automation can help you keep a record of those reviews for audits.
Quick check
Can I give a team access to one folder only?
Not through repository roles. Access is per repository. Use code owner review to control approvals, or a separate repo for restricted code.
Do CODEOWNERS entries grant access?
No. Owners must already have write permission, otherwise they are not assigned.
Sources
- GitHub Docs: Repository roles for an organization
- GitHub Docs: About code owners
- GitHub Docs: Secure use reference
- GitHub Docs: About protected branches
Last reviewed: 19 October 2026.
