[3P] Automated pre-review safety scanning

[serge-ivo]

Part of the open-to-third-party program. Feeds the curated review queue (#W3) so humans see risk up front.

• Static checks on submitted config + code: declared tool scope vs actual use, SSRF/egress (`lib/ssrf.ts`), any attempt to read secrets/other tenants, prompt-injection heuristics in the system prompt, obvious cost-bomb patterns (unbounded loops/fan-out).
• Produce a risk score + findings attached to the review item.
• Hard-block on clear violations (secret access, eval, cross-tenant); soft-flag the rest for the human reviewer.

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