Repository navigation
Trust gating before third-party creators may declare runtime/workflow capabilities (gates #141) #142
Description
Part of #58. Status note (2026-10-08, #972 audit): #141 is closed — declarative
capabilities are wired through create + update (sanitizeDeclaredCapabilities+ the
lintAgentClaimsclaims-vs-capabilities lint). So this issue no longer gates unshipped work;
it is the trust gate that must exist before third-party creators are let near those
declarations, which is #58's demand-gated open. Related: #75 (browser-agent trust model), #52.
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) acreatortrust 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. -
customSurfacesstays 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).
Activity
feat(agents): wire declarative capabilities through create + update (#…
serge-ivo commentedon Aug 6, 2026
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:350accepts and sanitises declaredcapabilitieson 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 commentedon Aug 6, 2026
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):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.
feat(supervision): a delegated run now records what it DID, not just …
serge-ivo commentedon Aug 18, 2026
Old-issue sweep, 2026-08-18. Gate re-verified:
externalUsers: 0, calls: 0(30d). Thedeferred: no demandlabel stands.But one of the four bullets here should come out of the deferred set, because it is a live gap on first-party agents. The third bullet's mechanism — the creator-declared ceiling a subscriber binds within, enforced server-side at
runRegistryTool— exists and is #404'sCONNECTOR_CONSTRAINTS. It now covers two connectors:terminal(lib/surface-options.ts:214) andtmux(:235).It does not cover
github, and that is not a third-party problem. Every Coder-family agent holdsgithub_create_issue/github_comment_issue/github_update_issuetoday, therepoargument is bounded by the prompt and nothing else, and there are 16 App installations on this account. Migration0123's header names exactly this as the reason it declined to grant the tmux Operator GitHub:And
0120's header records a repo allowlist forgithubas real, separate work that was deliberately not smuggled in.So: a
githubentry inCONNECTOR_CONSTRAINTSis worth doing with zero external users, it is useful to the agents already shipped, and it happens to also be a hard prerequisite for this ticket and for #75. Recommend filing it as an ordinary backend ticket rather than leaving it inside a demand-gated trust epic — that is the only way it gets done before it is needed.The other three bullets (creator trust tier, subscribe-time disclosure, quotas for third-party runtime agents) are correctly parked. The 2026-08-06 note that this should be a blocker on #53/#55/#74/#76 rather than a parallel task is still right and still unrecorded as a link.
serge-ivo commentedon Oct 14, 2026
Owner decision on 2026-10-14: A — keep third-party runtime/workflow capability gating deferred. Runtime/browser/native capability declarations remain first-party/operator-controlled for now. Do not implement creator trust tiers or open third-party runtime declarations until #58 is reactivated by demand.
proagentstore commentedon Oct 24, 2026
❓ The coder stopped on a question: Issue #142 (trust gating for third-party creators) is marked
deferred: no demandby your own decision on 2026-10-14, which says not to implement creator trust tiers until #58 is reactivated by demand. The run objective asks to implement it now. How should I proceed?Options:
Implement #142 now — reverse the deferral·Leave it deferred — close this run as-is·Re-check the issue and implement only what applies to first-party/operator useWhy it asks: The owner's standing deferral decision directly conflicts with the run objective; only the owner can settle which takes precedence.
Answer it on the run's card or with
answer_instance_input. The run is parked until it is answered — answer any time; it continues from where it stopped.