この記事は KDDIアジャイル開発センター（KAG） Advent Calendar 2025、23日目の記事です。
はじめに
こんにちは、KDDIアジャイル開発センターのはしもと（仮名）です。
本記事では、AWS re:Invent 2025期間中に発表された IAM Policy Autopilot について紹介します。
この機能は「Agent-centric identity and access management（エージェント中心のIDおよびアクセス管理）」というコンセプトの一部として発表されました。
名前からは「AIエージェントがコードを理解して最適なIAMポリシーを自動生成してくれる」という期待を持ってしまいそうですが、実際にはどうなのか、その仕組みの検証と活用方法を考えていきます。
なお本記事の内容は、AWS re:Invent 2025 re:Cap with KAG の登壇内容を一部修正したものです。
Agent-centric な権限管理とは
re:Invent 2025期間中では、AWSのブログ内で、AIを活用したセキュリティイノベーションとしてこの概念が発表されました。
また、これらを構成する新機能として、以下の4つの機能が紹介されました。
| 機能名 | 概要 |
|---|---|
| IAM Policy Autopilot | ポリシー生成の自動化 |
| Login for AWS local development | 人間がアクセスする場面で長期鍵を排除 |
| Private access sign-in | コンソールアクセスを閉域化、利用アカウントを制限 |
| Outbound identity federation | マシン/ボットがAWS外へアクセスする場面で長期鍵を排除 |
直接言及があるわけではないですが、「Agent-centric」という概念は、それぞれがAIエージェントと統合された機能というものではありません。
あくまでAIエージェントの登場も踏まえた新しいIAMの考え方で、エージェントとの連携有無に関わらず、既存のリスクポイントを見直し、セッションベースの認証認可や、ゼロトラストの成熟度レベルを向上させることを目的としていると理解しました。
本記事では、この中から IAM Policy Autopilot に焦点を当てて解説します。
IAM Policy Autopilotの概要
当初抱いたイメージ
「IAM Policy Autopilot」という名前から、以下のような流れを想像していました。
IAMポリシーに関するナレッジを備えたAIエージェントが、ユーザーの作成したコードを理解
↓
実装とAWSにおけるIAMポリシーのベストプラクティスに基づき、最適化されたポリシー定義を出力
↓
人とIAMポリシーとの長きに渡る争いの終結（わーい！）
実際の仕組み
しかし実際には、「指定されたファイル内でのSDK呼び出しを抽出し、それに対応するアクションを許可するポリシーを生成する」という決定論的なコード解析を用いたツールでした。
処理の流れは以下の通りです。
１．ローカルでコードをスキャン ： AWS SDK呼び出しをマシン上で解析
２．依存関係を含む権限へマッピング ： 使用するSDK呼び出しに対応するIAMアクションに変換
３．ベースラインポリシーを生成 ： 構文的に正しいIAMポリシーのJSONを出力
重要なポイントとして、エージェント（LLM）を呼び出しているわけではなく、ルールベースの変換であることを理解しておく必要があります。
インストール方法
IAM Policy Autopilotは、手元で簡単に動かすことができます。OSSとしてツールが公開されているのでリポジトリを見ながら進めます。
CLIツールとしてインストール
方法1: uvを使用（推奨）
# 直接実行
uvx iam-policy-autopilot
方法2: pipを使用
pip install iam-policy-autopilot
方法3: インストールスクリプトを利用
curl -sSL https://github.com/awslabs/iam-policy-autopilot/raw/refs/heads/main/install.sh | sudo sh
MCPサーバーとして設定
MCPサーバーとして利用する場合は、以下のような設定を行います（Kiro × uv/uvxの場合の例）。
{
"mcpServers": {
"iam-policy-autopilot": {
"command": "uvx",
"args": ["iam-policy-autopilot", "mcp-server"],
"env": {
"AWS_PROFILE": "your-profile-name",
"AWS_REGION": "us-east-1"
},
"disabled": false,
"autoApprove": []
}
}
}
利用可能なサブコマンド
IAM Policy Autopilotは、CLIツールとしてもMCPサーバー経由でも、以下の主要な機能を提供しています。
| サブコマンド（CLI） | 概要 |
|---|---|
generate-policies |
ソースコードからIAMポリシーを生成 |
fix-access-denied |
AccessDeniedエラーを分析し、必要なポリシー変更を提案・適用 |
mcp-server |
MCPサーバーを起動 |
generate-policiesの主なオプション
iam-policy-autopilot generate-policies <source_files> [OPTIONS]
| オプション | 説明 |
|---|---|
--region <REGION> |
リソースARNのAWSリージョンを指定 |
--account <ACCOUNT> |
リソースARNのAWSアカウントIDを指定 |
--service-hints <SERVICES> |
分析対象のAWSサービスを限定（不要な権限の削減に有効） |
--upload-policies <PREFIX> |
生成されたポリシーをAWS IAMにアップロード |
--pretty |
JSON出力を整形 |
fix-access-deniedの主なオプション
iam-policy-autopilot fix-access-denied <error_message> [OPTIONS]
| オプション | 説明 |
|---|---|
--yes |
確認なしでポリシー変更を自動適用 |
基本的な使い方と実行例
シンプルなコードでの動作確認
まずは、シンプルなPythonコードで動作を確認してみましょう。
import boto3
sts = boto3.client("sts")
response = sts.get_caller_identity()
print(response)
このコードに対してIAM Policy Autopilotを実行します。
uvx iam-policy-autopilot generate-policies ./src/get_caller_identity.py --pretty
生成されるポリシーは以下の通りです。
{
"Policies": [
{
"Policy": {
"Id": "IamPolicyAutopilot",
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:GetCallerIdentity"
],
"Resource": [
"*"
]
}
]
},
"PolicyType": "Identity"
}
]
}
シンプルなコードであれば、適切なポリシーが生成されます。
複雑なコードでの課題
少しコードに処理を追加してみます。以下は、S3、DynamoDB、VPCを操作するSDK呼び出しが含まれるLambda関数の例です。
"""
IAM Policy Autopilot 検証用 Lambda関数
"""
import os
import boto3
AWS_REGION = os.environ.get("AWS_REGION", "ap-northeast-1")
s3_client = boto3.client("s3", region_name=AWS_REGION)
dynamodb_client = boto3.client("dynamodb", region_name=AWS_REGION)
dynamodb_resource = boto3.resource("dynamodb", region_name=AWS_REGION)
BUCKET_NAME = os.environ["BUCKET_NAME"]
TABLE_NAME = os.environ["TABLE_NAME"]
"""Lambda関数のエントリポイント。actionパラメータに応じて処理を振り分ける"""
def handler(event, context):
action = event.get("action")
if action == "s3_get":
return s3_get_object(event["key"])
elif action == "dynamodb_put":
return dynamodb_put_item(event["item"])
"""S3バケットから指定したキーのオブジェクトを取得する"""
def s3_get_object(key):
response = s3_client.get_object(Bucket=BUCKET_NAME, Key=key)
return response["Body"].read().decode("utf-8")
"""DynamoDBテーブルの存在を確認し、なければ作成する"""
def ensure_table_exists():
try:
dynamodb_client.describe_table(TableName=TABLE_NAME)
except dynamodb_client.exceptions.ResourceNotFoundException:
dynamodb_client.create_table(
TableName=TABLE_NAME,
KeySchema=[{"AttributeName": "pk", "KeyType": "HASH"}],
AttributeDefinitions=[{"AttributeName": "pk", "AttributeType": "S"}],
BillingMode="PAY_PER_REQUEST",
)
# テーブルがACTIVEになるまで待機
waiter = dynamodb_client.get_waiter("table_exists")
waiter.wait(TableName=TABLE_NAME)
"""DynamoDBテーブルにアイテムを保存する"""
def dynamodb_put_item(item):
ensure_table_exists()
table = dynamodb_resource.Table(TABLE_NAME)
table.put_item(Item=item)
"""VPCの存在を確認し、なければ作成する（未使用関数）"""
def ensure_vpc_exists():
ec2_client = boto3.client("ec2")
response = ec2_client.describe_vpcs(
Filters=[{"Name": "tag:Name", "Values": ["autopilot-test-vpc"]}]
)
if response["Vpcs"]:
return response["Vpcs"][0]["VpcId"]
vpc = ec2_client.create_vpc(CidrBlock="10.0.0.0/16")
return vpc["Vpc"]["VpcId"]
このコードでは、実際に呼び出されるのは以下の処理のみです。
- S3からオブジェクトを取得（
s3_get_object） - DynamoDBテーブルの作成（未作成時のみ、
ensure_table_exists） - DynamoDBへのアイテム保存（
dynamodb_put_item）
一方、ensure_vpc_exists関数はコード内に存在しますが、実際には呼び出されません。
このコードに対してIAM Policy Autopilotを実行すると、以下のようなポリシーが生成されます。
{
"Policies": [
{
"Policy": {
"Id": "IamPolicyAutopilot",
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:*:*:key/*"
],
"Condition": {
"StringLike": {
"kms:ViaService": [
"s3.*.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectLegalHold",
"s3:GetObjectRetention",
"s3:GetObjectTagging",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:*:*:accesspoint/*/object/*",
"arn:aws:s3:::*/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3-object-lambda:GetObject"
],
"Resource": [
"arn:aws:s3:*:*:accesspoint/*/object/*",
"arn:aws:s3:::*/*"
]
},
{
"Effect": "Allow",
"Action": [
"dynamodb:BatchWriteItem",
"dynamodb:CreateTable",
"dynamodb:CreateTableReplica",
"dynamodb:DeleteItem",
"dynamodb:DescribeTable",
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:PutResourcePolicy",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:TagResource",
"dynamodb:UpdateItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:kms:*:*:key/*"
],
"Condition": {
"StringLike": {
"kms:ViaService": [
"dynamodb.*.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DescribeVpcs"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpc"
],
"Resource": [
"arn:aws:ec2:*:*:ipv6pool-ec2/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2::*:ipam-pool/*"
]
}
]
},
"PolicyType": "Identity"
}
]
}
まあ大変です。こんなにたくさんのポリシーを出力するなんて、ポリシーにも大は小を兼ねる理論を適用したい方なのでしょうか。
DynamoDBだけで12個のアクションがある、また ensure_vpc_exists() は実際には呼び出されないにもかかわらず、EC2関連の権限（ec2:CreateVpc、ec2:DescribeVpcsなど）が含まれてしまっています。
なお本来必要な最小限のポリシーは以下のようなものです。シンプルですね。これがほしかったのに。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "<操作対象のS3バケットのARN>/*"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable",
"dynamodb:CreateTable",
"dynamodb:PutItem"
],
"Resource": "<操作対象のDynamoDBテーブルのARN>"
}
]
}
実践的な活用方法
ここまで見てきたとおり、IAM Policy AutopilotだけではAWSが勧める「最小権限の原則」を満たすポリシーは得られません。
それは仕方のないこととして特性を理解した上で、効果的な活用方法を考えてみます。
ベースラインポリシーの「たたき台」として使う
ポリシー定義を固めていく際の「LLMのコンテキスト」として利用できます。
- 先にルールベースで生成し、そこからLLMに削らせる
- ルールベースでマッピングする特性上、存在しないAction名は出てこないという利点がある（最新サービスへの対応状況については今後要確認）
最小権限でなくていいからまず動くポリシーが欲しい場合
-
AdministratorAccessやPowerUserAccess、xxxFullAccessの使用は回避できる
最小権限でIAMポリシーを作成する際に利用可能な機能として「IAM Access Analyzer」のポリシー生成機能が挙げられます。ただし、CloudTrailログをインプットとして必要な権限を判断するため一度ソースコードをAWS上で実行する必要があるのに対し、このツールは実行前に使うことができます。
fix-access-deniedによるエラー修正
fix-access-denied機能を使うと、権限不足系のエラーメッセージを渡すことで、足りないポリシーを教えてくれます。
便利は便利なのですが、じゃあわざわざIAM Policy Autopilotを使う必要があるか、と言われると悩むところではあります。
まとめ
IAM Policy Autopilotは、コードからIAMポリシーを自動生成する便利なツールですが、その出力は 「たたき台」程度のものです。
重要なポイント
- 出力結果は不完全であることを理解した上で、LLMなどのコンテキストとして活用する
- 最小権限の実現には、人間のレビューが引き続き求められる
- もうX年、IAMポリシーと遊べるドン！
AIやツールによって完全にこのあたりの確認が自動化できればよいですが、その分求められる品質レベルとしては高く、完全に機械に委譲するにしてはまだまだリスクのある領域です。
IAM Policy Autopilotを上手に活用しながら、適切な権限管理を実現していきましょう。