AI開発時代の多層防御を設計する〜AWSアクセスキーにまつわる怖い話〜
生成AIがコードに認証情報を混入させる新たなリスクを指摘し、シフトレフトと監視設計による多層防御の必要性を説く。
キーポイント
生成AIによるセキュリティインシデントの増加
従来の人間のうっかりミスに加え、生成AIが「動くコード」を優先して認証情報をハードコーディングする傾向が新たな漏洩経路となっている。
GitGuardian 調査による実証データ
GitHub Copilot の補完候補の約 3 割に API キーのような機密情報が含まれているという調査結果があり、AI の常習的なリスクが示唆されている。
シフトレフトと監視設計の重要性
生成AIを活用した開発を安全に行うためには、コード作成段階での防御（シフトレフト）と継続的な監視という 2 つの軸で対策を講じる必要がある。
AWS アクセスキー管理の現状認識
個人やチームがアクセスキーを環境変数やシークレットマネージャではなく、コードに直接記述して使用しているケースが多く見られる。
情報漏洩以外の重大な被害：計算資源の悪用
アクセスキーの漏洩は単なるデータ流出だけでなく、攻撃者による仮想通貨マイニング（クリプトジャッキング）やLLM推論の不正利用（LLMjacking）を招き、数千万円規模の請求が発生するリスクがある。
返金保証はなく調査コストも高い
AWSによる不正利用分の返金対応は存在するが100%保証されるものではなく、いつ・どのキーで何が起きたかを時系列で説明するための調査作業自体に多大な手間がかかる。
多層防御の必要性と自動化
生成AIによる開発速度向上に伴い人手でのレビューが追いつかないため、コード作成時点やプッシュ前の検知など、複数の防衛ポイントで自動かつ事前に機能する仕組みが不可欠である。
重要な引用
生成AIは「一発で動くコード」を最短で出そうとするので、認証情報を環境変数やシークレットマネージャから読む正しい書き方より、そのままコードにベタ書きするほうを選びがちなのです。
GitHub Copilot の補完候補のうち 3 回に 1 回ほどシークレットの構造を満たす文字列（API キーらしき値）が混ざっていたという GitGuardian の調査結果もあります。
「人間のうっかり」だけでなく「AI の常習」として混入が起きる、というのが今の前提です。
怖いのは情報漏洩だけではない
100%返ってくる保証はありません
公開された認証情報は中央値4分未満で外部に発見されています
影響分析・編集コメントを表示
影響分析
この記事は、生成AIツールの普及に伴ってセキュリティリスクの性質が「人的ミス」から「アルゴリズム的な常習」へと変化している点を鋭く指摘しており、開発現場におけるセキュリティ意識の転換を促す重要な示唆を含んでいます。単なる注意喚起に留まらず、具体的な対策として「シフトレフト」と「監視設計」の組み合わせを提案することで、実務レベルでの即効性のあるガイドラインを提供しています。
編集コメント
生成AIの利便性が高まる中で、セキュリティリスクが「偶然」から「確率的に発生する仕様」として認識されるべき時代に入ったことを示す好例です。開発チームは AI の出力を無条件で信頼せず、自動スキャンやコードレビュープロセスの見直しを急務とする必要があります。
はじめに
こんにちは、3 月に Algomatic にエンジニアとして JOIN しましたぴやてぃと申します。
普段はフロントエンドからバックエンド、インフラまでフルスタックに開発していて、最近は Claude Code をはじめとする生成 AI ツールを活用しながら日々プロダクトを作っています。AWS が好きでいつかラスベガスに行きたいです。
前回の記事はこちら、三上さんによる「LeLab で始めるノーコード模倣学習」でした。人間にとっては簡単な動作も、ロボットが学習するには一苦労なんだな、というのがわかりとても勉強になりました。（最後のロボットの動画はなんだかかわいくて愛着が湧きました）
今回は「初夏のアドベントカレンダー 20 日目」として、夏と言ったら怖い話、ということで、生成 AI で開発を進めていく会社にいるからこそ起きうる怖い話をしようかなと思います。
さてみなさん、AWS のアクセスキーどうしていますか？
個人で AWS を使っている人、個人のリポジトリにそのまま push したりしていませんか？
開発で使っている人、アクセスキーを最後に更新したのはいつですか？
アクセキーって普段あまり意識しないのですが、これが漏洩すると本当にやばいことが起きるんです。
そして厄介なことに、生成 AI を使ってコードを書くようになってこの「漏洩」の入口が一つ増えました。これまでは人間がうっかり認証情報をコミットしてしまうのが主な原因でしたが、いまは生成 AI が勝手にコードへ認証情報を混入させる、ということが起きるようになってきたのです。
しかもこれは「たまたま」ではありません。生成 AI は「一発で動くコード」を最短で出そうとするので、認証情報を環境変数やシークレットマネージャから読む正しい書き方より、そのままコードにベタ書きするほうを選びがちなのです。実際、GitHub Copilot の補完候補のうち3 回に 1 回ほどシークレットの構造を満たす文字列（API キーらしき値）が混ざっていたというGitGuardian の調査結果もあります。「人間のうっかり」だけでなく「AI の常習」として混入が起きる、というのが今の前提です。
とはいえ、生成 AI を使って開発を効率化したいですよね。私もそうです。
そこで大事になるのが、防御の仕組みをしっかり作っておくことです。具体的には「シフトレフト」と「監視設計」。この 2 つを生成 AI 時代の開発に合わせて設計しておくことが、安心して生成 AI に開発を任せるための前提になります。
1 章：API キーが漏れたら何が起きるの？
ある日、あなたは生成 AI にコードを組んでもらいました。サクッと動くコードが出てきて、いい感じです。
しかし、そのコードには AWS のアクセスキーがハードコーディングされていました。あなたはそれに気づきませんでした。
そのソースコードがそのまま Git に push され、あるいはデプロイされると、どうなるか。悪意ある攻撃者が、そのアクセスキーをすぐに抜き取ってきます。
もしもこのとき、AWS の権限が最小限に絞られていなかったら――つまり、そのキーで広い操作ができてしまう状態だったら、何が起きるでしょうか。
一番イメージしやすいのは、データを抜かれる情報漏洩でしょう。「いやでも、個人開発だし」「検証環境だから大した情報ないし」と思うかもしれません。
たしかに、扱っている情報次第ではダメージが小さく済むこともあります。でも、怖いのは情報漏洩だけではないのです。
漏れたアクセスキーを使って、攻撃者はあなたの財布（AWS アカウント）で計算資源を勝手に回すことがあります。
古典的なのが「クリプトジャッキング」と呼ばれる攻撃です。漏れたキーを使って、攻撃者があなたのアカウントの全リージョンに大量のサーバーを立て、仮想通貨のマイニングを走らせる。普段使っていないリージョンにまで展開されるので、気づいたときには手遅れ、ということが起きます。
被害額は、規模によっては数千万円に達することがあります。
最近では、この攻撃の「生成 AI 版」とも言えるLLMjackingも登場しています。漏れたキーで、被害者の費用でホスト型の LLM（Amazon Bedrock など）を勝手に呼び出す攻撃です。狙う対象がマイニング用のサーバーから LLM の推論に変わっただけで、「他人の財布で計算資源を回す」という本質はクリプトジャッキングとまったく同じです。
「でも AWS が返金してくれるんでしょ？」と思うかもしれません。
たしかに、不正利用が認められれば AWS はある程度の返金対応をしてくれます。ただし、100% 返ってくる保証はありませんし、そのためには「いつ・どのキーで・何が起きたのか」をきちんと調査して時系列で説明する必要があります。（実際やってみるとわかるのですが、結構大変な作業です…）
どうすれば防げたでしょうか？
ここで考えたいのは、「どの時点でこうなる未来を止められたか」です。
- AI がキーを埋め込んだ瞬間に気づけていたら？
- push される前に弾けていたら？
- 万が一漏れても、被害が広がる前に検知できていたら？
と言った感じで、防げるポイントはいくつかあります。
生成 AI に任せて爆速で開発するほど、人間の目視レビューは追いつかなくなるため、こうした防御を自動で・事前に効かせる仕組みが必要になってきます。次の章で具体的に見ていきましょう。
2 章：生成 AI 時代の多段防御設計
シフトレフト：発生源で弾こう
混入の発生源が AI に移った今は、コードが生まれる瞬間に防ぐことが大切です。こうして開発の早い段階（＝図でいう「左」）で問題を止める考え方をシフトレフトと呼びます。
シフトレフト自体は以前からある考え方で、できるだけ早い段階で問題を見つけよう、というものです。
本記事では、それをさらに一歩進め、AI がコードを生成する瞬間（プロンプト投入前・ツール実行前）まで検知を前倒しするという意味で用いています。
「左」側で止める必要があるのは、漏洩してからでは遅いからです。
GitGuardian の調査によると、公開された認証情報は中央値で 4 分未満で外部に発見されています。一方で、Verizon の 2025 DBIR（データ侵害インシデントレポート）によると、漏れたシークレットが修正されるまでには中央値で約 94 日かかるとされています。
具体的には、左から順に次のような防御ゲートを設置します。
(a) 生成の瞬間に弾く
まずは、AI がコードを書くタイミングです。
AI コーディングツールのフック機能を使えば、プロンプトを送る前やコマンドを実行する前にシークレットをスキャンできます。最近では ggshield の AI Hook のように、AI ワークフローへ組み込めるツールも登場しています。
(b) コミット前に弾く
次はコミット前です。
pre-commit フックでシークレットスキャンを実行します。gitleaks や TruffleHog などを使えば、git commit の時点で「API キーが混ざっていますよ」と止めてくれます。
開発者の手元で完結するので、開発体験を大きく損なわずに導入できるのもメリットです。
(c) CI で弾く
万が一ローカル環境をすり抜けても、CI（継続的インテグレーション）でシークレットスキャンや GitHub Secret Scanning / Push Protection を実行すれば、リモートリポジトリに到達する前に止められます。
「人間のレビューだけに頼らない」仕組みにしておくことがポイントです。
(d) IaC にセキュリティを焼き込む
インフラをコードで管理しているなら、そこにも防御を組み込めます。
AWS CDK や Terraform で、最小権限・長命なアクセスキーの禁止・IMDSv2 の強制といったルールを最初からコードに落とし込めます。
さらに、cdk-nag・tfsec・Checkov などを使えば、ポリシー違反をデプロイ前に自動で検知できます。最近では Amazon Inspector が SAST（静的アプリケーションセキュリティテスト）や IaC コードのスキャンを行ってくれるようになったので、これを使うのも選択肢の 1 つです。
「人間が気を付ける」のではなく、「仕組みで守る」。生成 AI で開発する今は、この考え方がこれまで以上に重要になってきたと感じています。
万が一に備えて、監視もしっかりしよう
シフトレフトはとても強力ですが、それだけで完璧というわけではありません。
そのため、漏れた後の被害を最小限にする「右」の防御も必要です。1 章で見たように、漏れたキーはコストを急激に膨らませます。ここを早期に捕まえるのが監視の役割です。
コストアラートをかけておく
AWS も推奨していますが、Cost Anomaly Detection などで異常な課金の急増を検知できるようにしておきます。1 章のクリプトジャッキングや LLMjacking は、まさに「請求額が爆発する」攻撃なので検知しやすいです。
API コールと不審な挙動を監視する
CloudTrail で API コールを記録し、GuardDuty で不審なモデル呼び出しなどを検知します。「見覚えのないリージョンからのアクセス」「普段使わない API の呼び出し」あたりは要注意のサインです。
ここで、「どんな API コールが危ないのか」を見ておきましょう。クラウドへの攻撃の多くはマルウェアを仕込むのではなく、AWS の正規の API を順番に叩くだけで進みます。つまり攻撃の足跡はほぼすべて CloudTrail に残ります。見るべきポイントは、だいたい攻撃の流れに沿って 4 つです。
- ① 探索（Discovery）：侵入直後、攻撃者は「何ができるアカウントなのか」を調べます。GetCallerIdentity（自分が誰かの確認）、ListUsers / ListRoles / GetAccountAuthorizationDetails（権限の棚卸し）、DescribeInstances / ListBuckets といった List*・Describe* 系の短時間での連発が典型的なサインです。とくに見覚えのない IP からこれが来たら要注意。
- ② 権限昇格（Privilege Escalation）：次に、奪った権限をさらに広げにきます。AttachUserPolicy / PutUserPolicy（とくに AdministratorAccess のアタッチ）、UpdateAssumeRolePolicy、sts:AssumeRole あたりが代表格です。「自分自身に管理者権限を付ける」イベントは、ほぼ一発で危険信号と考えてよいです。
- ③ 永続化（Persistence）：一度入った経路を絶たれても戻れるよう、裏口を作ります。CreateUser → CreateAccessKey の連続実行、CreateLoginProfile、AddUserToGroup（管理者グループへの追加）などが該当します。
- ④ 証拠隠滅（Defense Evasion）：暴れる前にログを止める攻撃者もいます。StopLogging / DeleteTrail / UpdateTrail が該当するイベントになります。ログが消されたという事実そのものが、強いインシデントのサインになります。
これらに加えて、失敗した API コール（AccessDenied）も見逃せません。攻撃者が権限を探って総当たりしている最中は、アクセス拒否が大量に出ます。
これらの CloudTrail のイベントを EventBridge で受け取り、該当するイベント名だったら SNS や Slack へ通知すると気づきやすいです。Amazon Q を使って、CloudTrail の危険なイベントを Slack へ要約通知するのも選択肢の 1 つです。
全リージョンを監視する
攻撃は普段使っていないリージョンで起きることもあるため、監視は全リージョンにかけておくこと。一つのリージョンだけ見ていても、攻撃者は誰も見ていない場所を狙います。
可能なら最小権限を徹底する
仮にキーが漏れても、そのキーでできることが最小限に絞られていれば、被害も最小限で済みます。ただし、ここは開発スピードとトレードオフなので要検討です。
3章：まとめ
生成AIにコードを書かせる時代になって、シークレット混入の発生源が「人間のうっかり」から「AIの常習」へ変わりました。だからこそ、多層防御を設けることでセキュリティインシデントの発生を防ぐのが大事です。
- 左（シフトレフト）：発生源で弾く
AIが書いた瞬間・コミット前・CI・IaCの各ゲートで、シークレットや危険な設定を止める。
- 右（監視）：漏れても被害を抑える
コストアラート・CloudTrail・GuardDutyなどを使った監視で、漏れた後の被害を最小化する。
ただし、この辺りの設計は開発スピードとトレードオフになります。堅牢にすればするほど、アラートの確認や権限の問題で開発スピードが落ちてしまいます。
開発を始める前に、「今回はどこまで防御するか」をチームで話しておけるといいのかなと思います。
私は、こうした防御設計は、開発にブレーキをかけるためのものではなく、むしろ生成AIで爆速に開発するためのものだと思っています。
「漏らさない・漏れても広がらない」仕組みが自動で・事前に効いているからこそ、私たちは安心してAIにコードを書かせ、開発を進められます。防御がないまま走るのは、ブレーキのない車でアクセルを踏むようなものです。怖くて結局スピードは出せません。
生成AIで開発を加速させるために、防御の設計を最初にしっかりやっておくのが大切です。
参考文献
本文中でも触れていますが、参考にした主な情報源です。
- Yes, GitHub's Copilot can Leak (Real) Secrets - GitGuardian Blog
- The State of Secrets Sprawl 2025 - GitGuardian Blog
- 2025 Data Breach Investigations Report (DBIR) - Verizon
- LLMjacking: Stolen Cloud Credentials Used in New AI Attack - Sysdig
- The Growing Dangers of LLMjacking - Sysdig
- ggshield - GitHub
- gitleaks - GitHub
- TruffleHog - GitHub
- Push protection for repositories and organizations - GitHub Docs
- cdk-nag - GitHub
- tfsec - GitHub
- Checkov
- AWS CloudTrail User Guide - AWS Documentation
- Detecting unusual spend with AWS Cost Anomaly Detection - AWS Documentation
- What is Amazon GuardDuty? - AWS Documentation
- Security best practices in IAM - AWS Documentation
- MITRE ATT&CK
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では6月に体勢が変わり、「AI時代の企業OSを作る」という新しいミッションに向かって一緒に走っていけるエンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
原文を表示
はじめに
こんにちは、3月にAlgomaticにエンジニアとしてJOINしましたぴやてぃと申します。
普段はフロントエンドからバックエンド、インフラまでフルスタックに開発していて、最近はClaude Codeをはじめとする生成AIツールを活用しながら日々プロダクトを作っています。AWSが好きでいつかラスベガスに行きたいです。
前回の記事はこちら、三上さんによる「LeLabで始めるノーコード模倣学習」でした。人間にとっては簡単な動作も、ロボットが学習するには一苦労なんだな、というのがわかりとても勉強になりました。（最後のロボットの動画はなんだかかわいくて愛着が湧きました）
今回は「初夏のアドベントカレンダー20日目」として、夏と言ったら怖い話、ということで、生成AIで開発を進めていく会社にいるからこそ起きうる怖い話をしようかなと思います。
さてみなさん、AWSのアクセスキーどうしていますか？
個人でAWSを使っている人、個人のリポジトリにそのままpushしたりしていませんか？
開発で使っている人、アクセスキーを最後に更新したのはいつですか？
アクセスキーって普段あまり意識しないのですが、これが漏洩すると本当にやばいことが起きるんです。
そして厄介なことに、生成AIを使ってコードを書くようになってこの「漏洩」の入口が一つ増えました。これまでは人間がうっかり認証情報をコミットしてしまうのが主な原因でしたが、いまは生成AIが勝手にコードへ認証情報を混入させる、ということが起きるようになってきたのです。
しかもこれは「たまたま」ではありません。生成AIは「一発で動くコード」を最短で出そうとするので、認証情報を環境変数やシークレットマネージャから読む正しい書き方より、そのままコードにベタ書きするほうを選びがちなのです。実際、GitHub Copilotの補完候補のうち3回に1回ほどシークレットの構造を満たす文字列（APIキーらしき値）が混ざっていたというGitGuardianの調査結果もあります。「人間のうっかり」だけでなく「AIの常習」として混入が起きる、というのが今の前提です。
とはいえ、生成AIを使って開発を効率化したいですよね。私もそうです。
そこで大事になるのが、防御の仕組みをしっかり作っておくことです。具体的には「シフトレフト」と「監視設計」。この2つを生成AI時代の開発に合わせて設計しておくことが、安心して生成AIに開発を任せるための前提になります。
1章：APIキーが漏れたら何が起きるの？
ある日、あなたは生成AIにコードを組んでもらいました。サクッと動くコードが出てきて、いい感じです。
しかし、そのコードにはAWSのアクセスキーがハードコーディングされていました。あなたはそれに気づきませんでした。
そのソースコードがそのままGitにpushされ、あるいはデプロイされると、どうなるか。悪意ある攻撃者が、そのアクセスキーをすぐに抜き取ってきます。
もしもこのとき、AWSの権限が最小限に絞られていなかったら――つまり、そのキーで広い操作ができてしまう状態だったら、何が起きるでしょうか。
一番イメージしやすいのは、データを抜かれる情報漏洩でしょう。「いやでも、個人開発だし」「検証環境だから大した情報ないし」と思うかもしれません。
たしかに、扱っている情報次第ではダメージが小さく済むこともあります。でも、怖いのは情報漏洩だけではないのです。
漏れたアクセスキーを使って、攻撃者はあなたの財布（AWSアカウント）で計算資源を勝手に回すことがあります。
古典的なのが「クリプトジャッキング」と呼ばれる攻撃です。漏れたキーを使って、攻撃者があなたのアカウントの全リージョンに大量のサーバーを立て、仮想通貨のマイニングを走らせる。普段使っていないリージョンにまで展開されるので、気づいたときには手遅れ、ということが起きます。
被害額は、規模によっては数千万円に達することがあります。
最近では、この攻撃の「生成AI版」とも言えるLLMjackingも登場しています。漏れたキーで、被害者の費用でホスト型のLLM（Amazon Bedrockなど）を勝手に呼び出す攻撃です。狙う対象がマイニング用のサーバーからLLMの推論に変わっただけで、「他人の財布で計算資源を回す」という本質はクリプトジャッキングとまったく同じです。
「でもAWSが返金してくれるんでしょ？」と思うかもしれません。
たしかに、不正利用が認められればAWSはある程度の返金対応をしてくれます。ただし、100%返ってくる保証はありませんし、そのためには「いつ・どのキーで・何が起きたのか」をきちんと調査して時系列で説明する必要があります。（実際やってみるとわかるのですが、結構大変な作業です…）
どうすれば防げたでしょうか？
ここで考えたいのは、「どの時点でこうなる未来を止められたか」です。
- AIがキーを埋め込んだ瞬間に気づけていたら？
- pushされる前に弾けていたら？
- 万が一漏れても、被害が広がる前に検知できていたら？
と言った感じで、防げるポイントはいくつかあります。
生成AIに任せて爆速で開発するほど、人間の目視レビューは追いつかなくなるため、こうした防御を自動で・事前に効かせる仕組みが必要になってきます。次の章で具体的に見ていきましょう。
2章：生成AI時代の多段防御設計
シフトレフト：発生源で弾こう
混入の発生源がAIに移った今は、コードが生まれる瞬間に防ぐことが大切です。こうして開発の早い段階（＝図でいう「左」）で問題を止める考え方をシフトレフトと呼びます。
シフトレフト自体は以前からある考え方で、できるだけ早い段階で問題を見つけよう、というものです。
本記事ではそれをもう一歩進めて、AIがコードを生成する瞬間（プロンプト投入前・ツール実行前）まで検知を前倒しする、という意味で使っています。
「左」で止める必要があるのはなぜか、それは漏れてからでは遅いからです。
GitGuardianの調査では、公開された認証情報は中央値4分未満で外部に発見されています。一方で、Verizonの2025 DBIRによると、漏れたシークレットが修正されるまでには中央値で約94日かかるとされています。
具体的には、左から順に次のような防御ゲートを置きます。
(a) 生成の瞬間に弾く
まずは、AIがコードを書くタイミングです。
AIコーディングツールのHook機能を使えば、プロンプトを送る前やコマンドを実行する前にシークレットをスキャンできます。最近ではggshieldのAI Hookのように、AIワークフローへ組み込めるツールも登場しています。
(b) コミット前に弾く
次はコミット前です。
pre-commitフックでシークレットスキャンを実行します。gitleaksやTruffleHogなどを使えば、git commitの時点で「APIキーが混ざっていますよ」と止めてくれます。
開発者の手元で完結するので、開発体験を大きく損なわずに導入できるのもメリットです。
(c) CIで弾く
万が一ローカルをすり抜けても、CIでシークレットスキャンやGitHub Secret Scanning / Push Protectionを実行すれば、リモートに到達する前に止められます。
「人間のレビューだけに頼らない」仕組みにしておくことがポイントです。
(d) IaCにセキュリティを焼き込む
インフラをコードで管理しているなら、そこにも防御を組み込めます。
AWS CDKやTerraformで、最小権限・長命なアクセスキーの禁止・IMDSv2の強制といったルールを最初からコードに落とし込めます。
さらに、cdk-nag・tfsec・Checkovなどを使えば、ポリシー違反をデプロイ前に自動で検知できます。最近ではAmazon InspectorがSASTやIaCコードのスキャンを行ってくれるようになったので、これを使うのも選択肢の1つです。
「人間が気を付ける」のではなく、「仕組みで守る」。生成AIで開発する今は、この考え方がこれまで以上に重要になってきたと感じています。
万が一に備えて、監視もしっかりしよう
シフトレフトはとても強力ですが、それだけで完璧というわけではありません。
そのため、漏れた後の被害を最小限にする「右」の防御も必要です。1章で見たように、漏れたキーはコストを急激に膨らませます。ここを早期に捕まえるのが監視の役割です。
コストアラートをかけておく
AWSも推奨していますが、Cost Anomaly Detection などで異常な課金の急増を検知できるようにしておきます。1章のクリプトジャッキングやLLMjackingは、まさに「請求額が爆発する」攻撃なので検知しやすいです。
APIコールと不審な挙動を監視する
CloudTrailでAPIコールを記録し、GuardDutyで不審なモデル呼び出しなどを検知します。「見覚えのないリージョンからのアクセス」「普段使わないAPIの呼び出し」あたりは要注意のサインです。
ここで、「どんなAPIコールが危ないのか」を見ておきましょう。クラウドへの攻撃の多くはマルウェアを仕込むのではなく、AWSの正規のAPIを順番に叩くだけで進みます。つまり攻撃の足跡はほぼすべてCloudTrailに残ります。見るべきポイントは、だいたい攻撃の流れに沿って4つです。
- ① 探索（Discovery）：侵入直後、攻撃者は「何ができるアカウントなのか」を調べます。GetCallerIdentity（自分が誰かの確認）、ListUsers / ListRoles / GetAccountAuthorizationDetails（権限の棚卸し）、DescribeInstances / ListBuckets といった List*・Describe* 系の短時間での連発が典型的なサインです。とくに見覚えのないIPからこれが来たら要注意。
- ② 権限昇格（Privilege Escalation）：次に、奪った権限をさらに広げにきます。AttachUserPolicy / PutUserPolicy（とくに AdministratorAccess のアタッチ）、UpdateAssumeRolePolicy、sts:AssumeRole あたりが代表格です。「自分自身に管理者権限を付ける」イベントは、ほぼ一発で危険信号と考えてよいです。
- ③ 永続化（Persistence）：一度入った経路を絶たれても戻れるよう、裏口を作ります。CreateUser → CreateAccessKey の連続実行、CreateLoginProfile、AddUserToGroup（管理者グループへの追加）などが該当します。
- ④ 証拠隠滅（Defense Evasion）：暴れる前にログを止める攻撃者もいます。StopLogging / DeleteTrail / UpdateTrail が該当するイベントになります。ログが消されたという事実そのものが、強いインシデントのサインになります。
これらに加えて、失敗したAPIコール（AccessDenied）も見逃せません。攻撃者が権限を探って総当たりしている最中は、アクセス拒否が大量に出ます。
これらのCloudTrailのイベントをEventBridgeで受け取り、該当するイベント名だったらSNSやSlackへ通知すると気づきやすいです。Amazon Qを使って、CloudTrailの危険なイベントをSlackへ要約通知するのも選択肢の1つです。
全リージョンを監視する
攻撃は普段使っていないリージョンで起きることもあるため、監視は全リージョンにかけておくこと。一つのリージョンだけ見ていても、攻撃者は誰も見ていない場所を狙います。
可能なら最小権限を徹底する
仮にキーが漏れても、そのキーでできることが最小限に絞られていれば、被害も最小限で済みます。ただし、ここは開発スピードとトレードオフなので要検討です。
3章：まとめ
生成AIにコードを書かせる時代になって、シークレット混入の発生源が「人間のうっかり」から「AIの常習」へ変わりました。だからこそ、多層防御を設けることでセキュリティインシデントの発生を防ぐのが大事です。
- 左（シフトレフト）：発生源で弾く
AIが書いた瞬間・コミット前・CI・IaCの各ゲートで、シークレットや危険な設定を止める。
- 右（監視）：漏れても被害を抑える
コストアラート・CloudTrail・GuardDutyなどを使った監視で、漏れた後の被害を最小化する。
ただし、この辺りの設計は開発スピードとトレードオフになります。堅牢にすればするほど、アラートの確認や権限の問題で開発スピードが落ちてしまいます。
開発を始める前に、「今回はどこまで防御するか」をチームで話しておけるといいのかなと思います。
私は、こうした防御設計は、開発にブレーキをかけるためのものではなく、むしろ生成AIで爆速に開発するためのものだと思っています。
「漏らさない・漏れても広がらない」仕組みが自動で・事前に効いているからこそ、私たちは安心してAIにコードを書かせ、開発を進められます。防御がないまま走るのは、ブレーキのない車でアクセルを踏むようなものです。怖くて結局スピードは出せません。
生成AIで開発を加速させるために、防御の設計を最初にしっかりやっておくのが大切です。
参考文献
本文中でも触れていますが、参考にした主な情報源です。
- Yes, GitHub's Copilot can Leak (Real) Secrets - GitGuardian Blog
- The State of Secrets Sprawl 2025 - GitGuardian Blog
- 2025 Data Breach Investigations Report (DBIR) - Verizon
- LLMjacking: Stolen Cloud Credentials Used in New AI Attack - Sysdig
- The Growing Dangers of LLMjacking - Sysdig
- ggshield - GitHub
- gitleaks - GitHub
- TruffleHog - GitHub
- Push protection for repositories and organizations - GitHub Docs
- cdk-nag - GitHub
- tfsec - GitHub
- Checkov
- AWS CloudTrail User Guide - AWS Documentation
- Detecting unusual spend with AWS Cost Anomaly Detection - AWS Documentation
- What is Amazon GuardDuty? - AWS Documentation
- Security best practices in IAM - AWS Documentation
- MITRE ATT&CK
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では6月に体勢が変わり、「AI時代の企業OSを作る」という新しいミッションに向かって一緒に走っていけるエンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み