A feature flag is production configuration that changes behavior without a code deploy. That means it needs the same controls as other config: restricted write access, review for risky changes, an audit trail, and a known owner for every flag.
Why flags escape normal review
Code changes go through pull requests, tests and approvals. A flag change often goes through a dashboard in a few clicks. Martin Fowler's feature toggle article notes that operators need to change some toggles quickly, so a full redeploy is often too slow. That speed is the point, and it is also the risk.
If anyone with dashboard access can turn on an unreleased code path in production, the dashboard is part of your deployment pipeline. Treat it that way.
Four kinds of flag, four risk levels
Fowler describes four categories: release toggles, experiment toggles, ops toggles and permissioning toggles. They carry different risks.
- Release toggles hide incomplete and untested code in production. The risk is that someone turns on a path that was never meant to run for real users.
- Experiment toggles route users into cohorts. The risk is data handling, because they usually evaluate user attributes.
- Ops toggles let operators degrade features during incidents. The risk is that an unreviewed change disables a control.
- Permissioning toggles decide who gets which features. These are access control in disguise and should be handled like authorization code.
Controls worth having
- Write access by role. Not every developer needs production flag access.
- Approval for flags that touch authentication, payments or data access.
- An audit log that records who changed what and when.
- An owner and a purpose written next to every flag.
- A safe default when the flag service cannot be reached. Decide it on purpose.
- Test both states of a flag before release.
Fowler suggests keeping toggle config in source control where possible, so changes ride through the same pipeline as code. Where a runtime dashboard is needed, replicate the review habit with approvals in the tool.
Related reading
Flags also have a lifecycle problem. See stale feature flags and expiry dates and kill switch design.
Where Safeguard fits
Safeguard policies and gates apply the same idea to the software supply chain: rules written down, enforced automatically, with a record of each decision.
Quick check
Is a feature flag a security control?
Not by itself. A permissioning flag can act as one, and any flag can weaken a control if it is changed carelessly, so access to change flags matters.
Sources
Last reviewed: 19 October 2026.
