生成AI時代のIAMのマニアックな話 — プログラムには鍵を渡せるのに、なぜLLMには渡してはいけないのか

佐々木拓郎

AWSのIAMは長らく、登場人物を人間とプログラムの2種類で説明できました。プログラムに鍵を渡せたのは、値の使い道がコードで決まり、レビューで保証できたからです。第3のアクター、LLMは違います。渡した値がその後どう使われるかを、プログラムのようには保証できません。守り役のハーネスも、LLMと同じ信頼境界の内側にいます。必要なのは、その外側からの守りです。 その境界は、IAMの代理実行を活用して構築できます。IAMには、本人に鍵を渡さず代理者に実行させる設計思想が昔からあります。代表例はAssumeRoleやサービスロールです。この思想はAIエージェントにも応用できます。MCPサーバ経由を見分ける条件キーや、モデルに鍵を持たせないBedrockの設計も、その延長線上にあります。 従来の考え方がどこまで通用し、どこから拡張が要るのか。15分で整理します。対象はAIエージェントからAWSを操作する方で、IAMロールとポリシーの基本を前提とします。11月発行予定の『AWSの薄い本 IAMのマニアックな話』改訂第2版でも扱う、生成AI時代のIAM設計を先取りしてお話しします。