We actually have this with the permissions API. The issue is everyone just opts for longer approval times and less intrusive UX with manifest level permissions.
I agree though, runtime permissions should be the default
> Not sure where you heard this but general sentiment is the opposite.
My personal experience and anecdotal evidence is in line with this hypothesis. Using the likes of Microsoft's own Copilot with small simple greenfield TypeScript 5 projects results in surprisingly poor results the minute you start leaning heavily on type safety and idiomatic techniques such as branded types.
> There was recently a conference which was themed around the idea that typescript monorepos are the best way to build with AI
It's especially tricky since monorepos are an obvious antipattern to begin with. They're a de-separation of concerns: an encouragement to blur the unit boundaries, not write docs, create unstable APIs (updating all usages at once when they change), and generally to let complexity spread unchecked.
Hate to say it but this sounds like a skill issue. The reason Typescript monorepos are gaining popularity for building with AI is because of how powerful TS's inference system is. If you are writing lots of types you are doing it wrong.
You declare your schema with a good TS ORM then use something like TRPC to get type inference from your schemas in your route handlers and your front end.
You get an enforced single source of truth that keeps the AI on track with a very small amount of code compared to something like Java.
This really only applies to full stack SAAS apps though.
The agent mode is really disappointing. I thought OpenAI would try to be more innovative with how the agent interacts with webpages, but it looks like it's the same DOM parsing and screenshot workflow the rest of the AI browser agents use. Giving the agent full access to the page is a recipe for disaster.
We have better tools for this now. This is a draft video I put together for the W3C demoing WebMCP. It blows their agent mode out of the water, and you can even use in-browser models for inference (see the end of the video)
It's more providing permission granularity on the action level rather than the sandbox level. Your script might not be able to make external api calls, but there is no way to gate the ability to take destructive action within the webpage.
With something like WebMCP you get elicitation and the ability to disable tools from the client.
WebMCP essentially turns your website into an MCP server. Which means it is kind of like building a UI for the LLM that lives alongside the human UI.
It's also a contract for how LLM's interact with a website, they can do no more than the tools allow them to do. When you are running javascript on the page, the entire website is an attack surface.
Let's take gmail, for example. There is no way to protect your webpage from an agent running a script that sends an email by triggering the send email button. But with WebMCP, you can explicitly disable the "send_email" tool when the agent interacts with gmail.
I left my job to work on my side project (MCP-B: https://news.ycombinator.com/item?id=44515403) full time. I set out with the goal of making the ability to vibecode a webMCP server for your website and inject it via userscript.
While building that, I basically wrote a modern version of Tampermonkey with its own marketplace built in. So you can vibe code any userscript and publish it to the marketplace all within the extension.
The automation stuff is still the core value-prop, but this is a fun bonus feature while I work on solidifying the automation features.
I'm writing a HN post for it. Excited to show everyone in a couple weeks here.
This might the best collection of resources:
https://github.com/ryanspletzer/oidc-oauth-spec-graph