AI エージェントに PaaS・オーケストレーターの管理 API や本番ログを操作させると、秘密は「渡し方」ではなく戻り方から漏れる。実作業で1セッション中に同じ本番 DB パスワードを3回会話ログへ流出させた経験から、経路は3つに類型化できる。

漏れる3経路

1. リソース作成 API のレスポンス: 生成した資格情報を作成結果に含めて返す実装が多い。作成のたびに平文で返る
2. サービス・コンテナのログ取得: 起動スクリプトが接続文字列を引数に持つツールを呼ぶと、その行がログに残る。ログの末尾を取っただけで資格情報が出る
3. リソース詳細取得 API: 環境変数一式をそのまま返す。「一覧が見たいだけ」の読み取り呼び出しが最も油断しやすく、実際にこれが3回目の流出だった

判断基準

• 渡す側より受け取る側を疑う。秘密を引数として渡さない工夫（値をファイルへ置き、コマンド内でその場読み出しに展開する）は有効だが、対策として不十分。それは入力面しか塞がない
• 読み取り系の呼び出しほど危険と扱う。書き込み系は身構えるが、読み取り系は「確認するだけ」と素通しにしがちで、環境変数や接続情報を含むペイロードが丸ごと出る
• 秘密を返しうる API は、呼び出しの直後に投影を挟むのを既定にする。応答をそのまま出力せず、必要なフィールドだけを抜き出して表示する。「まず生で見て、必要なら絞る」の順にしない
• ログ取得は既知の秘密パターンをマスクする整形を必ず通す。接続文字列の書式は限られるので、その形にマッチする部分を伏せ字へ置換してから出す

落とし穴

• ファイルへ置いた秘密をコマンド内で読み出す方式は、値が会話ログに出ない点で有効だが、プロセス引数には現れる。共有ホストでは別の露出面になる。標準入力へ流し込む形にできるならそちらが強い
• 流出したら必ずローテーションする。会話ログ・セッション記録は永続化されるので「見なかったことにする」は成立しない。ローテーションは DB 側の変更だけでなく、管理基盤に保存された値とアプリの環境変数の両方を更新しないと、次回の再作成で古い値が復活する

確認方法

作業前に「この API は秘密を返しうるか」を一度だけ確かめ、返すなら投影のひな型を決めてから本番作業に入る。事故後の再発防止として、同じ API を次に呼ぶときも投影を通す。