How One Team Fixed Three Critical Jenkins Agent Security Flaws After Near-Miss

A software team discovered serious security gaps in their Jenkins CI/CD setup after a pull request from an external contributor briefly exposed a live network path to an internal metadata endpoint. Their core mistake was treating Jenkins agents as trusted infrastructure, when in reality agents execute arbitrary code — including from third-party contributors — and are not protected by controller-level access controls. The team had been routing both internal and untrusted fork-PR builds through the same agent pool, inadvertently giving external code access to internal deployment credentials. They had also mounted the Docker socket into agent containers for convenience, which effectively granted any running build root-level access to the underlying host machine. Following a thorough audit, the team separated build infrastructure by trust tier and moved away from docker.sock mounting to eliminate these critical attack surfaces.