[browser][trust] Trust & permission model for browser agents (design prerequisite)

[serge-ivo]

[browser][trust] Trust & permission model for browser agents (design prerequisite)

Design (then implement) the safety layer that MUST exist before any non-first-party agent can drive a browser. Blocks the creator write-path.

Must cover

1. Per-agent permission scope — declared up front, consented to by the subscriber: domain allowlist, action allowlist (read-only vs click vs type vs navigate-off-origin vs upload), and which of the subscriber's connected sessions it may touch.
2. Profile isolation by default — sandboxed/empty Chrome profile unless the subscriber explicitly grants real-profile + specific-site auth.
3. Prompt-injection defenses — page content fenced as data-not-instructions (extend the RAG fencing; browser DOM is a worse channel); block navigation off the declared allowlist; ignore in-page "instructions."
4. Sensitive-action gates — send/pay/delete/post/message require human approval by default; mass-action throttles (the "accept/message ALL" class).
5. Creator review + reputation + full per-action audit (build on the [Admin] Foundation: access control gating + admin-action audit log #28 admin audit log).
6. Consent + ToS — subscriber sees exactly what an agent can do before running; clear stance on site-ToS/abuse.

Acceptance

• Written threat model + permission schema.
• Enforcement points identified (runner, workflow, route).
• Reviewed before implementation begins.

Part of the open-browser-agents epic. Hard-blocks the write-path.

[serge-ivo]

Labelled deferred: no demand — not cancelled, and not started.

Per #250 ("the board contradicts the focus bet — make deferred-by-strategy legible"), and #58's own wording, which gates this work on demand rather than on readiness.

The measurement that decides it, taken 2026-08-06 over 30 days (GET /v1/admin/usage/external):

external users:  0
operator calls:  2,782
spend:           $40.92 — entirely the operator's own

This issue serves third-party creators. There are none, and nothing on the board measures progress toward getting one. Leaving it as live work makes the roadmap read as if it were in flight, which is precisely what #250 objects to.

The un-gate condition is #68's: external users on a first-party runtime agent. When that number is non-zero, this comes back — the endpoint above makes it checkable rather than a matter of opinion.

Nothing here is judged wrong or wasted. The platform work that already landed (capability registry, connector framework, declarative pipelines, per-tool consent) is what makes first-party agents cheap to build, and it stays. What is deferred is the marketplace layer on top: sandboxing untrusted creator code, curated publish review, payout metering, creator onboarding.