No. The Jenkins documentation says it is highly advisable not to run any builds on the built-in node, because that node is the controller itself. Set its executors to 0 under Manage Jenkins, then Nodes and Clouds, and run builds on agents. Configure at least one agent first, or builds will not start.
What the built-in node is, and why it matters
The built-in node is the machine and process where Jenkins itself runs. It holds the Jenkins home directory, job configurations, and stored credentials. A build that runs there executes with the same operating system access as the controller.
Jenkins points out that people who can configure jobs are often less trusted than administrators. A job author can write a pipeline step that runs any command. If that step runs on the controller, a job author effectively becomes an administrator of the host.
How to turn it off
- Create at least one agent or cloud, and confirm a test job runs on it.
- Open Manage Jenkins, then Nodes and Clouds.
- Select Built-In Node and choose Configure.
- Set the number of executors to 0 and save.
The Job Restrictions plugin is mentioned in the same documentation as another way to limit which jobs may use the built-in node.
What if you only have one machine?
You can still run an agent on the same host, as a separate operating system user. Jenkins says that user must have no read or write access to the Jenkins home directory and must not be able to use sudo or similar tools to gain privileges. If the agent user can read the Jenkins home, you have moved the problem, not solved it.
Agent to controller access control
Agents can send requests to the controller. Jenkins has a control that limits what an agent may ask for. Since Jenkins 2.326 it is always enabled. On 2.325 and earlier it is on by default, and the documentation strongly recommends you do not disable it.
Decision table
| Your setup | What to do |
|---|---|
| Agents already exist | Set built-in node executors to 0 today |
| No agents yet | Add one agent, test, then set executors to 0 |
| One host only | Run the agent as a separate OS user with no access to Jenkins home |
| Old Jenkins version | Upgrade, so agent to controller access control cannot be switched off |
Quick check
Will setting executors to 0 break my jobs?
Jobs that depend on the built-in node will wait in the queue with nothing to run on. Add and test an agent first, and give jobs a label that matches it.
Is a separate OS user enough isolation?
It is the minimum Jenkins describes for a single machine. A separate host or a short-lived container agent gives stronger separation.
Safeguard reads the output of your builds, not the build host: it scans dependencies, produces SBOMs, and can enforce policies and gates on pull requests. You can try the free scan on a repository.
Sources
Last reviewed: 19 October 2026.
