| ▲ | drdexebtjl 2 hours ago | ||||||||||||||||
> openai isn't putting AI agents on the open internet either. They did? Not in the training run which led to the HuggingFace hack, but other runs had agents being trained on information retrieval tasks, like the RubyGems hack. > You could argue that openai didn't do enough, but hindsight is 20/20 No, you can argue they didn’t do enough because they didn’t. Air-gapping is a concept you learn in cybersecurity 101. There’s no world in which this is just incompetence, the sandbox must have been designed to fail, or at least not designed to contain an agent with capabilities that they had been publicly saying it had. | |||||||||||||||||
| ▲ | gruez 2 hours ago | parent [-] | ||||||||||||||||
>They did? Not in the training run which led to the HuggingFace hack, but other runs had agents being trained on information retrieval tasks, like the RubyGems hack. The agents were sandboxed, but they escaped the sandbox by using a 0day in artifactory. >Air-gapping is a concept you learn in cybersecurity 101. And that's plainly untennable in cases where access to docs/packages are required. You're just proving the "hindsight is 20/20" point. Most hacks could conceivably be prevented through airgapping, so does that mean every entity who got hacked is criminally liable because they didn't airgap their systems? This isn't limited to air gaps, you can make similar arguments for other security measures. For instance computing history is littered with kernel EoPs and hypervisor escapes. Does that mean anyone who uses a shared hosting environment and gets hacked as a result should be blamed because they didn't follow "cybersecurity 101" and running everything on bare metal? | |||||||||||||||||
| |||||||||||||||||