Advantages and disadvantages of sandboxing agents with OS DAC/MAC, VM, container, user-space, WASM runtime, browser extension permissions, and IDK IFrames and Origins?

How are AI agents built into browsers sandboxed by comparison?

Recent work in sandboxing agents; https://news.ycombinator.com/item?id=47223974

The tension is real, but I think it's the same trust model problem that browser extensions solved years ago — just re-emerging with sharper stakes. The key insight is that 'inside the page' doesn't mean 'unlimited': you can constrain the agent to a declared action space (a list of semantic intents your app exposes) rather than letting it operate on arbitrary DOM mutations. Essentially the app becomes the API surface, and the agent calls into it rather than scripting the UI directly. The session inheritance is then a feature, not a risk, because the agent operates exactly at the permission level of the authenticated user — it can't escalate beyond what a human clicking around could do. The harder unsolved problem is prompt injection: if the page content itself can influence the agent's instructions (e.g., a user-generated comment telling the agent to 'click delete account'), you need the same kind of sandboxing logic that email clients use to strip active content.

This is the problem every agent has to face.

PageAgent’s differentiator is that site developers can embed it directly into their own pages. In that scenario, with proper system instructions plus a built-in whitelist/blacklist API for interactive elements, the risk is pretty manageable.

For the general-agent case, operating on pages you don’t control, the risk is definitely higher. I’m currently working on the human-in-the-loop feature so the user can intervene before sensitive actions.

Would love to hear other approaches if anyone has ideas.