✓ Sobrevivió Puesto 1 de 16 propuestasIndie Seguridad 8 nov 2026

Registro de extensiones verificadas y sandbox para agent harnesses

Una capa de seguridad para harnesses de agentes de código de código abierto: registro de extensiones verificadas, instalaciones seguras para tokens OAuth y un motor de permisos nativo que bloquea acciones peligrosas.

Abrir el debate ↗

Un brief listo para pegar en Claude Code, Cursor o cualquier agente de programación (en inglés).

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.

Total6.1/10

Dolor6

Disposición a pagar5

Momento8

Hueco7

Foso5

Viabilidad6

A favor

Quién paga

Engineering leads y staff devs en empresas de 20 a 200 personas que adoptan harnesses de agentes abiertos (Pi y clones), pagando entre 50 y 200 USD/mes por equipo desde el presupuesto de dev-tools/seguridad; también prosumers a 10–20 USD/mes.

Lo que dijo la gente · 4

Volvió a Claude Code porque el harness abierto no tiene un modo automático integrado que bloquee acciones peligrosas y no verifica los módulos populares de terceros. Leer el comentario ↗
No confía su token OAuth a extensiones de terceros, citando reportes recurrentes de usuarios baneados tras filtraciones y abusos de tokens. Leer el comentario ↗
Construyó por su cuenta una capa de sandboxing sobre Pi solo para reducir el riesgo de que los agentes hagan algo destructivo. Leer el comentario ↗
Configuró manualmente reglas de coincidencia de patrones para que las llamadas CLI destructivas y las ediciones de archivos requieran aprobación, replicando valores de seguridad por defecto que el harness no incluye. Leer el comentario ↗

Parafraseado del debate. Sigue los enlaces para ver los comentarios originales.

Competidores y hueco

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)

Los harnesses abiertos acumulan un ecosistema de extensiones que crece rápido sin ninguna verificación de cadena de suministro y sin valores de seguridad en tiempo de ejecución por defecto; los escáneres de dependencias genéricos no detectan exfiltración de tokens OAuth, prompt injection oculto ni ampliación de alcance en extensiones de agentes, y ningún producto cubre esto.

Por qué ahora

El ecosistema de harnesses abiertos (Pi y similares) ha crecido de forma explosiva en los últimos ~12 meses junto con el acceso OAuth basado en suscripciones, lo que crea una nueva superficie de ataque (robo de tokens que lleva a baneos de cuentas) y una nueva clase de riesgo en la cadena de suministro de extensiones para la que aún nadie ha productizado defensas.

Foso · 5/10

Un registro de extensiones curado y auditado, junto con un feed de inteligencia de amenazas sobre patrones de ataque a extensiones de agentes que se actualiza continuamente, se acumula con la adopción; convertirse en la capa de confianza por defecto genera un efecto de lock-in de distribución similar al de los registros de paquetes.

En contra

Equipo rojo: El ecosistema de extensiones de harnesses abiertos tiene un riesgo real y distinto de cadena de suministro (robo de tokens OAuth, prompt injection en extensiones) que los escáneres genéricos y la idea de integridad de extensiones de IDE no cubren, y la ventana de amenaza es genuinamente nueva.
Qué la haría fracasar: Pi (u otro proveedor de harness) lanza sandboxing nativo y un registro oficial verificado, lo que colapsa la oportunidad de terceros antes de que el mercado sea lo bastante grande.

Empezar

Primeros tres pasos: Construir un analizador estático que escanee extensiones de Pi en busca de exfiltración de tokens, llamadas de red y patrones de prompt injection, y publicar un registro público con puntuación.
Lanzar una extensión de políticas de permisos para Pi que aplique un modo automático (bloqueo de comandos peligrosos, reglas de aprobación) para que los usuarios tengan seguridad de nivel Claude Code de forma nativa.
Publicar un paquete de 'perfil endurecido' (lanzador de sandbox + extensiones verificadas) y vender licencias de equipo con aplicación de políticas a nivel de organización.
Debate original: Goodbye Claude, hello Pi ↗ 605 puntos391 comentariosDe los comentariosArtículo enlazado

Traducido del inglés. Leer el original