✓ Sobreviveu 1º de 16 propostasIndie Segurança 8 de nov. de 2026

Registro de extensões verificadas e sandbox para agent harnesses

Uma camada de segurança para harnesses de agentes de programação de código aberto: registro de extensões verificadas, instalações seguras para tokens OAuth e um motor de permissões nativo que bloqueia ações perigosas.

Abrir a discussão ↗

Um briefing pronto para colar no Claude Code, Cursor ou qualquer agente de programação (em 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.

Geral6.1/10

Dor6

Disposição a pagar5

Momento8

Lacuna7

Fosso5

Viabilidade6

A favor

Quem paga

Engineering leads e staff devs em empresas de 20 a 200 pessoas que adotam harnesses de agentes abertos (Pi e clones), pagando de $50 a $200/mês por equipe a partir do orçamento de dev-tools/segurança; também usuários avançados individuais, a $10 a $20/mês.

O que as pessoas disseram · 4

Voltou para o Claude Code porque o harness aberto não tem um modo automático integrado que bloqueie ações perigosas e não há verificação dos módulos de terceiros mais populares. Ler o comentário ↗
Recusa confiar seu token OAuth a extensões de terceiros, citando relatos recorrentes de usuários banidos após vazamentos e abusos de token. Ler o comentário ↗
Construiu por conta própria uma camada de sandboxing sobre o Pi só para reduzir o risco de agentes fazerem algo destrutivo. Ler o comentário ↗
Configurou manualmente regras de correspondência de padrões para que chamadas destrutivas de CLI e edições de arquivo exigissem aprovação, replicando padrões de segurança que o harness não traz de fábrica. Ler o comentário ↗

Parafraseado da discussão. Siga os links para ler os comentários originais.

Concorrentes 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)

Os harnesses abertos estão acumulando um ecossistema de extensões que cresce rápido, sem nenhuma verificação de supply chain e sem padrões de segurança em tempo de execução. Scanners genéricos de dependências não verificam vazamento de tokens OAuth, prompt injection escondido ou escalada de escopo em extensões de agentes, e nenhum produto preenche essa lacuna.

Por que agora

O ecossistema de harnesses abertos (Pi e similares) cresceu muito nos últimos ~12 meses, junto com o acesso OAuth baseado em assinatura. Isso cria tanto uma nova superfície de ataque (roubo de tokens que leva ao banimento de contas) quanto uma nova classe de risco na supply chain de extensões, para a qual ninguém ainda transformou as defesas em produto.

Fosso · 5/10

Um registro curado e auditado de extensões, somado a um feed de threat intel continuamente atualizado sobre padrões de ataque a extensões de agentes, cresce com a adoção. Tornar-se a camada de confiança padrão cria um efeito de lock-in de distribuição semelhante ao dos registros de pacotes.

Contra

Time vermelho: O ecossistema de extensões de harnesses abertos tem riscos reais e específicos de supply chain (roubo de tokens OAuth, prompt injection em extensões) que scanners genéricos e a ideia de integridade de extensões de IDE não cobrem, e a janela de ameaça é de fato nova.
O que a faria fracassar: O Pi (ou outro fornecedor de harness) lança sandboxing nativo e um registro oficial verificado antes que o mercado seja grande o bastante, fechando a oportunidade para terceiros.

Começar

Primeiros três passos: Construir um analisador estático que varre extensões do Pi em busca de exfiltração de tokens, chamadas de rede e padrões de prompt injection, e publicar um registro público com pontuação.
Lançar uma extensão de política de permissões para o Pi que aplique um modo automático (bloqueio de comandos perigosos, regras de aprovação), para que os usuários tenham segurança de nível Claude Code de forma nativa.
Lançar um pacote de 'perfil endurecido' (launcher de sandbox + extensões verificadas) e vender assentos para equipes com aplicação de política em toda a organização.
Discussão original: Goodbye Claude, hello Pi ↗ 605 pontos391 comentáriosDos comentáriosArtigo vinculado

Traduzido do inglês. Ler o original