I think browsers would be good for agentic sandboxes -- seeking security advice

Like lots of people I've been programming a lot with AI agents. And I think the future is in some way a system of personalized software, where everyone 'owns', jointly with their agents, their own frontend to all the services they use. Browsers already have decent process isolation and some kind of capability system with a UX design paradigm of user-prompts for approval gating access to sensitive resources (like storage, microphone & camera access), so I think they're a good and lightweight fit and alternative to containers. The big labs are building their own walled garden 'superapps' that are approaching this. A lot of them work with containers of some sort.

While that may be the way of the future, I think I would prefer a system that is a bit more like a browser. I do think that agents are so heavily trained on repos / folder structures that you do need to give them a sandboxed file-system. But I don't think you need to give them a full Unix environment. Just JS, DOM, workers with some bells & whistles could suffice.

So I started vibecoding such a system, just as a prototype, and now I really need some advice on how to structure the security.

I came up with the following:

• A custom browser, built with Electron, for displaying UIs
• A workerd server for isolated background processes / agents
• JS/TS app-internal build system and type checker
• An RPC system
• Context-isolated file system, which can be shared between workers and frontend panels (accessed via RPC gated by user approval)
• An out-of band system for user approval prompts with a simple notion of severity
• A credentials store that can be used (approval gated) via an egress proxy for access to external services

As I have been building this, I already noticed that there's such a potential for this to get messy. I've started looking into adding a fine grained capabilities system, somewhat inspired by the Android approach.

But one of the challenges that I face is that a lot of our approaches to capabilities seem to have been formulated for static code artifacts. At its core, however agents constantly are doing eval of dynamically generated code. -- So static manifests are either way too broad (we're back to ambient authority), too restrictive (people won't use it) or lead to constant approval request spam. Any ideas on how to handle that?

Other, perhaps questionable choices here have been (so far):

• I added a way to run trusted node code in an extension system, as an approval gated escape hatch, but I don't yet have a way to lock things down, to make it impossible to edit / deploy extensions from a given workspace. -- Some of these are just to run native code that doesn't really have to touch the host and could benefit from an actual container.
• The same goes for frontend UI: It seems attractive to allow agents inside the system customize the frontend experience for the desktop browser, as well as a mobile app host -- but that's another softening of boundaries.

Here's a link to what I've been working on: vibestudio

To sum it up:

• I think there will be a continuing trend of people vibe-coding their own personalized software which needs some kind of sandbox and security structure.
• I'd want this to be really light-weight and include not just the agents running in the backend, but also the frontend side-of things in one system.
• This can be a fairly lightweight and one-size-fits-all runtime environment like the browser has been.
• The browsers that we already have don't quite offer the functionality that we'd want for an agentic personal software environment.
• This is a bit of an opportunity to sneak in some decent security primitives, but also really challenging since AI is inherently messy and a very confusable deputy.