[Epic] Open browser-agent creation to creators — BLOCKED on a trust model

Epic: Open browser-agent creation to creators — BLOCKED on a trust model

The strategic unlock that would make PAGS a real platform: let creators declare runtime:"browser" agents themselves. This must NOT ship as a simple write-path. A browser agent runs on the subscriber's own machine, with their real Chrome profile, logged into their real accounts — so a published agent operates as the subscriber, with their full authenticated session, on any site. Opening that to arbitrary creators without a trust model is a critical safety failure (prompt-injection hijack of a logged-in session, malicious creators exfiltrating/acting-as the user, ToS/abuse).

Today runtime:"browser" is migration-gated (first-party only). That gate is a safety feature, not missing plumbing.

Hard prerequisite (must land first)

Trust & permission model for browser agents (design + implementation)

Then, and only then

Creator capability write-path API

Gating

Do not start until (a) the focus wedge shows real demand and (b) the trust model is designed + reviewed.
Pairs with the third-party-creator program (Epic: first-party exemplary agents → mature the platform → open to third parties (demand-gated) #58).

Non-goals

Shipping a PUT config.capabilities that lets anyone set runtime:"browser" without permission scoping, profile isolation, injection defenses, and review.

Issues (strict order)

[browser][trust] Trust & permission model for browser agents (design prerequisite) #75 Trust & permission model (prerequisite)
[browser][platform] Creator capability write-path API — gated on the trust model #76 Creator capability write-path (blocked on [browser][trust] Trust & permission model for browser agents (design prerequisite) #75)

Gated by #68 + #58.

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.

Closing — this epic holds no work of its own, and two of its three parts are now wrong or done.

Its job was ordering: #75 (trust model) before #76 (write-path API). That ordering has resolved in both directions — #76 is closed (the write path shipped via #141; the residual gating moved to #142), and #75 stands on its own.

What remained here was:

A false premise. "Today runtime:"browser" is migration-gated (first-party only). That gate is a safety feature, not missing plumbing." There is no such gate at HEAD: KNOWN_RUNTIMES (agent-capabilities.ts:361) accepts "browser", and sanitizeDeclaredCapabilities persists it through POST/PUT /v1/agents, behind requireCreator. The real control is now a role grant — new users default to roles:["user"] — not a code gate. Leaving that sentence on the board is worse than having no ticket, because anyone granting a creator role on the strength of it would be wrong.
A non-goal that already happened. "Non-goals: shipping a PUT config.capabilities that lets anyone set runtime:"browser"…" — that is what Wire declarative capabilities (surfaces/runtime/workflow/tools) through create + update — the missing authoring path (#51) #141 shipped, minus "anyone".
One paragraph worth keeping — the rationale: a browser agent runs on the subscriber's machine, in their real Chrome profile, logged into their real accounts. That belongs in [browser][trust] Trust & permission model for browser agents (design prerequisite) #75, which is where the safety layer is designed.

Also worth recording for whoever picks up #75: workers/api/wrangler.toml:30-33 carries the comment "Unset = inert (fail-closed). First-party/self-use ONLY — do NOT enable for third-party creators until the browser trust model (#75)" directly above BROWSER_TOOLS_ENABLED = "1". The browser connector tools are ON in production. Harmless while there are no third-party creators; not harmless as a control that reads as off.

Coverage after this close: #75 = design the trust model · #142 = do not open the authoring path (or grant the creator role externally) until it lands.

Navigation Menu

Repository navigation

[Epic] Open browser-agent creation to creators — BLOCKED on a trust model #74