TL;DR

• AI エージェントが「データアクセス」「信頼できないコンテンツへのアクセス」「通信能力」の 3 つを同時に持つと本質的なリスクが生じる（リーガルトライフェクタ）。この 3 要素を分離・最小化することが権限設計の出発点になる
• CVSS スコアが最高値（10）でも、利用コンテキスト（ローカル実行か公開サーバーかなど）によっては実害がほぼゼロのケースがある。スコア単独での優先度付けは危険であり、コンテキストを組み込んだ評価フローが必要
• AI が自動生成した低品質なセキュリティ報告（スロップ）が大規模 OSS に殺到しており、5 ヶ月で 1,142 件・1 日平均 16.6 件というペースは Linux カーネルの約 2 倍に相当する。トリアージ自動化なしにメンテナンスは成立しない
• プロンプトインジェクション攻撃への完全な解決策は 2026 年 4 月時点でも未解決。現状のベストプラクティスは「信頼できないコンテンツのマーキング」と「最新フロントエンドモデルの利用」によるディフェンス・イン・デプスにとどまる
• 大規模 AI エージェント OSS のガバナンスは、単一企業依存を避ける非営利財団モデルへの移行が現実的な選択肢として浮上している。スポンサー構造と中立性のバランスは設計上の重要課題となっている

対象読者与前提

対象：

• AI エージェントを業務・プロダクトに組み込んでいる、または設計を検討しているバックエンド・インフラ・セキュリティエンジニア（中〜上級）
• 脆弱性トリアージ・権限設計・サンドボックス構成など、実装レベルの意思決定を近い将来に行う必要がある立場の読者
• 大規模 OSS を依存ライブラリとして採用・評価する立場にあるエンジニア・アーキテクト

前提：

• AI エージェントの基本的な動作モデル（LLM + ツール呼び出し）を理解していること
• CVSS スコアなど脆弱性評価の基礎概念に触れたことがあること
• OSS の依存関係管理やセキュリティ勧告の受信・対応フローを経験していること

扱わないこと：

• OpenClaw の個別 API・設定ファイルの具体的な実装手順
• 本記事で言及する講演者（Peter Steinberger 氏）の個人経歴・キャリアストーリー
• 財団の法的設立状況や具体的なスポンサー契約の詳細（講演時点では設立進行中）
• 大学・企業によるリスク評価レポートの固有名称（本記事の情報源では特定されていない）

本記事は、AI Engineer チャンネルが公開した講演「State of the Claw — Peter Steinberger」（2026 年 4 月 17 日）のリテラチャノートを一次情報源とした技術的考察です。引用は日本語の翻訳・要約であり、英語原文の逐語引用ではありません。各数値・発言にはタイムスタンプを付記します。

背景：5 ヶ月・1,142 件・1 日 16.6 件という実証データ

AI エージェントの実運用が本格化した 2026 年春、その最前線にいる OSS プロジェクトが 5 ヶ月間に直面した数字が、設計課題を考える上での有力な出発点になる。

Steinberger 氏の講演 [01:21] によると、同氏が作成した OpenClaw は設立から 5 ヶ月で約 30,000 コミット、2,000 人のコントリビューター、30,000 件のプルリクエストを達成した（「GitHub 史上最速クラスの成長」は講演者本人の主張であり、GitHub 公式データによる第三者検証はない）。

この成長が同時に引き寄せたのが、セキュリティ勧告の洪水だった。

講演 [04:58] では以下のデータが示された：

しかし重要なのはこの数字の内訳だ。99% が「Critical」評価されているにもかかわらず、実際にインシデントに発展したケースはほとんどない。この乖離を生んでいる構造的な要因が、以下の 5 つのフレームに集約される。

フレーム 1：リーガルトライフェクタ——権限設計の出発点

概念の定義

Steinberger 氏は講演 [14:03] で次のように述べた（日本語要約）：

「あなたのデータにアクセスでき、信頼できないコンテンツにアクセスでき、そして通信能力を持つエージェントシステムは、潜在的にリスクがあります。これは OpenClaw に特有のものではありません。」

この「3 要素の同時保持」を本記事ではリーガルトライフェクタと呼ぶ（講演内での命名であり、セキュリティ業界の標準用語として普及しているかは不明）。

設計への翻訳

この概念が実装上の意思決定に直結する。

チェック項目（設計時）：

• データアクセス範囲の確認— エージェントがアクセスできるファイルシステム・データベース・API は最小限に絞られているか。不要な読み取り権限・書き込み権限が付与されていないか -
• 信頼できないコンテンツの入力経路の棚卸し— 外部 URL のスクレイピング・ユーザーフリーテキスト入力・メール本文の解析など、エージェントが処理するコンテンツのうち「信頼できないもの」はどれか -
• 通信能力の制限— エージェントが外部に送信できる宛先・プロトコルを許可リストで管理しているか。不要なアウトバウンド通信をブロックしているか

判断基準： 3 要素すべてを同時に持たせる設計は、最後の手段として扱う。可能であれば「信頼できないコンテンツの処理」と「通信能力の行使」を異なるエージェントまたは実行ステップに分離し、権限の最小化を徹底する。

正如演讲 [11:15] 中所述，尽管存在诸如“作为个人代理使用”和“禁止添加到群组聊天”等官方指南，但仍有报告称在忽略这些设置的情况下进行了风险评估。明确说明使用场景对于规范文档和安全策略来说至关重要，从风险因子角度来看也是如此。

框架 2：CVSS 分数与背景的差距——优先级逻辑的实现

分数所示与未所示的内容

Steinberger 先生在演讲 [07:54] 中举了一个 CVSS 分数为 10（最高值）的漏洞具体例子：“尚未发布的 iPhone 应用程序的可读权限可被写入”。

他说道（日语摘要）："实际上，这种情况很少会导致事件发生。因为典型的用例是安装在自己的机器上。"

CVSS 分数显示漏洞的通用严重程度，但不显示特定使用环境中的实际风险。这种差异导致了"99% Critical，但实际危害几乎为零"的情况。

结合背景进行评估的流程

以下是以 CVSS 分数为基准线并结合背景进行修正的评估流程示例（这是从证据包得出的设计指南，并非 OpenClaw 官方文档）。

from dataclasses import dataclass
from enum import Enum
class Priority(Enum):
...

实现要点：

• is_local_only 和 is_publicly_exposed 的两个轴是背景修正的核心 - affected_feature_in_use 需要跟踪实际功能使用情况（可以从功能标志或构建设置中导出）- exploit_available 可以通过将自动检查集成到 CI 中保持新鲜度

框架 3：处理斜率型安全报告——三分类自动化设计

"Slop"是什么

在演讲 [05:18] 中定义的"Slop（斜率）"是指由 AI 自动生成的、质量低或误导性的信息、代码或漏洞报告。

Steinberger 先生指出，1,142 个建议的大部分属于这种 Slop（演讲中未提供 Slop 比例的定量值），99% 被评估为"Critical"的背景与 Slop 的特性有关。AI 自动搜索旨在发现大量高分数漏洞，但生成大量不考虑实际使用背景的报告。

从开源维护者的角度来看，这意味着问题质量的转变。不是"漏洞数量增加"，而是"区分有意义漏洞和噪音的成本急剧增加"的结构。

三分类自动化设计方针

OpenClaw 实际上实施了什么样的三分类在演讲中未详细说明，但从 469 个公开处理、60% 关闭的处理率可以反向推导出设计问题。

# 安全建议三分类自动化设计检查清单（示例）
triage_automation:
initial_filter:
...

设计注意事项： 自动关闭可以降低维护者的负担，但存在错误拒绝有意义报告的风险。重要的是与定期自动关闭精度审查一起设计可以提出申诉的流程。

框架 4：提示注入的现状——纵深防御的实现

"没有完全解决方案"的前提

Steinberger 先生在演讲 [36:03] 中明确说明（日语摘要）："对于提示注入还没有找到完全解决方案。"

这是演讲者个人的主张，不能断定为整个行业的共识，但在 2026 年 4 月时也没有公开的提示注入对策有"银弹"。

基于这个前提，设计方向从"完全防止注入"转向"即使注入成功也最小化损害"。

当前最佳实践及其局限性

演讲 [36:03] 中展示的最佳实践有两点：

• 不可靠内容的标记 - 为代理处理的內容分配"可靠（trusted）"和"不可靠（untrusted）"标签，并在构建 LLM 提示时明确区分 - 使用最新的前端模型 - 最新模型在抗注入攻击方面改善的情况较多

基于这些的实施示例（伪代码）：

class PromptBuilder:
"""
构建带有明确信任级别的提示。
...

纵深防御的额外层：

框架 5：开源治理的可持续性——非营利基金会模型的选择

"不要将自己制作的东西交给自己的公司"的决定

Steinberger 氏は講演 [16:57] でこう述べた（日本語要約）：「このプロジェクトが成功するためには、一企業のものであることはできません。そのため、私は OpenClaw 財団でスイスのようなものを作っています。」

参考モデルとして挙げたのが Ghost（オープンソースのブログプラットフォーム）の非営利財団構造だ。Nvidia・Microsoftなどの企業から支援を受けながら、単一企業（OpenAI を含む）への依存を避ける中立的な組織を構築中とのこと（財団の法的設立状況・スポンサー企業との契約詳細は講演時点では確認できない）。

依存ライブラリ選定時のガバナンス評価チェックリスト

大規模 AI エージェント OSS を依存ライブラリとして採用する際、ガバナンス構造は長期リスクの重要な評価軸になる。

oss_governance_checklist:
ownership:
- 単一企業が実質的にコントロールしているか？
...

検証・落とし穴

落とし穴 1：「Critical なら緊急対応」反射の罠

CVSS スコアが高い勧告を受け取った瞬間に緊急対応チームを召集する運用は、スロップが大量流入する環境では持続不可能になる。99% Critical という数字は「すべてが深刻」ではなく「スコアリングアルゴリズムがコンテキストを無視している」ことを示す。

対処： フレーム 2 で示したコンテキスト評価フローを自動化し、「CVSS スコアは入力の一つ」として扱う運用ルールを先に整備する。

落とし穴 2：推奨設定を無視したセキュリティ評価の参照

講演 [11:15] によると、大学・一部企業が公式のセキュリティガイドライン（個人エージェントとして利用・グループチャットへの追加禁止等）を意図的に無視した設定でテストを行い、リスクを誇張したレポートを公開している事例が報告されている（当該レポートの固有名称は本記事では特定できない）。

対処： 外部のセキュリティ評価レポートを参照する際は、どの設定・どの利用シナリオでテストされているかを必ず確認する。公式の推奨利用方法との乖離が大きいほど、そのレポートの実用的リスク評価としての信頼性は低下する。

落とし穴 3：プロンプトインジェクション対策の過信

「コンテンツマーキングを実装した」「最新モデルを使っている」という状態を「対策済み」として認識するのは危険だ。フレーム 4 で示したとおり、これらは攻撃成功の確率を下げるものであり、攻撃を完全に防ぐものではない。

対処： プロンプトインジェクション対策をフェーズで設計する。Phase 1（コンテンツマーキング・最新モデル）→ Phase 2（権限最小化によるダメージ局所化）→ Phase 3（ロギング・Human-in-the-loop による検知と復旧）という多層構造で考える。

落とし穴 4：OSS のスター数・コミット数だけでの依存可否判断

30,000 コミット・2,000 コントリビューターという数字は成長の証であると同時に、メンテナンスキャパシティを超えている可能性のサインでもある。講演 [15:02] によると、プロジェクト規模がメンテナーの処理能力を大幅に超えており、スロップがその負担をさらに悪化させている。

対処： 依存ライブラリの評価では「スター数・コミット数」より「コアメンテナーの数」「Issue のクローズ率と速度」「セキュリティ勧告の対応履歴」を優先指標として確認する。

まとめと次に試すこと

各フレームに対応する、明日から実施できる具体的なアクションを列挙する。

フレーム 1（リーガルトライフェクタ）

• 現在のエージェント実装を「データアクセス・信頼できないコンテンツ・通信能力」の 3 軸でマッピングする
• 3 要素すべてを同時に持つコンポーネントを特定し、最小権限原則での再設計を検討する
• 利用シナリオ（個人マシン・チーム共有・公開サーバー等）をセキュリティポリシーに明文化する

フレーム 2（CVSS スコアとコンテキストのギャップ）

• 既存の脆弱性対応フローに「利用コンテキスト評価」ステップを追加する

is_local_only

/is_publicly_exposed

/exploit_available

の 3 要素を評価シートに組み込む - CVSS スコアだけで優先度が付いている既存の未対応 Issue を棚卸しする

フレーム 3（スロップトリアージ）

• セキュリティ勧告の受付テンプレートに「再現手順・利用コンテキスト・影響バージョン」を必須フィールドとして追加する
• 「再現手順なし」「既知 Issue と類似」を自動ラベルする CI/CD ステップを導入する
• 過去の勧告の「クローズ理由」を分類・集計し、スロップの傾向を把握する

フレーム 4（プロンプトインジェクション）

• エージェントへの入力を
  trusted

/untrusted

に分類するプロセスを文書化する - 外部コンテンツを処理するエージェントのプロンプトテンプレートに信頼レベルの明示を追加する

• エージェントのツール呼び出し（特に書き込み・送信系）のログ取得を実装・確認する

フレーム 5（OSS ガバナンス）

• 依存している主要 AI 関連 OSS のガバナンス構造（コアメンテナー数・バックアップ体制・セキュリティ勧告対応履歴）を棚卸しする
• ガバナンスリスクが高いと判断したライブラリについて、代替手段または内製化の検討を始める
• 自プロジェクトが OSS を公開する場合は、貢献ガイドライン（AI 生成 PR への対応方針を含む）を整備する

出典

**一次情報（講演動画）：**Peter Steinberger, "State of the Claw", AI Engineer チャンネル, 2026 년 4 월 17 일 - URL:

• 타임스탬프 참조: [01:21] 급격한 성장의 수치 / [04:58] 보안 경고 통계 / [05:18] 슬롭의 정의 / [07:54] CVSS 점수와 컨텍스트 / [11:15] 권장 설정 무시 / [14:03] 리거트라이팩터 / [15:02] 유지보수자 고갈 / [16:57] 재단 설립 / [36:03] 프롬프트 인젝션 현재 위치

• 본記事의注記： 인용은 일본어 번역 및 요약이며, 영어 원문의 단어별 인용이 아닙니다. Steinberger氏の주관적 주장（"GitHub 역사상 가장 빠른 성장", "슬롭이 대부분", "완전한 해결책 없음" 등）과 객관적 데이터를 구분하여 서술합니다. Mermaid 도식 및 코드 예시는 Evidence Pack 에서 유도된 설계 지침이며, OpenClaw 의 공식 문서가 아닙니다.