The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).
What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().
For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.
I came across sandstorm a few years back too -- so my mind was blown to learn workers and CloudflareOS are a better implementation of that project.
Cloudflare becoming FedRAMP High recently is a big deal in my little world. I'm trying to learn everything I can about it for our little AI consultancy.
CloudflareOS looks like the sandboxing piece I was just starting to put together -- agents and MCPs behind real security boundaries. Sandboxing is so damn important in this space and most of the other providers ignore it completely or just give it lip service. I think the workers concepts are going to supercharge way more than folks are giving you credit for (in the HN thread a few weeks back there were a lot of dubious folks -- I see it more like the Dropbox announcement).
I hope our paths cross at some point soon. I would love to get more understanding of CF and the roadmap for COS.
Or at least, ideally. Unfortunately, content-security-policy today has a few exotic holes. WebRTC, for instance, cannot be blocked; the standard simply doesn't cover it.
So it's not suitable as a sandbox against malicious code trying to leak data by any means possible. Instead it's protection against the AI doing something stupid, perhaps prompted by a user who doesn't know better.
(We would love to get those CSP holes plugged, though...)