Newbies can screw up but to do real damage you need management buy-in
Several years ago, I worked in a lab that was pretty much a free for all. The software was tested in the local lab and then deployed in machines with dedicated hardware all over the world. When there was a field issue, support people would often bring in the machine (if they thought it was a hardware issue) or just the hard drive (if they thought it was only a software problem) from the field back to the lab to debug it.
Of course, many of these machines would be absolutely riddled with viruses and malware, which would then run rampant over the lab network. Management's response was not to install antivirus on the lab machines, however. That was too expensive, and frankly, the McAfee software that they had standardized on made computers so disgustingly slow that they were unusable. That was perfectly fine for employee machines, of course. No one cares about them. But customers visited the lab, so the machines there had to be presentable.
Management ordered IT to install a process on every lab machine that would check every USB media connection attempt and check it had a specific file in the root directory. That file would have an MD5 checksum proving it had been checked for viruses by the lab anti-virus machine. The idea was that you brought your USB thumb drive to the lab and plugged it into the virus scanner machine, which would write this time-stamped USB credential file. Then you connected the USB to a lab PC, and the antivirus process would check that the credential file was current and correct. If it wasn't, or if it was missing, the process would eject the USB.
Naturally, neither management nor IT told the engineering staff about this. Projects ground to a halt as engineers took test builds down to the lab and spent hours struggling unsuccessfully to install them on the lab PCs, only to have their USB media ejected as soon as it was connected. Dozens of problem tickets were raised against both lab support and IT, but since only the upper castes in those groups were aware of the cause, several IT and lab support people were trying to debug the issue.
For those engineers whose lab machines had a CD reader, they burned their builds to CDs and were able to install them that way. Of course, they couldn't get logs back, but they could at least be partially productive. Others tried dozens of different USB keys, without success. A third group discovered that if you started a batch job on the PC that continually copied a big file to the USB drive letter in a loop before the USB was connected, once the USB was connected, it would establish a file handle and the disk wouldn't be ejected. That solution was mailed around by engineering leaders to their teams, and it became the de facto resolution.
Delivery dates were missed, customers screamed, and finally, someone in management realized that maybe they should have, oh, announced this change or something. Then they came up with the brilliant idea that instead of just silently ejecting the USB, the software on the PC could put up a message on the screen telling the user why the USB had been rejected, or something.
Ingenius! The software was updated, and an IT person was tasked with upgrading it on all the lab machines. All the machines. Several hundred of them, in multiple labs, on several floors.
The IT person realized that there was a better way. Rather than manually doing 1500+ installs, why not have the users do it? Since they were plugging in USB disks to the lab machines themselves, have the virus scanner install the newer version on their USB, enable the USB's autorun, and then when anyone scanned their USB (which at least some engineers were doing now, since a month after this started, there was a company-wide notice about the change) and plugged it into a new machine, it would install the upgrade! Any machine that was used would be upgraded, and any that weren't upgraded weren't being used in the first place, right? This was a great time saver.
So, the approved solution was to install executable software on the USB and put it in the USB's autorun. And it worked. The first time such a USB was connected to a lab machine, it would update the software, and all was good.
However, on the second connection, the updated software would look at the USB, notice that it had autorun enabled, and was trying to install software on the PC. Oh my god! That's a virus! Quick! Force a disconnect and lock the machine!
People who didn't use the virus scanner and were running the batch file hack to lock the USB didn't have any problem. People who did use the mandated (and mandatory) virus scanner found that after doing so, as soon as they connected to a lab machine, it not only ejected the USB, it immediately locked up. And since only lab personnel had the machine passwords, work stopped until a lab person could be found.
In other words, you were fine as long as you didn't follow company policy. There's a great incentive structure for you.
Even better, when people then plugged their USBs back on their desktop machines, it then spread the "virus" into the corporate network at large.
That time-saving optimization disabled the entire lab for weeks, took IS three days to clean up the corporate network, and IT spent a month scouring all of the remnants of it off of the 1500+ lab machines.
By the way, there never was a case of a virus being transmitted via USB in the lab. Ever. All of the viruses had been transmitted by field personnel bringing hard disks in from the field and installing them in the lab, which completely bypassed the USB checking nonsense. In other words, in addition to all the chaos that it caused, the entire exercise was completely useless at its' stated goal.