Shared Credentials

エージェントのPoC実装では、手元にある個人のアクセストークンやMachine UserのAPIキーといった認証情報を使い回しがちです。実装が早く終わるという理由で多くの実装者がこの方式を選びますが、エージェント経由で複数の利用者に共有される認証情報、すなわちShared Credentialsはアクセス境界を壊す存在でもあります。

個人トークンの流用

エージェントの実装やテストで、自分のトークンやAPIキーを使うことはよくあります。自分が自分の権限で動かしている間は問題になりませんが、そのエージェントを他の人に公開したとき、利用者は実装者本人の権限でサービスへアクセスします。個人や所属チームにしか許可されていないリソースの閲覧・更新・削除もできてしまいます。 Context Engineeringの浸透で、より多くの文脈を与えるためにエージェントは多数のサービスへ接続されるようになりました。個人の権限を持つトークンをエージェント経由で複数の利用者に共有すると、Confused Deputy Problemに繋がります。

Machine Userの成立条件

個人トークンの次に選ばれるのが、Machine UserやサービスアカウントのAPIキーです。個人に属さないマシンアイデンティティとして広く使われ、Machine Userの権限がエージェントを使う全ユーザーが既に持っている権限の共通部分に収まっている場合は安全に利用できます。もし利用者が本来持っていない権限をエージェント経由で行使できるならConfused Deputy Problemの発生となります。社内ナレッジベースに接続するMCPサーバーを全体読み取り権限のMachine Userで構成し全従業員へ公開すると、別部門の従業員が自分のアカウントでは閲覧を禁じられている文書へそのサーバー経由で到達できます。このためMachine Userに与える権限は、全利用者の権限のサブセットであることを導入時に確かめるだけでは足りません。利用者の異動・退職・権限変更に追随し、監査し続ける必要があります。

監査ログから消える行為者

Machine Userで行われた操作はサードパーティサービスの監査ログ上ではそのMachine Userの操作として記録され、誰を起点とした行動なのかというコンテキストがログから欠落します。コード変更や機微情報の閲覧・編集にMachine Userを使っていると、事故の後に誰がやったのかを辿れません。 Machine Userを使うエージェントでは、エージェント側の利用ログを単なるアクセスログではなく監査ログとして扱う必要があります。誰がいつどの指示でエージェントを動かしたかをサービス側の操作と相関できる形で記録し、改ざんできない形式で長期保存します。

手動の権限付与という落とし穴

Machine Userの運用にはもう一つ落とし穴があります。利用者の一人が、特定チームだけが閲覧できるスペースや自分だけが見られるページをエージェントに読ませたくなり、Machine User自体に手動でアクセス権を付与してしまうことです。ドキュメント管理ツールのプライベートスペース・チケット管理ツールの制限付きプロジェクト・チャットツールのプライベートチャンネルへの意図しない招待が行われる可能性があります。一見すると付与した本人の権限とは合致していますが、Machine Userの権限は全利用者に共有されるため、他の利用者には本来見えないはずのリソースがエージェント経由で取得できるようになります。このため権限の継続的な棚卸しが対策として必要です。導入時にサブセットであることを確認して終わりではなく、Machine Userに意図しない権限が追加されていないかを定期的に検査し、検知と是正を運用に組み込みます。