✓ Sopravvissuta 1ª su 16 proposteIndie Sicurezza 8 nov 2026

Registro di estensioni verificate e sandbox per agent harness

Un livello di sicurezza per gli agent harness di coding open source: registro di estensioni verificate, installazioni che proteggono i token OAuth e un motore di permessi nativo che blocca le azioni pericolose.

Apri la discussione ↗

Un brief pronto da incollare in Claude Code, Cursor o qualsiasi agente di programmazione (in inglese).

I want to build a small, bootstrappable product. Help me plan and start the MVP.

Product: Vetted extension registry and sandbox for agent harnesses
What it is: A security layer for open-source coding-agent harnesses: vetted extension registry, OAuth-token-safe installs, and a native permission engine that blocks dangerous actions.
Who pays: Engineering leads and staff devs at 20–200 person companies adopting open agent harnesses (Pi and clones), paying $50–200/mo per team from the dev-tools/security budget; also prosumers at $10–20/mo.
Closest alternatives: npm audit / Snyk (generic dependency scanning, blind to agent-extension threats , Claude Code's built-in permission system (only works inside its own harness), OS-level sandboxing like Docker/Seatbelt (no agent-aware policies), Pi community extensions (unvetted, self-serve)
The gap: Open harnesses are accumulating a fast-growing extension ecosystem with zero supply-chain vetting and no native runtime safety defaults; generic dependency scanners don't check for OAuth-token exfiltration, hidden prompt injection, or scope creep in agent extensions, and no product fills this.
Why now: The open-harness ecosystem (Pi and similar) has exploded in the last ~12 months along with subscription-based OAuth access, creating both a new attack surface (token theft leading to account bans) and a new class of extension supply-chain risk that nobody has productized defenses for yet.
Moat to build toward: A curated, audited extension registry plus a continuously updated threat-intel feed of agent-extension attack patterns compounds with adoption; becoming the default trust layer creates a distribution lock-in similar to package registries.
Biggest risk: Pi (or another harness vendor) ships native sandboxing and an official vetted registry, collapsing the third-party opportunity before the market is big enough.

First three steps:
1. Build a static analyzer that scans Pi extensions for token exfiltration, network calls, and prompt-injection patterns, and publish a scored public registry.
2. Ship a permission-policy extension for Pi that enforces an auto mode (dangerous command blocking, approval rules) so users get Claude-Code-grade safety natively.
3. Release a 'hardened profile' bundle (sandbox launcher + vetted extensions) and sell team seats with org-wide policy enforcement.

Start by asking me up to five questions about constraints (stack, budget, timeline), then propose the smallest version a paying customer would use, and scaffold it.

Totale6.1/10

Problema6

Disponibilità a pagare5

Tempismo8

Vuoto di mercato7

Fossato5

Fattibilità6

A favore

Chi paga

Engineering lead e staff developer di aziende da 20 a 200 persone che adottano agent harness open source (Pi e cloni), con un budget dedicato a dev-tools e sicurezza da 50 a 200 dollari al mese per team; anche prosumer a 10-20 dollari al mese.

Cosa ha detto la gente · 4

Sono tornati a Claude Code perché l'harness open source non ha una modalità automatica integrata che blocchi le azioni pericolose e non verifica i moduli di terze parti più diffusi. Leggi il commento ↗
Non si fidano di affidare il token OAuth alle estensioni di terze parti, citando segnalazioni ricorrenti di utenti bannati dopo fughe di token e abusi. Leggi il commento ↗
Hanno costruito a mano un proprio livello di sandboxing sopra Pi solo per ridurre il rischio che gli agenti compiano azioni distruttive. Leggi il commento ↗
Hanno configurato manualmente regole di pattern matching che richiedono approvazione per le chiamate CLI distruttive e le modifiche ai file, replicando impostazioni di sicurezza predefinite che l'harness non include. Leggi il commento ↗

Parafrasato dalla discussione. Segui i link per i commenti originali.

Concorrenti e lacuna

npm audit / Snyk (generic dependency scanning, blind to agent-extension threats Claude Code's built-in permission system (only works inside its own harness)OS-level sandboxing like Docker/Seatbelt (no agent-aware policies)Pi community extensions (unvetted, self-serve)

Gli harness open source stanno accumulando un ecosistema di estensioni in rapida crescita senza alcuna verifica della supply chain e senza impostazioni di sicurezza runtime native; gli scanner generici di dipendenze non controllano esfiltrazione di token OAuth, prompt injection nascosta o scope creep nelle estensioni degli agenti, e nessun prodotto copre questo spazio.

Perché ora

L'ecosistema degli harness open source (Pi e simili) è esploso negli ultimi 12 mesi insieme all'accesso OAuth basato su abbonamento, creando sia una nuova superficie di attacco (furto di token che porta al ban degli account) sia una nuova classe di rischi nella supply chain delle estensioni per cui nessuno ha ancora messo sul mercato delle difese.

Fossato · 5/10

Un registro di estensioni curato e sottoposto ad audit, unito a un feed di threat intelligence costantemente aggiornato sui pattern di attacco alle estensioni degli agenti, cresce con l'adozione; diventare il livello di fiducia predefinito crea un lock-in di distribuzione simile a quello dei registri di pacchetti.

Contro

Red team: L'ecosistema delle estensioni degli harness open source presenta rischi di supply chain reali e distinti (furto di token OAuth, prompt injection nelle estensioni) che gli scanner generici e l'idea di integrità delle estensioni IDE non affrontano, e la finestra di minaccia è davvero nuova.
Cosa la farebbe fallire: Pi (o un altro vendor di harness) rilascia sandboxing nativo e un registro ufficiale verificato, azzerando l'opportunità di terze parti prima che il mercato sia abbastanza grande.

Partire

I primi tre passi: Creare un analizzatore statico che scansiona le estensioni di Pi alla ricerca di esfiltrazione di token, chiamate di rete e pattern di prompt injection, e pubblicare un registro pubblico con punteggi.
Rilasciare un'estensione di policy dei permessi per Pi che applica una modalità automatica (blocco dei comandi pericolosi, regole di approvazione), così gli utenti ottengono una sicurezza di livello Claude Code in modo nativo.
Pubblicare un bundle di 'profilo rinforzato' (launcher sandbox + estensioni verificate) e vendere licenze per team con applicazione delle policy a livello di organizzazione.
Discussione originale: Goodbye Claude, hello Pi ↗ 605 punti391 commentiDai commentiArticolo collegato

Tradotto dall'inglese. Leggi l'originale