The Whitelisting feature that I am suggesting (already implemented - see https://github.com/jenkinsci/job-dsl-plugin/pull/968), would enable Jenkins Admins to control what types of jobs regular Jenkins users are able to create.

My strategy includes two ways to whitelist. 1) You can whitelist external classes that are allowed to define blocks of dsl. 2) You can also whitelist what's directly in the script to be processed (doesn't look at any dsl blocks imported from other classes), by specifying the xml parents that are allowed to be generated.

You can also do a combination of the two. In our use case what we'll be doing is using the 1st whitelisting option to whitelist a helper class which has most of our build dsl blocks in it (defined by our central build and deploy team), and then we will use the 2nd whitelisting option to whitelist some publishing elements that we want our developers to be able to configure to their hearts content. (we use the second whitelisting option for this because developers will be defining this directly in the job-dsl.groovy file that they will be checking into source control).

This also works because the developers don't have access to the actual seed job. The seed job is simply configured by our admin team to pick up a job-dsl.groovy file from updated repos. So all developers have to do is check in that file and away they go! Configuration options for the average developer + continued security and governance on our shared build agents!