【AI駆動DevOps】AIエージェントにAWS環境を安全に渡すための「ReadOnly設定分離」戦略

AIエージェントにインフラ構築やセキュリティ診断を任せる際、最大の懸念は「AIが誤って本番環境を破壊しないか？」という点です。本記事では、自作AIエージェント（Kiro CLI）での運用事例を元に、 物理的に書き込み権限を持たせない設定ファイルの分離 と、AWS SSO環境下での安全な実装パターン について解説します。

1. 背景と課題

私たちは現在、AWS環境のセキュリティ診断やコスト最適化を行うAIエージェントを運用しています。しかし、開発者のローカルマシンにある ~/.aws/config には、通常 AdministratorAccess や PowerUserAccess などの強力な権限を持つプロファイルが含まれています。

プロンプトで「書き込み禁止」と指示するだけでは不十分です。LLMは確率的に動作するため、指示を無視したり、意図せず破壊的なコマンド（terraform destroy や aws s3 rb）を実行するリスクがゼロではありません。

課題

1. 誤操作リスク: AIが誤ってAdmin権限のプロファイルを使用してしまう。
2. プロンプト依存の脆弱性: LLMへの自然言語による禁止指示は、確実なガードレールではない。
3. SSO/証明書問題: 企業内ネットワーク下で、AIエージェント経由のCLI実行がSSLエラーで失敗する。

2. 実装環境と前提

• OS: macOS / Linux
• AIツール: Kiro CLI (または Amazon Q Developer CLI, Cursor等のAIエージェント)
• 認証方式: AWS IAM Identity Center (旧 AWS SSO)
• ネットワーク: 企業プロキシ/SSL検査あり（独自のCAバンドルが必要）

3. ソリューション: readonly-config 戦略

私たちの採った戦略はシンプルかつ強力です。「AIエージェントには、Readonly権限しか記述されていない設定ファイルしか見せない」 という物理的な制約を課すことです。

3.1. 構成概要

通常の ~/.aws/config とは別に、~/.aws/readonly-config を作成します。

1. Configの分離: readonly-config には、参照権限のみのプロファイルを記載しています。
2. 環境変数による強制: エージェント実行時のみ AWS_CONFIG_FILE 環境変数を切り替えます。
3. プロンプトによる検証: エージェント自身に「自分が正しいConfigを見ているか」を検証させます。

3.2. ステップバイステップ実装

Step 1: readonly-config の作成

各プロファイルに必要な設定（SSO設定など）を全て明示的に記述する構成を採用しました。

これにより、「どのプロファイルでどの設定が効いているか」が一目瞭然となり、設定ミスを防ぐことができます。

~/.aws/readonly-config:

# SSOセッション定義（ここだけは共通化）
[sso-session my-sso]
sso_start_url = https://my-company.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
cli_pager =

# --- 以下、各環境のReadOnlyプロファイル ---

[profile my-system-dev-readonly]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = ReadUserAccess  # ここで強力な権限は指定しない
region = ap-northeast-1
output = json
cli_pager =

[profile my-system-prod-readonly]
sso_session = my-sso
sso_account_id = 987654321098
sso_role_name = ReadUserAccess
region = ap-northeast-1
output = json
cli_pager =

Step 2: エージェントプロンプトへのガードレール実装

AIエージェント（System Prompt）に、以下の検証手順を義務付けます。これにより、環境変数の設定漏れを防ぎます。

## 対象環境の制約
*   **【必須】** このエージェントは `AWS_CONFIG_FILE` 環境変数で `~/.aws/readonly-config` を指定して利用することが必須です。
*   **【初回検証】** エージェント起動時、必ず以下を実行してください：
    1. `echo $AWS_CONFIG_FILE` を実行。
    2. 値が `~/.aws/readonly-config` でない場合、`export AWS_CONFIG_FILE=~/.aws/readonly-config` を実行して強制的に設定。

Step 3: 企業内プロキシ環境下でのSSL証明書対応

企業指定のCAバンドル（例: custom-ca-bundle.pem）を利用する場合、AWS CLIやPythonライブラリが正しく証明書を読み込めるように環境変数を設定する必要があります。

解決策: AWS_CA_BUNDLE を設定する

AIエージェントの設定（agent-config.json 等）や .zshrc に以下を設定します。基本的には AWS_CA_BUNDLE だけで十分なケースが多いですが、利用するPythonライブラリの依存関係や環境によっては REQUESTS_CA_BUNDLE も必要になる場合があります。

# AWS CLI本体用（基本はこれだけでOK）
export AWS_CA_BUNDLE="/Users/myuser/custom-ca-bundle.pem"

# もしSSOログイン時にSSLエラーが出る場合は以下も追加
export REQUESTS_CA_BUNDLE="/Users/myuser/custom-ca-bundle.pem"

これを設定しないと、aws sso login 時に SSL: CERTIFICATE_VERIFY_FAILED エラーが発生し、AIエージェントがログイン画面のURLを取得できずにスタックします。

4. なぜこの方法が良いのか？

4.1. "設定ファイル分離" vs "IAM権限管理"

「IAMで権限を絞ればいいのでは？」という意見もありますが、AIエージェント運用においては 「設定ファイルの分離」が追加の防壁レイヤー として機能します。

• IAM: 論理的なガード。設定ミスがあれば突破される可能性がある。
• Config分離: 物理的なガード。AIエージェントが見ている世界（Config）には、そもそも書き込み権限のあるプロファイルが存在しないため、AIが誤って profile production-admin を指定しようとしても「Profile not found」で物理的に失敗します。

4.2. 各プロファイルへの明示的な記述

セキュリティに関わる設定ファイルにおいて、「可読性」よりも「確実性」を優先し、各プロファイルに全設定（sso_session, sso_account_id, sso_role_name, regionなど）を明示的に記述する方針を採用しました。

これにより、Git管理されたConfigファイルをチームメンバーに配布した際、「手元だけ動かない」という環境依存トラブルを激減させることができます。

5. まとめ

AIエージェントをインフラ運用に導入する際は、以下の「2重のガードレール」を推奨します。

1. 専用Config: readonly-config を作成し、ReadOnlyプロファイルのみを記述する。
2. 環境変数強制: エージェント実行時は AWS_CONFIG_FILE で専用Configを強制する。

これにより、開発者は「AIが何か壊すかもしれない」という不安から解放され、AIによるインフラ最適化の恩恵を安全に享受できるようになります。