Imagine a default Jenkins setup consisting of a single master instance ... a test running on master instance writing to a disk file could potentially ruin the master installation overwriting or deleting the Jenkins configuration files.

This does not feel right, considering this scenario an emphasis could be put on a better security setup consisting of a

• robust backend with REST APIs
• GUI
• jailed workers (chroot, docker container, etc.)
• secured messaging backbone for communication between the core and the workers

IMHO and TBD

I did not find a lot of evidence of this topic so far, it might be quite off track of the current jenkins philosophy compromising a bit of security for usability purposes. However security issues are subject to be discussed in enterprise environments and targeting those might be a viable direction.