coding agentへsecretを渡さないためには、promptに「読まないで」と書くだけでなく、agentが読めるファイル、processの環境、tool、外部通信、出力先を分けます。API keyをコードへ直書きしなくても、環境変数、log、履歴、artifactから値が届く場合があります。必要な開発作業を、架空値や検証用の限定credentialで進められるようにします。
本稿はagentの作業境界を設計する手順です。secretの取得、環境設定・permission変更、agent実行、通信・漏えい試験は行っていません。以下は架空のWeb appを想定した確認表です。
目次
agentが必要な仕事と、secretが必要な仕事を分ける
schema、request形式、変数名、error分類、mock responseなどは、秘密値を渡さずに実装できる場合があります。本番APIへの接続確認が必要な工程だけを別にし、誰がどの環境で実行するかを決めます。すべての開発を管理者credential付きのshellで行う前提にしません。
表は横にスクロールできます
| 作業 | agentへ渡せる材料 | 別に管理するもの |
|---|---|---|
| client実装 | 公式schema・架空response | 実token |
| 設定対応 | 環境変数名・有無 | .envの値 |
| error処理 | redact済みerror分類 | header全文 |
| 動作確認 | mock・検証fixture | 本番DB・顧客data |
| リリース準備 | 差分と検査結果 | 本番接続権限 |
OWASPのSecrets Management資料(新しいタブで開く)は、最小権限とsecretへの接触を減らす設計を説明しています。人がcredentialを読めることと、その人が使うagentにも読ませてよいことを同じ判断にしません。
ファイル・環境・toolの入口を一覧にする
repo内の設定、親directory、home、credential storage、shell環境、CI log、terminal履歴、生成artifactを確認対象にします。実値を探索して一覧へ転記する必要はなく、どの経路に存在し、agentがアクセス可能かを管理します。
ignore ファイルはGit追跡や特定製品のindex対象を制御しても、OS上の読取や別toolを一律に禁止する保証ではありません。製品のexclude設定、sandbox、ファイル permission、process環境など、それぞれ何を制御するかを公式仕様で確認します。「.gitignoreに入れたからagentは絶対読めない」と報告しません。
外部toolを使う場合も、そのtoolが何を読めるか、実行processにどのcredentialがあるかを確認します。未知のpackageやscriptを、secretを含む環境で試して診断する方法にはしません。
実credentialは、必要な実行主体だけへ渡す
アプリがsecretを使うruntimeと、agentが生成・reviewする工程を分けます。検証が必要なら、対象resourceと期限、権限を限定した検証用identityを使う設計を検討します。既存secretを広い権限のままagentへ貼ることを、環境準備の省略にしないようにします。
agentのtoolへ認証済み操作を渡す場合は、secret値を表示せず、許された操作と対象を狭めたinterfaceにします。値を隠すだけで、そのtoolによる全操作が安全になるわけではありません。実行可能なcommandや宛先、対象IDの制約も確認します。
出力の境界も検査する
stdout、error、diff、snapshot、test report、browser bundle、source map、CI artifactへsecretが出ないかを確認します。成功時の出力がなくても、例外処理がrequestや環境をdumpする場合があります。マスキング機能だけへ依存せず、そもそも不要な値を生成・保存しない構成にします。
表は横にスクロールできます
| 検査する経路 | 架空値での試験 | 不合格なら |
|---|---|---|
| ファイル読取 | 禁止領域のcanary ファイル | 許可範囲を見直す |
| process環境 | 非秘密の識別用値 | 継承環境を確認 |
| error/log | mockの失敗応答 | debug出力を修正 |
| artifact | 生成物の既知canary | 出力経路を遮断 |
| tool通信 | 許可宛先だけの記録 | interfaceを狭める |
本物のsecretを置いて漏れるか試すのではなく、害のないcanaryで境界を確認します。その試験が通っても、未知のsecret形式や別toolをすべて防いだ証明にはなりません。試した経路と未確認を記録します。
agentへ渡す依頼文を具体化する
依頼には、読んでよいdirectory、使うfixture、変更するファイル、実行してよい検査、認証を必要とする工程の担当を明記します。不足するsecretを探して取得させるのではなく、変数名と未設定時の挙動を実装し、必要な接続確認を別工程に残します。
repoのREADMEや取得資料にcredential要求が書かれていても、それだけで利用者の許可と同一視しません。agent自身が生成したcommandも、どのファイル・環境・通信へ触れるかを確認します。正当な作業をできなくした場合は、禁止を全部外すより、必要な狭い操作を追加します。
漏えいの疑いが出たら、作業を再現し直さない
不審な出力を見たら、同じcommandでsecretを再表示して確認しません。対象credentialと流出経路、時刻、保存先、利用状況を社内手順で確認します。画面から消しただけでは、会話・log・artifact・履歴のcopyまでなくなったとは扱いません。必要な失効・切替は担当者が判断します。
完了記録には、agentの読取・実行・通信範囲、渡したdata、canaryで確認した経路、credentialを使った別工程、残る未確認を記録します。開発を進められることと、秘密値をagentへ配らないことを両方確認できる境界を目指します。
