Mozilla wants AI agents to inherit the extension permission model — I counted what that model looks like at scale

There's an AI agent somewhere clicking through a browser session right now, logged in as a real person, doing real things to real accounts. Ask a simple question about it — what exactly is it allowed to touch, and how would you take that back mid-task? — and the honest answer today is: nobody knows, and you can't.

Mozilla's answer to that is the thing sitting in your browser already. On July 6, 2026, they opened issue #1041 in the W3C WebExtensions repo, titled "Browser-mediated permission lifecycle for AI agents acting on a user's behalf." The pitch: agents need a browser-enforced permission lifecycle, and the browser already has one — the one built for extensions.

I run a catalog that reads the manifest of every extension across the Chrome, Firefox and Edge stores. So before anyone borrows that model, it's worth looking at what it actually looks like in production.

What was actually filed

The proposal names four primitives: request, grant, revoke, audit. Nothing exotic. That's roughly the shape of every permission system you've ever used, and the argument is that agents currently have none of it enforced anywhere that counts.

The gaps the issue calls out are specific:

• Agents get broad, all-or-nothing access — a full session, a complete OAuth scope — with no way to scope it down.
• Permission settings live at the application layer, not the browser layer, so nothing enforces them below the app that asked.
• There's no standard way to revoke access mid-task, which is the moment you'd most want to.
• Users can't see what an agent did.

The case for putting this in the browser is that the browser already ships the abstractions — origins, permission grants, process isolation — and it's the last enforcement point the user actually controls. Browsers, the issue argues, currently have no concept of an agent as a principal, can't attribute an action to one, and offer no audit surface.

It went to the community group's public meeting on July 16 as a triage item (agenda issue #1043). As of August 10, 2026, it still carries needs-triage labels for Chrome, Firefox and Safari. Translation: it's a live, unresolved discussion, filed by one vendor, with nobody having taken a position yet. This is not a shipping feature and not a date on a calendar. It's the moment where the shape gets decided.

The scale of the thing being used as a template

Here's the number I'd want on the table during that discussion. Across the stores we track, our catalog holds 300,503 extensions reaching roughly 3.41 billion monthly users.

To be clear about what that figure is and isn't: it's the whole tracked ecosystem, not a count of things about to break. A permission-model change at the standards layer doesn't strand a subset of extensions — there's nothing to migrate here yet. I'm quoting it because it's the size of the working example. When someone says "let's do for agents what we did for extensions," that's the what we did: three hundred thousand programs holding grants inside browser sessions belonging to a few billion people.

And the track record of that model isn't spotless. Of that same set, 12,277 listings have already been pulled from their stores — listings that between them once reached about 180 million monthly users. Store review caught them, eventually. That's the cleanup rate on the permission system now being proposed as the blueprint. It's still the best deployed answer anyone has, and it still leaks at that scale.

Scale isn't the only property that would transfer. Grant width would too. Across the live listings in our catalog, 34,237 declare blanket access to every site — <all_urls> or one of its wildcard equivalents. That's what a grant under this model looks like in practice: not "read this tab while I'm looking at it" but every page, every session, until you uninstall. Inherit that granularity for agents and the request-and-grant step becomes a formality you click once.

Extensions have three of the four primitives, badly

Run the proposal's four primitives against what extensions actually do and the scoreboard is uneven.

Request and grant — solid. It's the visible part: an install prompt, a permission list, optional permissions you can ask for later.

Revoke — partial. You can turn an extension off or remove it. What you can't do is claw back a grant in the middle of whatever it's doing, which is precisely the mid-task revocation gap the issue flags for agents. Extensions have the same hole; nobody notices because extensions don't announce when they're working.

Audit — essentially absent. Nothing in Chrome or Firefox tells you what an installed extension did last Tuesday at 3am with the access you gave it. You can see the permission it holds. You cannot see the actions it took. That's a permission model that answers "what could happen" and never "what happened."

The reason audit is the hard one is that it needs something the other three don't: attribution. Request, grant and revoke are all decisions about a principal, and the browser only has to remember the answer. Audit has to tag every network call and every DOM write with whoever caused it, then keep that record somewhere the causing party can't edit. The issue names this gap directly — browsers today have no concept of an agent as a principal and can't attribute an action to one. Which is exactly why bolting audit on afterwards tends not to happen: it's the primitive that has to be designed in from the start, and the deadline for doing that is now, while the shape is still open.

If agents inherit only the first three, we've shipped the extension model's weakest link into a system that acts autonomously and much faster. The audit primitive is the one worth fighting for, and it's the one extensions never got.

That gap is also why agent-adjacent attacks are hard to spot from the outside — I dug into the browser-side version of this in man-in-the-prompt attacks.

What to do while the standards people argue

Nothing here changes your browser today. What it should change is what you check.

1. Treat agent access like extension access. If you've handed a browser-using agent your logged-in session, it inherits every permission that session has. That's broad host access by another name — the same problem I picked apart in <all_urls> explained.
2. Audit what you already granted. Open chrome://extensions (or about:addons) and remove anything dormant. Dormant doesn't mean inert — it keeps its grants.
3. Check the ones you keep. Search the Extenshi catalog for the full declared permission set next to what the extension claims to do, or run npx @extenshi/guard scan to check what's already installed in your browsers and disable things with undo. No account needed for the scan.

If you build extensions, this discussion is where your platform's next permission surface gets designed, and it's open — the issue explicitly asks what lessons transfer from extension permissions. Worth 20 minutes of your opinion. And before your next upload, npx @extenshi/cli will flag permission patterns store review dislikes — 3 scans free, one-time, with prepaid packs past that.

Check your permissions now →

Sources

• W3C WebExtensions issue #1041 — "Browser-mediated permission lifecycle for AI agents acting on a user's behalf"
• W3C WebExtensions issue #1043 — community group meeting agenda, July 16, 2026

---

This article is based on publicly available standards discussions and our own catalog data. The W3C proposal referenced here is an open, unresolved discussion, not a finalized or shipping change, and no browser vendor has stated a position on it. Extenshi does not independently verify all claims made by third-party sources. References to specific companies or products do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].