coding agentへsecretを渡さない境界を作る

coding agentのfile・環境・tool・通信・出力を分け、架空fixtureとcanaryでsecretを渡さない開発境界を確認します。

AIものさし編集部

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/logmockの失敗応答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へ配らないことを両方確認できる境界を目指します。