エージェントセキュリティはプロンプトエンジニアリングではなく、プラットフォームの問題である

自律型AIエージェントが本来の範囲を超えて動作するのは、悪意があるからではなく、ツールへのアクセス権や認証情報が徐々に蓄積されるためです。CNCFアンバサダーのWilliam Rizzo氏とFrancesco Beltramini氏は最近の分析で、この境界線の侵食はエージェントのロジックやガバナンスプロセスの失敗ではなく、構造的なインフラの問題であると主張しています。

何が起きたか

特定された核心的な問題は、エージェントの実効的な権限が、アクセス可能なツールによって定義され、それが時間とともに静かに拡大していく点にあります。デモ用にスコープ設定された認証情報が本番環境に残存したり、特定のデプロイをブロック解除するために追加された委任が永続的な許可になったりすることがあります。このドリフト（逸脱）は、権限が中央の意思決定ポイントなしに、段階的かつ局所的に付与されるために発生します。チームがエージェントが不正なアクションを実行できることに気づいた頃には、その機能はすでに数週間も存在している可能性が高いのです。

多くの組織は、ガバナンス委員会やより厳格なレビュープロセスを通じてこの問題を解決しようと試みます。しかし、これらの手法は人間の意思決定を管理するものであり、問題の根源は明示的な意思決定を経ずに到来する機能にあります。著者らは、プロセスだけでは、明確なイベントとして表面化しない変更の種類をレビューすることはできないと主張します。警戒心に頼る代わりに、誰かが監視しているかどうかに関係なく、境界線を自動的に強制する基盤システムが必要なのです。

仕組み

エージェント自身に指示やプロンプトを通じて制限を課すことは、構造的に欠陥があります。エージェントの出力は確率分布であり、通常は正しいアクションを選択しますが、新しい状況や敵対的な条件では失敗する可能性があります。さらに重要なのは、完全に準拠したエージェントであっても、ツールが許可するアクションはすべて実行してしまうという点です。エージェントが資金移動用のツールを保持していれば、指示で禁止されていても資金を移動できます。実際に実行するのは機能（Capability）であるため、機能は常に意図（Intent）を上回ります。

これに対応するため、著者らは最小権限の原則に基づく同心円状の構造を持つ「安全オペレーティングモデル」を提案し、エージェントを標準的なワークロードとして扱います。中心にあるのは「ID」であり、短命で証明付きの認証情報を使用することで、すべての下流チェックが何を実行しているのかを正確に把握できるようにします。第1のリングである「Reach（到達範囲）」では、サービスメッシュを使用してエージェントが接続できるサービスを強制し、グラフの静かな成長を防ぎます。第2のリングである「Capability（機能）」では、アドミッション（エージェントが保持できるツール）とエグゼキューション（それらを使って何ができるか）を分離し、呼び出しごとの認可を要求します。

このモデルの要は、エージェントが自身の設定を変更できないようにすることです。エージェントは、その権限を定義するポリシーやオブジェクトを編集する能力を拒否されなければなりません。境界線への変更は、人間またはパイプラインによって管理されるバージョン管理下の設定から行われる必要があります。これにより、規制対象のワークフローに対して決定的なバックボーンが作成されます。エージェントは推奨事項やドラフトを提供しますが、最終的なゲートと承認はプラットフォームが強制します。

主要な詳細

• エージェントリスクは、意図的な設計上の欠陥ではなく、蓄積されたツールアクセスに起因します。
• プロンプトベースの制約は、保証されたセキュリティ境界線ではなく、確率的な提案に過ぎません。
• IDは、プラットフォームレベルで短命かつ証明付きの認証情報によって検証されなければなりません。
• Reach（到達範囲）はサービスメッシュによって強制され、宣言されていないピアへの接続をブロックします。
• Capability（機能）は、ツールゲートウェイにおけるアドミッションコントロールと、呼び出しごとの認可に分割されます。
• エージェントは、自身の制限を定義する設定オブジェクトを変更する許可を絶対に持っていてはなりません。

なぜ重要なのか

ソフトウェアエンジニアや技術リードにとって、これはセキュリティ負担をアプリケーション層からインフラストラクチャ層へシフトさせることを意味します。つまり、エージェント型システムの構築には、ワークロードID、サービスメッシュ、Policy-as-Codeなどのクラウドネイティブなセキュリティプリミティブの統合が必要になります。チームは、エージェントを独自の安全性を管理するブラックボックスとして扱うことをやめ、エージェントが動作する境界線を明示的に宣言し、強制しなければなりません。

このアプローチは、監査可能および規制対象のワークフローの設計方法も変えます。エージェントの認知作業と結果の決定的な実行を分離することで、組織はコンプライアンスを維持できます。プラットフォームは、運用の副産物としてID、Reach、Capabilityチェックの証拠を記録し、規制当局に対して明確なトレーラビリティを提供します。これにより、エージェントは複雑な解釈タスクを処理しつつ、資金移動やデータ修正などの重要なアクションは不変かつレビュー済みのゲートを通過することが保証されます。

実施できること

• エージェントIDを、短命かつ証明付きの認証情報を持つ第一級のワークロードIDとして扱ってください。
• サービスメッシュポリシーを実装し、エージェントの接続性を宣言されたピアのみ制限してください。
• アドミッションコントローラーを使用して、エージェントが未承認のツールにバインドすることを防いでください。
• ツールゲートウェイで呼び出しごとの認可を強制し、各具体的なアクションを検証してください。
• エージェントIDが自身のポリシー設定を変更する許可を明示的に拒否されていることを確認してください。
• エージェントが提案やドラフトを作成し、最終的な実行は決定的なパイプラインに委ねるようなワークフローを設計してください。