Currently Queue.Item.authenticate and Tasks.getAuthenticationOf check any configured QueueItemAuthenticator instances for a specific answer, then fall back to Queue.Task.getDefaultAuthentication, which for compatibility is normally SYSTEM. This behavior makes sense if there are no configured authenticators (the default case), or if there is an authenticator which returns a non-null authentication for every task.

The problematic case is when there is a configured authenticator yet it returns null for the given task or item. This could happen if for example ProjectQueueItemAuthenticator were configured yet a user created a new job and did not add a AuthorizeProjectProperty. Now the job runs as SYSTEM, with full privileges, whereas we would really want it to run as ANONYMOUS, with no special privileges.

BuildTrigger and ReverseBuildTrigger already specially handle this case by substituting ANONYMOUS for SYSTEM while they run (and in the former case printing a warning to the build console). But this does not extend to other plugin or core access control checks.

In particular, Computer.BUILD is checked in two places (on Item) when deciding whether to build a job on a particular slave. You would expect to be able to control access to sensitive slaves by selectively granting BUILD only to certain people, and then requiring them to associate themselves with jobs they wish to build on those slaves. But this scheme cannot work if they can simply omit any authentication on the job and still have the build be authorized. (Jenkins Enterprise by CloudBees has a feature using a different scheme for the same use case.)

It would be better if the callers of QueueItemAuthenticator.authenticate fell back to getDefaultAuthentication but replaced SYSTEM with ANONYMOUS in case there were at least one authenticator consulted. Then the replacement of SYSTEM with ANONYMOUS could be removed from both BuildTrigger and ReverseBuildTrigger. BuildTrigger.warning_you_have_no_plugins_providing_ac and BuildTrigger.warning_access_control_for_builds_in_glo could be left as is, or made more generic and moved into Run.execute; BuildTrigger.warning_this_build_has_no_associated_aut should be made more generic and moved into Run.execute (and Run.running_as_ printed with anonymous).