最も安全な境界とは、エージェントが手を伸ばすことすらできない境界である
AIエージェントが複数の組織のインフラを運用する場合、セキュリティは悪夢となります。
危険なのは、エージェントが巧妙なミスを犯すことではありません。危険なのは、エージェントが「間違った相手」に対して、ごく当たり前の作業を行ってしまうことです。
カスタマーAの代わりにカスタマーBのためにチケットを作成したり、シークレットをローテーションしたりすることは、情報漏洩にあたります。漏洩はパッチを当てて修正できるものではありません。開示しなければならないのです。
多くの人は、これを権限（permissions）で解決しようとします。エージェントが触れることができるもののリストを作成し、すべてのアクションをそのリストと照合します。
しかし、これは失敗します。権限管理は「リソースが存在していること」を前提としており、単に「拒否」するだけだからです。もしルールにバグがあったり、考慮漏れがあったりすれば、エージェントは誤ったデータにアクセスできてしまいます。
私は異なるモデルを採用しています。誤ったデータを「構造的に存在しない状態」にするのです。
カスタマーAのセッション内では、カスタマーBのリソースは存在しません。認証情報（credentials）はロードされず、エンドポイントもマップには含まれません。要求すべきものが存在しないため、拒否すべきものも存在しないのです。
ルールにはバグが生じますが、システムの物理的な構造にはバグは生じません。
私はこれを身をもって学びました。かつては、secrets managerがあれば十分だと考えていました。シークレットを分離すれば、テナントも分離できると考えていました。しかし、それは間違いでした。
secrets managerはシークレットを分離しますが、エンドポイントを分離するわけではありません。エージェントがカスタマーAの正しいトークンを持っていても、もし設定の中にカスタマーBのアドレスが含まれていれば、そのアドレスにリクエストを送ってしまう可能性があるのです。
漏洩の原因はシークレットではなく、ルーティングにあります。
私は、すべてのリソースを以下の1つのレコードにバインドすることで、この問題を解決しました。 • Resource • Endpoint • Credential • Owning tenant
所有者を取得せずにアドレスを取得することはできません。データを送信するライブラリは、テナントがセッションと一致しない場合、動作を拒否します。アドレスは所有者と結合されて初めて存在するものであるため、ハードコードによってこれを回避することは不可能です。
私は3層の防御策を用いています。
- 誤ったデータが存在しないようにするための構造的隔離（Structural isolation）
- エージェントがチェックを回避するために生のツールを使用できないようにするためのバイパスブロック（Bypass block）
- セッションが許可されたアドレスとしか通信できないようにするためのエグレス・スコーピング（Egress scoping）
これにより、フェイルクローズ（fails closed）するシステムが構築されます。
以前の仕事では、私はフェイルオープン（failing open）を主張していました。もしエージェントがアクションの安全性を確信できない場合は、そのまま進めるべきだと考えていたのです。疑念が生じるたびに停止してしまうエージェントは、役に立たないからです。
しかし、テナントの境界線は別問題です。もしエージェントが、自分が触れているのが誰のデータであるか確信が持てない場合は、停止しなければなりません。
行動における不確実性は動きをもたらす。所有における不確実性は、静止をもたらさなければならない。
「ノー」と言うためのチェックを構築してはならない。チェックを必要とする形そのものを取り除け。
出典: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad
オプションの学習コミュニティ: https://t.me/GyaanSetuAi