エンタープライズAIエージェントのためのガードレール
AIのガードレールに関するアドバイスの多くは、セールストークのように聞こえます。派手な図解やチェックリストに終始しがちです。
本番環境における真の安全性は、それほど華やかなものではありません。それは、LLMが登場するずっと前から存在していた要素に基づいています。
私はFortune 100企業向けにAIエージェントを構築することに2年間費やしました。これらのエージェントは、CI/CDの失敗、Kubernetesのインシデント、およびインフラストラクチャのドキュメントを処理します。
以下に、エージェントの安全性を確保するために私たちが使用しているレイヤードスタックを紹介します。
エージェント境界におけるアイデンティティ。すべてのエージェントはワークロードアイデンティティを使用します。共有の認証情報は決して使用しません。IAMのスコープがセキュリティの限界（天井）となります。エージェントにデータベースへのアクセスが必要ない場合、IAMロールにその権限を与えてはいけません。これが最も重要なコントロールです。
ツールの許可リスト（Allow-lists）。どのツールをエージェントが利用できるかはプラットフォームが決定します。コード検索エージェントにメールツールを持たせるべきではありません。これには静的な設定を使用します。動的なツール登録は決して行いません。
ネットワークのエグレス制御。エージェントは許可されたエンドポイントにのみアクセスできます。DNSフィルタリングとエグレスプロキシを使用します。これにより、モデルのハルシネーションが誤ったURLにアクセスすることを防ぎます。
シークレットの分離。エージェントは生のシークレットを一切目にすることはありません。ツール呼び出し時に注入される短寿命のセッショントークンを使用します。プロンプトにシークレットを絶対に入れないでください。プロンプト内のものはすべてログに記録されたり、再再生（リプレイ）されたりする可能性があります。
完全な監査証跡。すべてのモデル呼び出しとツール呼び出しをログに記録する必要があります。これには、入力、出力、ツールの引数、およびユーザーのアイデンティティが含まれます。インシデント発生時に何が問題だったのかを理解するために、これが必要です。
人間による承認。記録システム（System of Record）を変更するいかなるアクションに対しても、プラットフォームは一時停止しなければなりません。人間がそのアクションを承認する必要があります。これがセーフティネットとなります。
次のような一般的な間違いを避けてください：
プロンプトレベルの指示。「決してXをしないでください」とモデルに指示することは、セキュリティではありません。ユーザーはモデルを欺くことができます。コントロールをIAMまたはツールレイヤーに移動してください。
汎用的なPIIフィルタ。これらはエラー率が高いです。IAMを通じてデータアクセスを制限し、エージェントが機密情報を見ることがないようにする方が優れています。
ガードレールモデル。1つ目のモデルを評価するために2つ目のLLMを使用すると、レイテンシが増加します。それは真のセキュリティコントロールではなく、単なるモデルアンサンブルに過ぎません。
私が身をもって学んだ教訓：
プロンプトよりも先にIAMを修正する。IAMロールを厳格化すべき時に、プロンプトのチューニングに時間を浪費してしまいました。コントロールは可能な限りスタックの下層に移動させてください。
監査証跡を過剰なほど充実させてください。プロンプトと回答だけを記録するのでは不十分です。中間的なツールの呼び出しや引数も記録する必要があります。早期にログを記録しておくコストは低いですが、後で修正するコストは高くなります。
エージェント間の通信を制限してください。マルチエージェントシステムでは、エージェント間の呼び出し回数にハードキャップ（上限）を設定してください。これにより、連鎖的な失敗を防ぐことができます。
大規模な環境におけるAIの安全性は、モデルの問題ではありません。プラットフォームの問題です。エージェントを、他のあらゆる本番システムと同じ運用規律を持って扱ってください。
オプションの学習コミュニティ: https://t.me/GyaanSetuAi