✓ 生き残り提案 16 件中 1 位インディーセキュリティ 2026年11月8日

エージェント・ハーネス向けの審査済み拡張レジストリとサンドボックス

オープンソースのコーディングエージェント・ハーネス向けのセキュリティレイヤーです。審査済みの拡張レジストリ、OAuthトークンを安全に扱うインストール、危険な操作をブロックするネイティブな権限エンジンを提供します。

Claude Code や Cursor などのコーディングエージェントにそのまま貼れる概要（英語）です。

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.

総合6.1/10

課題の深刻さ6

支払い意欲5

タイミング8

市場の空白7

参入障壁5

実現性6

賛成

誰が払うか

20〜200名規模の企業でオープンなエージェント・ハーネス（Piとその派生）を導入しているエンジニアリングリーダーやスタッフエンジニア。開発ツール／セキュリティ予算から、チーム単位で月額$50〜200の支払いを想定しています。個人の上級ユーザー（プロスーマー）は月額$10〜20です。

議論での声 · 4

オープンなハーネスには危険な操作をブロックする自動モードが組み込まれておらず、人気のサードパーティ製モジュールも検証されていないため、Claude Codeに戻った。コメントを読む ↗
OAuthトークンが漏えいしてユーザーがBANされた事例が繰り返し報告されているため、サードパーティ拡張にトークンを預けることを拒否している。コメントを読む ↗
エージェントが破壊的な操作をしないよう、Piの上に独自のサンドボックス層を自作した。コメントを読む ↗
ハーネスが標準で備えていない安全対策を再現するため、破壊的なCLIコマンドやファイル編集に承認を必要とするパターンマッチングを手動で設定した。コメントを読む ↗

議論の内容を要約したものです。元のコメントはリンクからどうぞ。

競合と空白

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)

オープンなハーネスの拡張エコシステムは急速に広がっていますが、サプライチェーンの審査がなく、ランタイムの安全対策も標準では用意されていません。一般的な依存関係スキャナーは、OAuthトークンの流出、隠れたプロンプトインジェクション、エージェント拡張の権限の過剰拡大（スコープクリープ）を検査できず、この領域を埋める製品は存在しません。

なぜ今か

Piなどのオープンなハーネスは過去約12か月で急拡大し、サブスクリプションベースのOAuthアクセスも普及しました。その結果、トークン窃取によるアカウント停止という新たな攻撃面と、まだ対策製品が存在しないエージェント拡張のサプライチェーンリスクが同時に生まれています。

参入障壁 · 5/10

審査・監査済みの拡張レジストリと、エージェント拡張の攻撃パターンを継続的に更新する脅威インテルフィードは、採用が増えるほど価値が蓄積します。デフォルトの信頼レイヤーになれば、パッケージレジストリに近い形で強い囲い込みが生まれます。

反対

レッドチーム: オープンなハーネスの拡張エコシステムには、OAuthトークン窃取や拡張内のプロンプトインジェクションといった固有のサプライチェーンリスクがあり、一般的なスキャナーやIDE拡張の整合性チェックのアイデアでは対応できません。また、この脅威の時間枠は実際に新しいものです。
失敗するとしたら: Pi（または他のハーネスベンダー）がネイティブのサンドボックス機能と公式の審査済みレジストリを提供し、市場が十分に大きくなる前にサードパーティの機会が消滅するリスクです。

始め方

最初の3ステップ: Pi拡張をスキャンし、トークンの流出、ネットワーク呼び出し、プロンプトインジェクションのパターンを検出する静的解析ツールを作り、スコア付きの公開レジストリとして公開する。
危険なコマンドのブロックや承認ルールを強制する自動モードをPi向けの権限ポリシー拡張として提供し、ユーザーがClaude Code並みの安全性をネイティブに得られるようにする。
サンドボックス起動ツールと審査済み拡張をまとめた「ハードニング済みプロファイル」を公開し、組織全体でポリシーを強制できるチーム向けシートを販売する。
元の議論: Goodbye Claude, hello Pi ↗ 605 ポイントコメント 391 件コメントからリンク先の記事

英語からの翻訳です。原文を読む