I've slowly come to appreciate Google's emphasis on process/police over engineering coherence (and real security :P), so maybe I'm describing the infuriatingly

I've slowly come to appreciate Google's emphasis on process/police over engineering coherence (and real security :P), so maybe I'm describing the infuriatingly futile here, but... - Box with Ethernet port that connects straight to CorpIT (something something service account) and client/gadget USB port that shows up as mass storage; you talk to the box via a remote server using a userspace tool that speaks FUSE. Everything staged/uploaded gets archived. You could go one step further and tie this in with goma and have the box receive securely built code, so you'd only need to archive git metadata instead of giant blobs. - Engineering-specific Drive frontend could give you token/TOTP/straightforward based access to files, with download audit logging/data archiving (...this would be so simple for CorpIT to provide...) - PCI card with two Ethernet ports, one special one that plugs straight into CorpIT and a data port for single devices or even a local n-port switch; Linux on the card signs the special port into CorpIT via a service account and then uses custom RPC/whatever to mirror all traffic flowing over the data port. Chances are this setup would likely only be able to viably do 10Mbps given that all traffic would be mirrored. The card would require a wakeup (and/or firmware upload) event before the PHY appears, preventing EFI boot confusion. - "Secure bringup services" branch of CorpIT implements processes and makes services available that focus on the fundamentally open-ended requirements of hardware design, which would ideally provide more cohesive solutions that the workarounds described above. IMHO I reckon all those bored engineers would have an absolute field day doing stuff like the above (chasing Impact in a hardware context); it's a great pity they aren't adequately enabled to demonstrate the security implications and priority of doing so.