✓ Retenue 1e sur 16 proposéesIndie Sécurité 8 nov. 2026

Registre d'extensions vérifiées et sandbox pour les harnais d'agents

Une couche de sécurité pour les harnais open source de coding agents : registre d'extensions vérifiées, installations sans fuite de token OAuth, et moteur de permissions natif qui bloque les actions dangereuses.

Ouvrir la discussion ↗

Un brief prêt à coller dans Claude Code, Cursor ou tout agent de code (en anglais).

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.

Global6.1/10

Douleur6

Volonté de payer5

Timing8

Manque7

Avantage défensif5

Faisabilité6

Pour

Qui paie

Engineering leads et staff devs dans des entreprises de 20 à 200 personnes qui adoptent des harnais d'agents open source (Pi et clones), à 50–200 $/mois par équipe sur le budget dev-tools/sécurité ; aussi les prosumers à 10–20 $/mois.

Ce que les gens ont dit · 4

Est revenu à Claude Code parce que le harnais open source ne dispose pas d'un mode automatique intégré qui bloque les actions dangereuses et ne vérifie pas les modules tiers populaires. Lire le commentaire ↗
Refuse de confier son token OAuth à des extensions tierces, en citant des signalements répétés d'utilisateurs bannis après des fuites de tokens et des abus. Lire le commentaire ↗
A développé à la main sa propre couche de sandboxing par-dessus Pi, simplement pour réduire le risque que les agents commettent une action destructrice. Lire le commentaire ↗
A configuré manuellement une détection de motifs pour que les appels CLI destructeurs et les modifications de fichiers exigent une approbation, reproduisant des garde-fous que le harnais ne fournit pas. Lire le commentaire ↗

Reformulé à partir de la discussion. Suivez les liens pour lire les commentaires d'origine.

Concurrents et manque

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)

Les harnais open source accumulent un écosystème d'extensions en forte croissance sans aucune vérification de la chaîne d'approvisionnement ni de garde-fous d'exécution natifs ; les scanners de dépendances génériques ne détectent pas l'exfiltration de tokens OAuth, l'injection de prompt cachée ou l'élargissement des permissions dans les extensions d'agents, et aucun produit ne comble ce vide.

Pourquoi maintenant

L'écosystème des harnais open source (Pi et similaires) a explosé au cours des 12 derniers mois, en parallèle de l'accès OAuth lié aux abonnements. Cela crée à la fois une nouvelle surface d'attaque (vol de tokens menant à des bannissements de comptes) et une nouvelle classe de risques sur la chaîne d'approvisionnement des extensions, pour laquelle personne n'a encore productisé de défenses.

Avantage défensif · 5/10

Un registre d'extensions curé et audité, couplé à un flux de renseignements sur les menaces continuellement mis à jour sur les schémas d'attaque contre les extensions d'agents, gagne en valeur avec l'adoption ; devenir la couche de confiance par défaut crée un verrouillage de distribution comparable à celui des registres de paquets.

Contre

Équipe rouge: L'écosystème d'extensions des harnais open source présente un risque réel et distinct sur la chaîne d'approvisionnement (vol de tokens OAuth, injection de prompt dans les extensions) que les scanners génériques et l'idée d'intégrité des extensions IDE ne couvrent pas, et la fenêtre de menace est véritablement nouvelle.
Ce qui la ferait échouer: Pi (ou un autre éditeur de harnais) livre un sandboxing natif et un registre officiel vérifié, ce qui réduit l'opportunité tierce avant que le marché ne soit assez grand.

Démarrer

Les trois premières étapes: Construire un analyseur statique qui examine les extensions Pi à la recherche d'exfiltration de tokens, d'appels réseau et de motifs d'injection de prompt, et publier un registre public noté.
Livrer une extension de politique de permissions pour Pi qui applique un mode automatique (blocage des commandes dangereuses, règles d'approbation) pour offrir aux utilisateurs une sécurité de niveau Claude Code en natif.
Publier un bundle « profil durci » (lanceur sandbox + extensions vérifiées) et vendre des sièges d'équipe avec application de politiques à l'échelle de l'organisation.
Discussion d'origine: Goodbye Claude, hello Pi ↗ 605 points391 commentairesDes commentairesArticle lié

Traduit de l'anglais. Lire l'original