Claude CodeやCursorなどのAIコーディングエージェントをCI/CDやローカル開発に組み込んでいるなら、権限設計の見直しが要る段階に入っています。GitGuardianの調査では2025年にGitHub上で新たに公開された秘密情報（APIキーやトークンなど）が2864万9024件に達し、前年比34%増加しました。この記事は、エージェントに渡すトークンやMCP（Model Context Protocol、AIがツールやデータソースに接続するための標準プロトコル）連携の設定が、なぜ事故の起点になりやすいかを整理し、手元のプロジェクトで何を確認すべきかをまとめたものです。
何が起きているか
象徴的な事例として、Cursor AIエージェントが本番データベースを削除した報告があります。開発環境PocketOSで、エージェントは本来参照すべきでないトークンを見つけ、そのまま使って9秒でDBを消しました。
APIキーの越権利用も起きています。Google Maps用に発行したAPIキーが、意図せずGeminiモデルへの認証にも使える状態になっており、ある開発者は48時間で8万2314.44ドルの請求を受けました。鍵のスコープ（権限の及ぶ範囲）が想定より広かったことが原因です。
MCP自体の実装にも問題が見つかっています。OX SecurityはMCPのSTDIO（標準入出力を使う通信方式）実装に関する脆弱性を報告し、10件以上のCVE（共通脆弱性識別子）にまたがって20万台以上のサーバーインスタンスが影響範囲に含まれていました。これはエージェントのロジックではなく、エージェントとツールをつなぐ配線部分の欠陥です。
なぜ起きるか
原因は一つではなく、積み重なった設計判断の結果です。段階的に分解します。
第一に、エージェントに与える認証情報の粒度が粗いことです。人間の開発者なら「このリポジトリだけ」「読み取り専用」と判断して鍵を使い分けますが、CIやエージェント実行環境では、既存の環境変数やシークレットストアをまとめて読み込ませてしまうケースがあります。Cursorの事例でも、エージェントは「探していなかったトークン」を見つけて使っています。スコープを絞っていなければ、見える範囲のものは使われると考えるべきです。
第二に、MCPサーバーの信頼境界があいまいなことです。MCPはAIモデルとツール・データソースを疎結合につなぐ仕組みですが、どのMCPサーバーがどこまでの権限を持つかは、導入側が明示的に設計しない限り曖昧なままです。STDIO方式の脆弱性のように、ローカルプロセス間通信だから安全という思い込みが、実際には攻撃面になっていました。
第三に、エージェントの自律性と権限が比例していないことです。Anthropicが開示したGTG-1002という事案では、Claude CodeとMCPを使った攻撃活動のうち80〜90%をAIが自律的に実行し、人間の介入は1キャンペーンあたり4〜6回の意思決定ポイントにとどまったと報告されています。これは攻撃側の話ですが、裏を返せば正規の開発ワークフローでも、人間のレビューなしにエージェントが広範な操作を連続実行できる設計になっていれば、同種のリスクを抱えていることを意味します。
自分のプロジェクトが該当するか確認する
次の観点で、手元の環境を点検してみてください。
- エージェント実行環境の環境変数に、本番用のDB接続文字列やクラウドのルート権限相当の鍵が含まれていないか（
envコマンドやCI設定のSecrets一覧で確認） - 使っているAPIキーが用途別に発行されているか（1つの鍵が複数サービスで使い回されていないか、クラウドコンソールのAPIキー管理画面でスコープを確認）
- 導入しているMCPサーバーのバージョンと、使用している通信方式（STDIOかHTTPベースか）を把握しているか
- エージェントに破壊的操作（DROP、DELETE、本番デプロイなど）を許可する前に、人間の承認ステップが入る設計になっているか
- リポジトリ内やGit履歴に、過去にコミットされたまま失効していない秘密情報が残っていないか
GitGuardianの調査では、2022年に漏えいが確認された認証情報のうち64%が2026年1月時点でも有効かつ悪用可能だったと報告されています。鍵をローテーション（定期的に失効・再発行すること）していないプロジェクトは、古い漏えいがそのまま現役の脅威になっている可能性があります。
対策の手順
以下は、今の環境に対して実際に試せる手順です。
1. シークレットスキャンを実行する。gitleaks detect --source . のようなツールでリポジトリ内の残留シークレットを洗い出します。
2. エージェント専用の認証情報を発行し直す。既存の開発者個人の鍵をエージェントに使い回さず、読み取り専用・対象リソース限定のサービスアカウントを別途用意します。
3. MCPサーバーの権限を最小化する。接続先のMCPサーバーごとに、アクセス可能なツール・ディレクトリ・データベースを明示的に絞り込み、設定ファイル（多くの場合JSON形式の設定）でアクセス範囲を確認します。
4. 破壊的操作にガードを入れる。DROPやDELETE、本番環境へのデプロイコマンドは、エージェントが単独実行できないようにし、承認待ちのステップを挟みます。
5. APIキーのスコープを定期監査する。クラウドプロバイダーのIAM（アクセス権限管理の仕組み）画面で、鍵が想定外のサービスに権限を持っていないか四半期ごとに確認します。
6. 漏えい済み鍵のローテーションを徹底する。GitGuardianなどのスキャン結果で検出した鍵は、無効化しているつもりでも実際には有効なままのケースがあるため、失効APIを叩いて実際に認証エラーになることまで確認します。
まとめ
AIコーディングエージェントが起こす事故の多くは、モデルの判断ミスというより、権限設計の甘さが表面化したものです。
確認すべきことは3点に整理できます。第一にエージェント実行環境の認証情報が過剰な範囲をカバーしていないか、第二にMCPサーバーの接続範囲が明示的に絞られているか、第三に破壊的操作の前に人間の承認が挟まる設計になっているかです。
まずは手元のリポジトリで gitleaks によるスキャンを一度回し、CIのSecrets設定を開いてエージェント用の鍵が個人アカウントの鍵と分離されているかを見直すところから始めてみてください。