Agent to controller access control limits what a Jenkins agent can make the controller do. Since Jenkins 2.326 it is always enabled and cannot be switched off. In 2.325 and earlier it was on by default but could be disabled, which the Jenkins documentation strongly advises against.
The problem it solves
An agent runs build steps, often code from many contributors. If a compromised or malicious build could use the agent connection to read files or run commands on the controller, one bad job would become control of the whole system. The access control layer treats agents as less trusted than the controller.
This fits the way the Jenkins node docs describe agents: they are "assumed to be unreliable." Agents are small Java client processes that connect to the controller, and they host tools directly or inside containers.
Version facts
| Jenkins version | Status |
|---|---|
| 2.326 and later | Always enabled, following the JEP-235 security changes |
| 2.325 and earlier | Enabled by default, can be turned off on the Security page |
The documentation says it is strongly recommended not to disable the system. In older versions, administrators can selectively allow more access instead of disabling the whole thing.
Related hardening
Access control between agent and controller works best alongside these:
- Built-in node. Builds on the built-in node share the file system access of the Jenkins process, which the docs call inadvisable longer term. Set its executors to 0 under Manage Jenkins, then Nodes and Clouds, after you have agents or clouds configured.
- Separate OS user. If you only have one machine, run the agent as a separate OS user with no file system access to Jenkins home and no way to elevate permissions.
- One executor per node. The node docs call one executor per node the safest setting, and one per CPU core only for small tasks.
- Secrets on the command line. The Windows scheduler example in the docs shows an agent secret in plain text on the command line. Treat that as an example of what to avoid in shared environments, and restrict who can read task definitions.
- Job restrictions. The Job Restrictions plugin can limit which jobs run on the built-in node.
What to check on an old controller
- Is the version at least 2.326? If not, plan an upgrade, since the setting may be off.
- Does the Security page show any option that relaxes agent access?
- Are builds running on the built-in node?
- Do agents run as a user that can read Jenkins home?
Try it yourself
The demo shows a container image scan, a way to check what your build agents actually run.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard does asset discovery and scans container images and dependencies, which helps inventory build infrastructure. Try the free scan.
Quick check
Can I turn off agent to controller access control in current Jenkins?
No. It has been always enabled since 2.326.
Does a separate agent user help?
Yes. A separate OS user without access to Jenkins home limits what a build can read on the controller machine.
Sources
Last reviewed: 19 October 2026.
