No single account should be able to write a change, approve it, build it and deploy it. Split those duties across roles and enforce them with the pipeline, not with trust. Google's release engineering guidance puts access controls on approving changes, creating releases, deploying them and changing build configuration.
What to control
Google's site reliability book describes policy enforcement in release engineering. It lists the sensitive operations that sit behind access controls: approving code changes, creating and deploying releases, approving cherry picks, and changing build configurations. It adds that nearly all changes require code review, and that each release produces a report of what it includes.
Take that list and map it to your own setup.
A role map
- Propose a change: any engineer.
- Approve a change: a reviewer who is not the author.
- Merge to main: the pipeline, after checks pass.
- Change build or pipeline configuration: a small owner group, with review.
- Trigger a production release: the pipeline, or a named release role.
- Approve a hotfix outside the normal path: an on call lead, logged.
- Change production secrets: a small group, never through the pipeline logs.
Adjust to your size. A five person team may have everyone in several roles, but the author of a change should still not be its only approver.
Controls that do the work
Branch protection. Require pull requests, required checks and an approval from someone other than the last person to push. GitHub supports all of these, and lets you extend them to administrators.
Pipeline definitions under review. If anyone can edit the pipeline file in a feature branch and run it with production credentials, the review on application code is meaningless. Protect pipeline and build configuration with owners.
Scoped deployment credentials. The pipeline holds the right to deploy. People do not. Give each environment its own credentials with minimal rights.
Environment approvals. For production, require a manual approval step or a protected environment for high risk services.
Break glass. Provide an emergency path, since emergencies happen. Make it a named role, time limited, and logged, with a review afterwards.
Common gaps
- Admin accounts exempt from branch rules.
- Shared deploy tokens in many hands.
- Service accounts with permanent, wide rights.
- Hotfix paths that skip review and are used for convenience.
- No record of who released what.
Evidence for later
Good controls leave records. Keep the release report, the approvals, and the pipeline logs. They are useful in incident review and in answering customer or auditor questions. Whether a particular framework asks for this level of separation is something to check in that framework's text.
Review quarterly
List who holds each permission. Remove what is unused. Ask of each person: if this account were stolen today, what could the attacker ship?
Safeguard policies, gates and guardrails can enforce checks on changes before release, and agent identity helps scope what automated actors may do. The free scan is at gold.safeguard.sh/scan.
Quick check
Is separation of duties realistic for tiny teams?
Mostly yes. Require that the author cannot be the only approver and let the pipeline, not a person, hold deploy rights.
Should admins be exempt from branch rules?
No. Apply rules to admins too, and use a logged emergency path instead of a standing exemption.
Sources
Last reviewed: 19 October 2026.
