On day one a new developer needs a managed identity with MFA, membership in one team, Write access to that team's repositories, and a development environment. Production, admin roles, billing and secrets stores wait for a named request and an approver. Start narrow, because widening access is easy and clawing it back is not.
Why day one is the right time to be strict
Most access creep starts at onboarding. A manager says "give them what the last hire had", and the new person inherits years of accumulated permissions. Copying a colleague is the fastest way to grant rights nobody ever decided on.
A better habit is to define access by role, not by person. The role is written down once, reviewed once, and applied the same way every time.
A starter access set for an application developer
| Area | Day one | Later, on request |
|---|---|---|
| Identity | Single sign-on account, MFA enrolled | Group changes via ticket |
| Source control | Team membership, Write on team repos | Maintain or Admin on a named repo |
| Cloud | Dev or sandbox account through federated login | Staging read, production read only after onboarding |
| CI/CD | Can run pipelines, cannot edit secrets | Pipeline admin for platform roles |
| Secrets | None directly | Scoped access to one vault path |
| Data | Synthetic or masked data | Real data only with a documented need |
GitHub's own role ladder is a useful reference. Its documented repository roles run from Read through Triage, Write, Maintain and Admin, and Admin includes sensitive and destructive actions such as managing security settings and deleting the repository. A new developer who writes code needs Write. Almost nobody needs Admin on day one.
Steps to set it up
- Write the role definition. List the groups, repos and environments a developer on this team receives. Keep it to a page.
- Provision through your identity provider, not by hand in each tool. One group should drive many permissions.
- Use temporary credentials for cloud access. AWS documentation recommends that human users reach accounts through federation with an identity provider and temporary credentials, rather than long term keys.
- Enrol MFA before anything else is granted. Phishing resistant methods such as passkeys or security keys are the stronger choice.
- Name an approver for each higher tier. Make requests carry a reason and an end date.
- Record who approved what and when. This is the evidence an auditor will ask for later.
What to hold back, and why
Production write access is the big one. A developer who has not yet seen how your deploys, rollbacks and alerts work is not safer for having the keys. Read only access to logs is a good middle step.
Hold back shared secrets too. If someone needs a token to do their job, issue one scoped to that job, named for the person or service, with an expiry. Shared tokens cannot be attributed and are painful to rotate when someone leaves.
Review at 30 days
Put a calendar item on the manager for 30 days after the start date. Ask three questions. What access was requested beyond the baseline? Is it still needed? Did anything go unused? Cloud providers expose last used data for credentials, which makes this review quick.
Quick check
Should a new developer get Admin on their team's repository?
Usually no. Write covers pushing code and opening pull requests. Admin includes security settings and deletion, so grant it only to the person who owns the repository.
Can we copy access from a similar colleague?
It is quicker but risky, because it copies every past exception. Use a written role definition and add exceptions by approved request.
Who should approve production access?
The service owner or an engineering manager who is not the requester. Record the reason and an end date.
Safeguard can help here by discovering assets and credentials in use and by enforcing policies and gates on pull requests, so a new developer's first changes meet the same rules as everyone else's. You can try a free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Repository roles for an organization
- AWS IAM User Guide: Security best practices in IAM
Last reviewed: 19 October 2026.
