For production, start with matrix based security, or project based matrix authorization if teams need separate access. Avoid the "Anyone can do anything" setting outside a local test controller. Jenkins also keeps login and permissions as two separate settings, so configure both.
Two settings, not one
Access control has a security realm, which answers who can log in, and an authorization strategy, which answers what they can do. The realm can be Jenkins' own user database, LDAP, SAML or OpenID Connect SSO, or PAM, and plugins add more such as Active Directory and Entra ID. You must configure each on its own.
The options compared
| Strategy | What it does | Fit |
|---|---|---|
| Anyone can do anything | Full control for everyone, including anonymous users | Local testing only. The docs say not to use it otherwise |
| Legacy mode | Mirrors versions before 1.164. Admin users get full control, others read | Old setups only |
| Logged in users can do anything | Any logged in user has full control. Anonymous gets read or none | Small trusted teams, gives an audit trail |
| Matrix based | Per user and per group permissions, with special anonymous and authenticated entries | Recommended starting point for production |
| Project based matrix | Adds per project access control lists on top of the global matrix | Many teams on one controller |
Permissions in a matrix are additive. A user receives the union of their own grants and those of their groups.
How to choose
- One small team, everyone trusted: logged in users can do anything may be enough, with anonymous access removed.
- Several roles, such as admins, developers, and read only auditors: matrix.
- Several teams that must not touch each other's jobs: project based matrix.
Keep the Administer permission to very few accounts. Give developers only what they need, such as Job Build and Job Read on their folders.
Common mistakes
- Leaving anonymous Read on a controller that holds private job names.
- Granting Overall Administer to a whole group for convenience.
- Forgetting that installed plugins can add their own permissions to review.
- Never reviewing the matrix after staff changes.
Try it yourself
The demo walks through a gate on a pull request, a good model for thinking about who can change what.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for software changes, and compliance evidence automation for access reviews. A free scan shows what it finds in your code.
Quick check
Is "logged in users can do anything" safe?
It gives every logged in user full control, so it only fits a small, trusted group. It does create an audit trail, since users must log in.
What does additive permissions mean?
A user gets the union of the permissions granted to them directly and to every group they belong to.
Sources
Last reviewed: 19 October 2026.
