Key Takeaways
- Attackers breached a user application hosted on Modal to target Hugging Face, using the compromised environment as an open springboard to gain internet access.
- Modal's underlying sandbox held, but customer-level vulnerabilities showed how easily application breaches can be mistaken for platform infrastructure failures.
- Bernhardsson compares sandbox security to AWS S3, arguing that platforms must restrict default network and storage permissions rather than trusting developers to harden them.
- Modal deploys autonomous agents into internal sandboxes to run continuous "escape the room" challenges that test for privilege escalation paths.
- Incumbent cybersecurity vendors will survive autonomous offensive and defensive agents because enterprise buyers purchase brand trust and corporate risk mitigation, not just code.
App Layer Vulnerabilities Still Damage Cloud Reputation
When an application hosted on Modal was breached and pointed at Hugging Face, the initial public assumption was that Modal's platform had failed. In reality, the customer application contained the vulnerability, not the underlying compute layer.
Bernhardsson compares the confusion to public cloud infrastructure: “This is an app running on Modal that was hacked. It was not Modal that was hacked. AWS, a lot of people run stuff on AWS. Occasionally those apps get hacked. Does that mean AWS got hacked? No, of course not.”
Attackers found a flaw in the user code and turned that runtime into an open proxy. As Bernhardsson explains: “The agents running inside that exploited Hugging Face, they discovered a vulnerability in an app that was deployed on Modal, and they used that almost like a springboard for getting full internet access.”
For founders building agent platforms, this highlights the shared responsibility trap. If an execution environment grants unrestricted outbound internet traffic by default, a customer vulnerability quickly morphs into an abuse incident associated with your brand.
AWS Fixed S3 by Clamping Down on Default Permissions
When Amazon Web Services launched S3, creating a publicly accessible bucket was simple. Customers routinely left buckets open and leaked data. Even though those leaks were customer configuration mistakes, AWS eventually stepped in and made private access the strict default.
Modal is now considering the same structural shift for agent compute. “S3 used to be very easy to accidentally make public,” Bernhardsson notes. “AWS realized it doesn't necessarily pose a security problem for AWS per se, but a lot of their customers accidentally would leak data. And so S3, it's much harder now to make S3 buckets public. We're exploring: can we make security a little bit more restrictive by default without destroying the magic?”
For serverless agent sandboxes, making security restrictive by default means blocking outbound internet calls, restricting write access to the host, and stripping environment variables until a developer explicitly configures them.
Modal Uses Autonomous Agents to Test Sandbox Escapes
To find internal vulnerabilities before attackers do, Modal sets autonomous agents loose inside its own sandboxes with "escape the room" challenges, commanding them to escalate privileges and break through virtualization barriers.
“We started using agents internally quite a lot to try to find vulnerabilities,” Bernhardsson says. “So far hasn't found anything, but they're very good at probing into very deep parts of the system and trying to exploit things and trying to escalate and get out of sandboxes.”
Bernhardsson sees agents as dual-use tools: “My view on cybersecurity is that they're very good at finding vulnerabilities, but I think you can also use them defensively very well.”
However, Bernhardsson rejects the idea that autonomous security agents will wipe out established cybersecurity providers. Startups often assume superior technical detection makes old vendors obsolete. In enterprise software, companies buy established vendors to offload legal liability and satisfy risk boards. Brand equity protects incumbents from agent disruption far longer than pure software advantages do.
What to Do With This
Audit your agent execution environments this week and block unconstrained outbound internet traffic by default. If your platform executes dynamic user code or user-directed tasks, enforce an allowlist for external network requests, purge host environment secrets from the runtime container, and set hard execution timeouts to kill rogue processes within 60 seconds.