エージェントキーにはリスク予算が必要です

Shuriken の shuriken-skills リポジトリは、Claude Code、Codex CLI、GitHub Copilot CLI、Gemini CLI、Cursor、OpenCode、AGENTS.md 互換エージェント向けの指示をまとめたものです。¹ また、このリポジトリは、それらのエージェントを、ユーザーが権限を付与した場合にエージェントキーで市場データの読み取り、ウォレットの確認、見積もり依頼、取引の実行ができるプラットフォームへ案内します。²

重要なのは取引そのものではありません。重要なのは、その構造です。いまのエージェントには、現実の外部影響を生むツールにアクセスするための認証情報が必要になっています。エージェントキーは、通常の API キーのように振る舞うべきではありません。リスク予算として振る舞うべきです。

エージェントキーとは、境界を持つ権限オブジェクトです。エージェントに何ができるのか、何ができないのか、どれだけのリスクを生み得るのか、運用者がその行動をどう確認できるのか、そして必要なときにどれだけ素早く一時停止、ローテーション、失効できるのかを示すべきです。プロンプトの指示は助けになりますが、境界を担うのはサーバー側の制限です。

要約

MCP とポータブルなスキルにより、エージェントは外部システムへ接続しやすくなっています。³⁴ その移植性は、認証情報の重要性も高めます。Shuriken のドキュメントは、危険を伴うツールに対して正しい制御の形を示しています。つまり、エージェントキーを作成し、必要な権限だけを付与し、制限をサーバー側で強制し、活動を記録し、その連携が不要になったらキーを失効させる、という形です。²⁵⁶ 最近の最小権限に関する研究も、同じ方向を指しています。スキルは、特定のタスクに必要な最小範囲を超える行動を実行できるため、権限はパッケージ単位ではなく、タスクを意識したものにする必要があります。⁹

この教訓は金融以外にも当てはまります。送金する、コンテンツを公開する、インフラを変更する、顧客にメッセージを送る、個人情報に触れる。そうしたエージェントツールには、リスク予算を持つ範囲限定キーが必要です。その予算は、モデルより下、スキルファイルより下に置かれるべきです。エージェントが自信満々に要求しても、権限のない行動はサーバーが拒否しなければなりません。

重要なポイント

• エージェントツールの作り手へ: 認証情報は万能のベアラートークンではなく、機能ごとの予算として設計しましょう。
• セキュリティチームへ: 読み取り範囲と書き込み・実行範囲を分離し、実行側には支出、レート、対象オブジェクトの制限を置きましょう。
• プロダクトチームへ: 活動ログと失効操作は、奥まった設定ページではなく、主要 UI に表示しましょう。
• MCP の作り手へ: ツール配布と認証情報の権限は別の層として扱いましょう。スキルは教えるものです。キーは制限するものです。
• 運用者へ: まず読み取り専用で始め、連携経路を確認し、対応計画がある場合にだけ書き込み権限を追加しましょう。

スキルは指示を配り、キーは権限を配る

shuriken-skills リポジトリは、新しい配布パターンを示しています。1つのソースツリーに、スキルの Markdown、Claude と Codex 用のプラグインマニフェスト、Cursor プラグインマニフェスト、Gemini 拡張ファイル、OpenCode プラグイン、Rust クレート、AGENTS.md のフォールバック経路が含まれています。¹⁷

このパッケージ化が重要なのは、エージェントへの指示が複数のクライアントをまたいで移動するようになったからです。ベンダーは、同じ API と連携する方法を Codex、Claude Code、Cursor、Gemini、その他のツールに教えられます。MCP のドキュメントでは、エージェントスキルを、デプロイモデル、認証フロー、ツール設計パターンなどの設計判断を含むドメイン知識をコーディングアシスタントに与える、ポータブルな指示セットとして説明しています。⁴ 配布側については、エージェントスキルにはパッケージマネージャーが必要ですで書きました。セキュリティ側の問題は、それらのパッケージが実際の権限を求めた瞬間に始まります。

ポータブルな指示は、1つの問題を解き、別の問題を生みます。エージェントが正しい連携経路を学ぶ助けにはなります。しかし、その結果として行われる行動を安全にはしません。スキルは、最小権限を使うようモデルに伝えられます。プロンプトは「注意せよ」と言えます。README は推奨スコープを説明できます。けれども、モデルが認証済みリクエストを送ると決めた後では、それらの制御はリクエストを止められません。

この緊張関係は、MCP サーバーは新しい攻撃対象領域ですで扱った、より広い MCP の問題と一致します。ツールアクセスは、従来の承認習慣が追いつくより速く、行動可能な領域を広げます。エージェントスキルは指示の経路をポータブルにします。キーの仕組みは、権限の経路を狭く保たなければなりません。

だからこそ、認証情報には独自の設計が必要です。スキルファイルは指示の層にあります。エージェントキーは権限の層にあります。この2つを混ぜると、壊れやすいシステムになります。エージェントに何をすべきか教える同じテキストが、エージェントがやりすぎるのを止めようとするからです。

境界はサーバーに置くべきです。

Shuriken のパターンはリスク予算です

Shuriken の Agent Kit ドキュメントは、エージェントキーを、AI ツールができることを制御するオブジェクトとして説明しています。トークン価格の読み取りから取引実行までを対象にし、エージェントが行動を始める前に、サーバー側で制限を強制します。⁵ 権限ページでは6つの権限カテゴリを挙げ、付与された範囲外の呼び出しは認可エラーで失敗するとしています。⁶

この捉え方は、公開エージェントデモでよくある誤りも避けています。つまり、公開されたコード、見える指示、読めるプラグインマニフェストを境界として扱う誤りです。公開性はレビューを助けますが、オープンソースはセキュリティ境界ではありません。境界は、権限のない行動が失敗する場所にあります。

このパターンには5つの要素があります。

これは、高リスクなエージェントツールに適した形です。この設計は、モデルが賢くなることに依存しません。モデルが間違うかもしれない、過信するかもしれない、入力により侵害されるかもしれない、単に悪い指示を受けるかもしれない、という前提に立ちます。それでもサーバーはキーの制限を強制します。

私なら、ドメインではなく制御パターンをコピーします。デプロイキー、公開キー、顧客メッセージ用キー、Stripe 返金キー、取引用キーのいずれにも、同じ問いが必要です。このキーは、人間が気づくまでに最大でどれだけの損害を生み得るのか。

サーバー側の制限はプロンプトの約束に勝る

OpenAI の Agents SDK ドキュメントは、ガードレールを、入力ガードレールや出力ガードレールのトリップワイヤーを含む、エージェントの周囲で実行できるチェックとして位置づけています。⁸ ガードレールは、モデル実行の前後でリスクを捕まえられるため役に立ちます。それでも、認証情報の権限とは別の層にあります。

出力ガードレールは、危険な提案行動に警告を出せます。サーバー側のキー制限は、ガードレールが見逃しても、その行動を拒否できます。行動がテキストを超えると、この違いは重要になります。

投稿を公開する、メールを送る、DNS レコードを変更する、pull request をマージする、取引を実行する。そうしたツールを考えてみてください。プロンプトルールは「先に確認せよ」と言えます。ガードレールは高リスクなテキストを探せます。サーバー側のキーは、実際の制限を強制できます。

プロンプトルールは、静かに失敗することがあります。キーレベルの境界は、観測可能な拒否を作ります。その拒否は証拠になります。エージェントは範囲を超えようとした。サーバーは拒否した。運用者は失敗したリクエストを確認し、連携に新しいキーが必要なのか、より狭い手順が必要なのか、人間の承認ステップが必要なのかを判断できます。

これは、証拠ゲートの考え方と同じです。信頼は自信ではなく、観測可能な証拠から生まれるべきです。「制限内に留まりました」という最終回答より、どの制限が作動したかを示すサーバーログのほうが重要です。

また、最終回答はレビュー用の資料に近づきます。レビュー資料こそ新しい最終回答ですでは、本格的なエージェント作業には証拠となる成果物が必要だと論じました。認証情報の拒否、活動ログ、範囲限定キーの変更は、そのセキュリティ版です。

エージェント認証情報に最低限必要な形

外部世界に影響を与えられるエージェント認証情報には、6つの性質が必要です。

Shuriken のスキルも、連携の言葉で同じ中核を述べています。連携ごとに1つのキーを作り、最小範囲だけを付与し、キーを秘密に保ち、侵害が疑われたらローテーションし、不要になった連携は失効させる、ということです。⁷ スコープ設定スキルも、読み取り範囲と取引範囲を分け、「念のため」に広いキーを作ることへ警告しています。⁷

研究側の語彙も、このプロダクトパターンに追いつきつつあります。SkillScope 論文は、過剰権限をタスク依存のものとして説明しています。同じスキルの行動でも、あるユーザー要求には妥当で、別の要求には過剰になり得るということです。⁹ 著者らは、検証済みの過剰権限動作を持つ 7,039 個のスキルを報告し、自分たちのフレームワークにより権限を制限した結果、発火した過剰権限行動インスタンスが 88.56% 減少したとしています。⁹ その正確な仕組みをコピーする必要はありません。受け取るべきプロダクト上の教訓は、エージェント認証情報は、そのツールが想像できる最大の仕事ではなく、現在の仕事を反映すべきだということです。

この考え方は、通常のエージェントプロダクト設計になるべきです。バックエンドサービスが狭いコードパスを所有していた時代には、広い API キーにも意味がありました。エージェントは、狭い1本のコードパスのようには振る舞いません。計画し、再試行し、ツールを組み合わせ、失敗を要約し、補助スクリプトを呼び出し、外部入力に反応します。認証情報は、通常のサービストークンよりも大きな行動のばらつきを前提にすべきです。

そのばらつきがあるからこそ、エージェントのコード検索にはトークン予算の問題がありますは、認証情報の記事でも重要になります。エージェントは、不完全な文脈で判断することがよくあります。狭いキーは、コンテキストウィンドウが危険な細部を見落としたとき、システムに二度目の防御機会を与えます。

コピーしてはいけないもの

マーケティング上の楽観はコピーしないでください。

Shuriken の公開ドキュメントは、ユーザーが離席している間にエージェントが行動し、機会を捉えることについて強い表現を使っています。² その言い方は、彼らのプロダクトには合うのかもしれません。しかし、外部影響を生むエージェントツールの標準的な安全姿勢にするべきではありません。

高リスクな行動において、「離席中」は、より狭い運用上の意味を持つ必要があります。

• ユーザーが離席中でも、エージェントは情報を集められる。
• ユーザーが離席中でも、エージェントは行動の下書きを準備できる。
• エージェントが実行できるのは、小さく明示的で、サーバー側で強制される予算の内側だけである。
• 運用者は、後からすべての行動を確認できる。
• 運用者は、キーをただちに一時停止または失効できる。

これが、自律性と責任放棄の違いです。ユーザーは行動を委任できます。しかし、システムは説明責任を委任できません。

同じ注意は、スキルやプラグインマニフェストにも当てはまります。リポジトリがすべてのエージェントクライアントをサポートしていても、保守的な初期設定に値します。私が確認した .codex-plugin/plugin.json は、インターフェースメタデータに読み取り機能を記載していました。一方でドキュメントは、取引には明示的に有効化された権限と制限が必要だと説明しています。⁷ これは正しい方向です。配布は広くても、権限は狭く始められます。

判断ルール

新しいエージェント連携が認証情報を求めたら、発行する前にキーを分類してください。

この表は、境界をモデル自身が持っているかのように装うことなく、エージェントに使える経路を与えます。手順は改善され続けてよいものです。キーは、その改善が無制限の権限に変わることを防ぎます。エージェント実行トレースはランタイム契約ですも、監査の側面から同じことを述べています。何が起きたかをシステムが示せないなら、エージェントが意図された契約の内側で行動したとは証明できません。

同じ分離については、エージェントのサンドボックスセキュリティは提案にすぎませんでも書きました。モデルは、付与された権限の完全な内側で動いていても、安全でない結果を生み得ます。権限と安全性は同じものではないため、エージェントキーにはリスク予算が必要です。

FAQ

エージェントキーは、名前を変えただけの API キーですか？

いいえ。通常の API キーは、サービスへの広いアクセスを許可することがよくあります。エージェントキーは、1つの連携に対して境界のある機能セットを付与するべきです。サーバー側の制限、活動ログ、そしてユーザーのメインセッションに影響しない失効も必要です。

なぜサーバー側の強制が重要なのですか？

サーバーは最終リクエストを見ます。モデルの指示、スキルファイル、ガードレールは、危険な行動を見逃すことがあります。サーバー側の権限チェックなら、キーに必要な範囲がない場合や、設定済みの制限を超える場合にリクエストを拒否できます。⁶

すべてのエージェントは読み取り専用から始めるべきですか？

はい。ツールが意味のある外部影響を持つなら、読み取り専用アクセスから始めるべきです。連携経路を確認し、どのログ、制限、承認、ロールバック手順があるのかをチームが把握してから、書き込みまたは実行権限を追加してください。

MCP はエージェント認証情報をより危険にしますか？

MCP により、外部ツールを複数のクライアントから接続しやすくなります。³ その便利さは、認証情報設計の重要性を高めます。ポータブルなツールアクセスには、より広い信頼ではなく、狭いキーを組み合わせるべきです。

Shuriken から何をコピーすべきですか？

指示の配布とサーバー側の権限を分ける設計をコピーしてください。ポータブルなスキルは連携方法を教えられます。一方で、範囲限定キー、制限、ログ、失効が行動を制約します。プロダクト、法務、運用上の制御が正当化しない限り、ドメイン固有の取引動作をコピーしてはいけません。

参照