あなたの開発したエージェントが、あなた自身の資格情報（クレデンシャル）を使用しているという問題

本ブログはグローバルで公開された「Your agents are using your credentials, and that is the problem」の抄訳版です。

エンジニアがエージェントを本番環境にリリースする。そのエージェントは社内APIを呼び出す必要があるため、エンジニア自身の環境にすでにあるキーを利用する。エージェントが稼働する。と同時に、そのエージェントはエンジニアが保持しているすべての権限を手に入れることになる。

これこそが、今日のほとんどのエージェント開発におけるデフォルト（初期状態）の姿です。エージェント自身が固有のアイデンティティ（識別情報）を持たないため、借りてしまうのです。通常は、APIキーを介して人間のアイデンティティを借用します。初日は何の問題もなく動いてしまうため、まさにこの問題は見過ごされたまま本番環境へ出荷されてしまいます。

権限の「継承」が実際にもたらす代償

このたった一つのショートカット（手抜き）から、4つの破綻が引き起こされ、それらは連鎖して悪化していきます。

1. 特権昇格が発生する 人間ではないプロセスが、人間の持つ全アクセス権限をそのまま帯びることになります。タスクがそれを必要とするかどうかに関わらず、その人間がアクセスできるすべてのシステムにエージェントが到達できてしまいます。

2. スコープ（権限範囲）の限定ができなくなる エージェントが触れるべきなのは、社内システムのごく限定された一部であるべきです。しかし、人間のキーはそもそも「これだけを実行する」という限定的な意図を表現するために作られていないため、結果としてエージェントにあらゆるアクセスを許してしまいます。

3. 属性情報の喪失 エージェントが行動を起こした際、監査ログにはその「人間の仕業」として記録されます。エージェントがやったことと、人間がやったことを分離して追跡することができなくなります。これにより、インシデント発生時の対応は這うような遅さになり、後から求められるあらゆるコンプライアンスへの説明も困難になります。

4. 綺麗な失効ができなくなる エージェントの動作を停止させるために、その人間のキーを無効化・変更しなければならなくなります。これを行うと、その人間自身のアクセス権だけでなく、そのキーに依存していた他のすべてのプロセスまで巻き添えで遮断してしまいます。エージェント「だけ」をオフにするスイッチが存在しなくなるのです。

知識のある読者であれば、ここでよくある解決策に手を伸ばすでしょう。「キーを定期的に変更すればいい」「代わりにサービスアカウントをエージェントに渡せばいい」と。しかし、その両方とも本当の問題を見落としています。

「パスポート」はメンタルモデルとして間違っている

私たちの本能は、アイデンティティ（識別情報）を「パスポート」のように扱いがちです。パスポートは「あなたが誰であるか」を認証し、あらかじめ固定された権限セットへとあなたを紐付けます。国境で見せれば、それに伴うアクセス権が得られるという仕組みです。このモデルがうまく機能するのは、その権限の範囲内での「振る舞い（行動）」が予測可能である場合だけです。データセットへの読み取り権限を持つ人間は、データセットを読み取ります。キュー（待ち行列）に投稿するサービスアカウントは、毎回同じ周期で、淡々とキューに投稿します。

しかし、エージェントはパスポートの前提にあるこの「予測可能性」を破壊します。ここで問いかけるべき正しい質問は、「このアクターは誰か」ではありません。「このアクターは今この瞬間、このタスクのために、何をすることを認可されているか」です。これはパスポート的な意味でのアイデンティティではなく、「権能・権限（Authority）」の概念であり、この違いこそがすべての本質です。

これが重要な理由は次の通りです。エージェントの挙動は非決定的（ノン・デターミニスティック）です。2つのエージェントに同じ権限とまったく同じゴールを与えたとしても、彼らは異なる行動をとる可能性があります。なぜなら、各エージェントはプロンプト、コンテキスト、そして自分を呼び出したものの出力に基づいて、実行時（ランタイム）にどのツールチェーンを使用するかをその都度選択するからです。エージェントが実際にどのような行動を起こすかは、事前に権限を付与する（設計時の）段階では知る由もありません。

そうなると、「設計時に最小特権の原則を適用する」という行為は、「実行時の問題に対して、事前に設計時レベルの回答を用意しようとする」という矛盾に陥ります。アクター自身が何をするかを実行時に初めて決定するのに対して、あなたはアクターが何をしてよいかを前もって決めようとしているのです。対話のたびに振る舞いが変化するアクターに対して、静的な（固定された）権限付与では到底追いつくことはできません。

あなたのIAMスタックがこの問題を引き起こす理由

これは設定のミスではありません。アイデンティティ＆アクセス管理（IAM）に組み込まれた構造的な前提によるものです。現在運用されているシステムは、アクターを「人間」か「静的な権限セットを持つ長寿命のサービスアカウント」のいずれかであると想定しています。どちらも安定しており、毎日だいたい同じことを行います。あなたの管理策、監査モデル、そしてプロビジョニングのフローは、すべてその安定性を前提に構築されています。

しかし、エージェントはそのどちらでもありません。彼らは人間の代わりに動くため、サービスアカウントではありません。かと言って、独自のスケジュールで起動し、破棄されるソフトウェアであるため、人間でもありません。エージェントは、既存のIAMスタックにカテゴリーが存在しない「隙間」に位置しており、その隙間こそが、資格情報が借用されてしまう場所なのです。

まとめ

もし開発したエージェントが、それをデプロイした人間の名義で認証を行っているとしたら、あなたの本番環境には今まさに「権限継承」の問題が存在しています。監査人やインシデントによって発見される前に、自分たちで見つけ出してください。人間用のAPIキーが人間以外のプロセスによって使用されていないか、そして監査ログにおいてエージェントの行動と人間の行動が区別できなくなっていないかを探すのです。

キーの共有をやめるというのは、表面的な修正にすぎません。本当の解決策はもっと困難です。非決定的なアクターを、設計時の静的な権限付与で統治することはできません。つまり、エージェントに必要なのは、国境で一度だけスタンプを押されるパスポートではなく、実行時に決定される権能（Authority）のために構築されたアイデンティティです。

となると、当然の疑問が浮かびます。「エージェントに独自のアイデンティティが必要だとして、そのアイデンティティは一体何で構成されるのか？ そしてそれは、すでに運用しているワークロード・アイデンティティと何か違うのだろうか？」——それについては、次回の記事で解説します。