Sort repositories into three tiers by what a bad change would cost. Let agents work freely in the low tier, allow them with extra controls in the middle tier, and keep the top tier human only until your controls have a track record. The sorting takes an afternoon and prevents most scope arguments.
Why tier at all
A blanket yes exposes your most sensitive code on day one. A blanket no pushes developers toward unapproved tools. Tiers give you a defensible middle path, and the same sorting helps with other controls such as review depth.
The three tiers
| Tier | Typical contents | Agent policy |
|---|---|---|
| Low | Internal tools, prototypes, documentation, test utilities | Allowed with standard controls |
| Middle | Customer facing services, shared libraries, infrastructure code | Allowed with code owner review, restricted permissions, and extra logging |
| High | Authentication, payments, cryptography, release signing, deployment pipelines | Human only at first, revisit after the middle tier is stable |
Questions that place a repository
- Does it hold or process sensitive data? Customer records, health data, financial data.
- Can a bad merge reach production without another gate? Deployment pipelines and release repositories score high here.
- Is it widely depended on? A shared library with many consumers multiplies any flaw. See the blast radius thinking in this post.
- Does it contain secrets or keys in the tree? If so, fix that before any agent sees it.
- Do you have owners? A repository with no code owners has nobody to review agent changes.
Score each yes as one point and place the repository: zero to one is low, two to three is middle, four or more is high. Adjust by judgment, but write down why.
Make it enforceable
A tier on a spreadsheet changes nothing. Apply it where tools can read it.
- Use a list of repositories the agent tools may open, and set it in the tool's managed configuration where one exists.
- Add CODEOWNERS to middle tier repositories. GitHub's documentation notes that owners need write access, that the file sits in the root, a docs folder, or the .github folder, and that you can require code owner review in branch protection.
- Protect the CODEOWNERS file itself. The same docs advise assigning an owner to it.
- Review the tiers quarterly, because repositories change purpose.
Common objections
"The top tier is where help would matter most." True, and also where mistakes cost most. Start with read only assistance such as explaining code, then consider write access once the process is proven.
"Developers will use their own accounts." Some will. Reduce the pull by giving a good approved path, and detect unapproved use through asset discovery and network review.
Safeguard offers asset discovery, policies, and SBOM and dependency scanning, which help you inventory repositories and their dependency exposure before you assign tiers.
Quick check
Can the tiers differ by team?
Yes, but keep the criteria the same so two teams with similar risk land in the same tier.
Does read only access to the top tier make sense?
Often, with caution. Reading still exposes code and any secrets in it, so the data handling answers still apply.
Sources
Last reviewed: 19 October 2026.
