✓ Survived Rank 1 of 16 proposedIndie Security Nov 8, 2026

Vetted extension registry and sandbox for agent harnesses

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.

Open the discussion ↗

A ready-to-paste brief for Claude Code, Cursor or any coding agent.

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.

Overall6.1/10

Pain6

Willingness to pay5

Timing8

Gap7

Moat5

Feasibility6

For

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.

What people said · 4

Returned to Claude Code because the open harness lacks a built-in auto mode blocking dangerous actions and has no vetting of popular third-party modules. Read the comment ↗
Refuses to trust their OAuth token to third-party extensions, citing recurring reports of users getting banned after token leaks and abuse. Read the comment ↗
Hand-built their own sandboxing layer on top of Pi just to reduce the risk of agents doing something destructive. Read the comment ↗
Manually configured pattern matching so destructive CLI calls and file edits require approval, replicating safety defaults the harness doesn't ship. Read the comment ↗

Paraphrased from the discussion. Follow the links for the original comments.

Competitors and gap

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)

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 · 5/10

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.

Against

Red team: The open-harness extension ecosystem has real, distinct supply-chain risk (OAuth token theft, prompt injection in extensions) that generic scanners and the IDE-extension integrity idea don't address, and the threat window is genuinely new.
What would kill it: Pi (or another harness vendor) ships native sandboxing and an official vetted registry, collapsing the third-party opportunity before the market is big enough.

Start

First three steps: Build a static analyzer that scans Pi extensions for token exfiltration, network calls, and prompt-injection patterns, and publish a scored public registry.
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.
Release a 'hardened profile' bundle (sandbox launcher + vetted extensions) and sell team seats with org-wide policy enforcement.
Source discussion: Goodbye Claude, hello Pi ↗ 605 points391 commentsFrom the commentsLinked article