Trust gating before third-party creators may declare runtime/workflow capabilities (gates #141)

[serge-ivo]

Context

#141 wires declarative capabilities (surfaces/runtime/workflow/tools) through the create/update API so agents are authorable as data. That is safe today only because agent creation is operator-only (epic #58 is demand-gated). This issue is the guardrail that must land before the same authoring path is opened to untrusted third-party creators.

The risk

Declaring runtime:"coding"|"browser" + a workflow binding gives an agent's Pilot the ability to drive a CLI or real browser on a subscriber's machine (via pags up) or the subscriber's connected accounts. The blast radius is bounded by:

• closed-enum capabilities (no arbitrary code — that's customSurfaces, separately guarded),
• Pro-gating,
• subscriber consent (they choose to run the runner),
• per-connector write-consent (instance_connector_consent).

But a malicious or low-quality third-party agent that declares a runtime and lures a subscriber into running pags up is a real abuse vector once creation is open.

What this issue must decide/build

• Who may declare runtime/workflow. Options: (a) keep operator/admin-only and require review to flip an agent to a runtime capability; (b) a creator trust tier that unlocks runtime declaration after review; (c) allow declaration but require an explicit subscriber consent screen naming the capability ("this agent will run code on your machine").
• Subscriber-facing capability disclosure at subscribe time — surface runtime/workflow/write-scoped connector tools before the user commits, distinct from the current silent capability resolution.
• customSurfaces stays operator-only / sandboxed (it loads a code bundle into the console origin) — must NOT ride the Wire declarative capabilities (surfaces/runtime/workflow/tools) through create + update — the missing authoring path (#51) #141 path open to creators. Cross-link the Tier-2 sandbox ([3P] Tier-2: sandboxed creator code via Dynamic Workers (CRITICAL PATH) #52).
• Rate/quota + kill-switch for runtime-capable third-party agents.

Critical assessment

This is a policy + UX problem more than a code one — the enforcement points already exist (capability resolution, consent gate, Pro-gate). The missing pieces are (1) a trust tier on the creator, (2) an honest subscribe-time disclosure, (3) keeping the one genuinely code-executing surface (customSurfaces) off the open path. Until this lands, #141's capability-write routes must remain owner/admin-gated (they are).

Refs: #74, #75 (trust model epic), #58 (open-to-third-parties epic), #52 (Tier-2 sandbox), #141 (the wiring this gates).

[serge-ivo]

The ordering this describes has inverted in reality, and that is worth marking explicitly.

This issue says the guardrail "must land before the same authoring path is opened". #141 has since shipped — routes/agents.ts:350 accepts and sanitises declared capabilities on create and update. So the authoring path is live and the gate is not.

That is still safe today for exactly the reason stated here — creation is operator-only (#58 is demand-gated) — but the safety is now a deployment fact rather than a code property, which is a weaker guarantee than the one this issue was written to provide.

Suggest labelling this a blocker on any external-creator work (#53, #55, #74, #76) rather than a parallel task, so the dependency cannot be satisfied by accident.

[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.