✓ Überlebt Platz 1 von 16 VorschlägenIndie Sicherheit 8. Nov. 2026

Geprüfte Extension-Registry und Sandbox für Agent-Harnesses

Eine Sicherheitsschicht für Open-Source-Coding-Agent-Harnesses: geprüfte Extension-Registry, token-sichere Installationen und eine native Berechtigungs-Engine, die gefährliche Aktionen blockiert.

Diskussion öffnen ↗

Ein fertiges Briefing für Claude Code, Cursor oder jeden anderen Coding-Agenten (auf Englisch).

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.

Gesamt6.1/10

Schmerz6

Zahlungsbereitschaft5

Timing8

Marktlücke7

Burggraben5

Machbarkeit6

Dafür

Wer zahlt

Engineering Leads und Staff Developers in Unternehmen mit 20 bis 200 Mitarbeitenden, die offene Agent-Harnesses (Pi und Klone) einsetzen. Zahlung von 50 bis 200 $ pro Monat und Team aus dem Budget für Dev-Tools und Security; außerdem Prosumer für 10 bis 20 $ pro Monat.

Was die Leute sagten · 4

Ist zu Claude Code zurückgekehrt, weil das offene Harness keinen eingebauten Auto-Modus hat, der gefährliche Aktionen blockiert, und beliebte Drittanbieter-Module nicht geprüft werden. Kommentar lesen ↗
Vertraut das OAuth-Token nicht Drittanbieter-Extensions an und verweist auf wiederholte Berichte, dass Nutzer nach Token-Leaks und Missbrauch gesperrt wurden. Kommentar lesen ↗
Hat eine eigene Sandbox-Schicht auf Pi gebaut, um das Risiko destruktiver Aktionen durch Agents zu verringern. Kommentar lesen ↗
Hat Mustererkennung manuell konfiguriert, sodass destruktive CLI-Aufrufe und Dateiänderungen eine Freigabe benötigen. Damit werden Sicherheitsvorgaben nachgebaut, die das Harness nicht mitliefert. Kommentar lesen ↗

Sinngemäß aus der Diskussion wiedergegeben. Die Links führen zu den Originalkommentaren.

Wettbewerber und Lücke

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)

Offene Harnesses entwickeln ein schnell wachsendes Extension-Ökosystem ohne Supply-Chain-Prüfung und ohne native Sicherheitsvorgaben zur Laufzeit. Generische Dependency-Scanner prüfen nicht auf OAuth-Token-Exfiltration, versteckte Prompt Injection oder Scope Creep in Agent-Extensions, und kein Produkt schließt diese Lücke.

Warum jetzt

Das Open-Harness-Ökosystem (Pi und ähnliche) ist in den letzten etwa zwölf Monaten zusammen mit abonnementbasiertem OAuth-Zugriff stark gewachsen. Dadurch entstehen eine neue Angriffsfläche (Token-Diebstahl, der zu Account-Sperren führt) und eine neue Klasse von Extension-Supply-Chain-Risiken, für die noch niemand Schutzmechanismen als Produkt anbietet.

Burggraben · 5/10

Eine kuratierte, auditierte Extension-Registry zusammen mit einem laufend aktualisierten Threat-Intel-Feed zu Angriffsmustern bei Agent-Extensions wächst mit der Adoption. Wird das Produkt zur Standard-Vertrauensschicht, entsteht ein Lock-in ähnlich dem von Paket-Registries.

Dagegen

Red Team: Das Extension-Ökosystem offener Harnesses hat reale und eigenständige Supply-Chain-Risiken (OAuth-Token-Diebstahl, Prompt Injection in Extensions), die generische Scanner und die Idee zur Integritätsprüfung von IDE-Extensions nicht abdecken. Das Bedrohungsfenster ist tatsächlich neu.
Woran es scheitern würde: Pi oder ein anderer Harness-Anbieter liefert native Sandboxing-Funktionen und eine offizielle geprüfte Registry aus, bevor der Markt groß genug ist, und die Chance für Drittanbieter schrumpft.

Start

Die ersten drei Schritte: Einen statischen Analyzer bauen, der Pi-Extensions auf Token-Exfiltration, Netzwerkaufrufe und Prompt-Injection-Muster prüft, und eine öffentliche, bewertete Registry veröffentlichen.
Eine Berechtigungs-Richtlinien-Extension für Pi ausliefern, die einen Auto-Modus durchsetzt (Blockieren gefährlicher Befehle, Freigaberegeln), damit Nutzer Claude-Code-Niveau an Sicherheit nativ erhalten.
Ein Bundle „Hardened Profile“ (Sandbox-Launcher plus geprüfte Extensions) veröffentlichen und Team-Lizenzen mit unternehmensweit durchsetzbaren Richtlinien verkaufen.
Ursprüngliche Diskussion: Goodbye Claude, hello Pi ↗ 605 Punkte391 KommentareAus den KommentarenVerlinkter Artikel

Aus dem Englischen übersetzt. Original lesen