何も侵入されていない。すべて持ち去られた。
漏洩した低権限の AWS キーひとつを AI エージェントに渡すと、約 1 分で、誰の手も借りずに顧客データへ至る連鎖をたどります。侵入は一切なく、使われた資格情報はすべて有効です。漏洩キーの経済性は、いま反転しました。
漏洩した AWS キーひとつ——CI パイプラインが毎週こぼしているような、低権限で使い捨てられる種類のもの——を AI エージェントに渡し、到達できるものはすべて持ってこいと指示します。そして、その場を離れます。多くの場合、約 1 分後には誰もキーボードに手を置いていない状態で、そのエージェントは顧客データを読み込んでいます。
そこに至るために侵入されたものは何もありません。エクスプロイトも、CVE も、未パッチのサーバーも存在しません。エージェントが触れた資格情報はすべて有効で、発行された API 呼び出しはすべて、AWS が応答するように設計されているものでした。30 年にわたり、漏洩したキーは攻撃の入り口にすぎませんでした——人間が起きていなければならない遅い段階であり、セキュリティチームが生きる余地があり、迅速なローテーションが競争に勝てる隙間でした。その隙間が、約 1 分にまで縮まりました。
2026 年 5 月、Adan Álvarez という研究者が簡単なテストを実施しました。低権限の AWS キーをひとつ——CI/CD パイプラインが頻繁に漏らす種類のもの——取り、AI コーディングエージェントに、こういう指示だけを添えて渡しました。ペネトレーションテスターとして振る舞い、到達できるものを見つけよと。以降、キーボードに人間はいません。残りはエージェントが行いました。2 回に 1 回以上の割合で、エージェントは顧客データに至る連鎖の全体をたどり切りました——約 1 分で、無人のままです。
実際に何が起きたか
構成は意図的に平凡なものでした。漏洩したキーは、低権限のビルドユーザーに属していました。それだけでは顧客データには触れられません。しかし Terraform のステートファイルを読むことはできました。そのステートファイルには 2 つ目のキーの組が保存されていました。そのキーでロールを引き受けられました。そのロールは顧客バケットを読み取れました。
これは、ほぼすべての実在のクラウドアカウントの形です——一枚の城壁ではなく、小さく妥当な信頼関係の連なりであり、それぞれのリンクは単独では合理的です。人間の攻撃者はその連鎖を手作業で、時間をかけてほどきます。エージェントはそれを約 60 秒でほどきました。
成功した実行は、毎回同じ 6 つの手順を踏みました。キーの所有者を確認し、許可されている操作を列挙し、ステージングバケットから 2 つ目の資格情報を復元し、権限のあるロールを引き受け、データを見つけ、持ち出す。2 つのモデルで 12 回の実行を行ったうち、7 回が持ち出しに到達しました。大半は約 1 分で完了しました [1]。
これは実験室の中だけの結果でもありません。2025 年 11 月、Sysdig の脅威リサーチチームは、同じ形が実際の環境で展開されるのを観測しました。公開バケットに露出した有効な AWS キー、管理用の資格情報を発行するよう静かに書き換えられた Lambda 関数、19 個の別個の ID にわたる横移動——すべてが 8 分で完了しています [2][3]。注入されたコードにはモデルの指紋が残っていました。整然とした例外処理、反復的なターゲット選定ロジック、複数の言語で書かれたコメントです。
これは AWS の脆弱性ではない
夜も眠れなくなるべきなのはここです。何も侵入されていません。
エクスプロイトはなく、CVE もありません。バッファオーバーフローもなく、未パッチのサーバーもありません。資格情報はすべて有効でした。API 呼び出しはすべて、AWS が応答するように設計されているものでした。Sysdig の表現を借りれば、資格情報は正当であり、API は意図どおりに使用されたものです [3]。AWS は完璧に機能しました。
崩れた前提は AWS のセキュリティではありませんでした。その下にある、もっと古く、もっと静かな前提でした。漏洩したキーの危険性は、攻撃者が割ける注意力の範囲にとどまるというものです。30 年間、これは成り立ちました。資格情報の悪用には人間が必要でした——時間、技術、忍耐です。そのコストは防御の実質的な一部でしたが、アーキテクチャ図に描かれることは決してありませんでした。
エージェントはそのコストをおおよそゼロにします。忍耐は無限で、技術は分単位で借りられます。攻撃者は眠っていても構いません。
AWS に限った話ではない
ここに Amazon 固有のものは何もありません。同じ連鎖は、資格情報を使って次の資格情報を発見できる場所であればどこでも成立します。自身の権限を列挙できるクラウドキー、別のプロセスが読める .env ファイル中のトークン、ステートファイルの中の秘密情報、コードの隣でディスクに置かれている vault トークンです。ハーネスはいずれも——コーディングエージェント、先週インストールした MCP サーバー——連鎖をたどる存在になり得ます。あなたの許可があろうとなかろうとです。
共通しているのは、秘密情報それ自体が影響範囲を内包していることです。作業が行われる場所で読め、触れたものを列挙でき、どこからでも機能します。攻撃が遅く手作業だった時代には、この 3 つの性質は許容可能でした。エージェントの速度では許容可能ではありません。
意図的に、このために設計した
そこで、あえて逆のものを構築しました。
Clavitor の資格情報には、エージェントに渡された名前によってのみ到達できます。ストアを列挙できないため、地図を描くこともできません。秘密値がコードの実行場所に置かれることはなく、エージェントには資格情報を使う結果だけが渡り、資格情報そのものは渡りません。各資格情報は、発行されたマシンとスコープに結び付けられているため、ノートパソコンへ持ち出されたコピーは無価値です。そして、すべての要求は改変不能なハッシュチェーン・エンドポイント外のログに記録されます——PCI DSS Req 10 と NIST 800-171 (3.3.8) が求める証跡です——これにより、完全に「有効」な操作であっても、実行者名が伴います。
正直に述べれば、これによって漏洩した資格情報が無害になるわけではありません。キーを 1 つのバケットにスコープすれば、そのキーが漏洩すれば、攻撃者はその 1 つのバケットを手に入れます。ここで破壊されるのは連鎖です——1 つのありふれたキーが、他のすべてへの地図になる部分です。スコープされた資格情報と環境全体に及ぶ資格情報の違いは、安全と侵害の違いではありません。それは、インシデントと大惨事の違いです。
この状況を生き延びるための、資格情報ツールが守るべき少数のルールを書きまとめました。皆様の環境のツールを照らし合わせるには clavitor.ai/rules をご覧ください。
教訓は「ローテーションを速める」ではない
60 秒の攻撃に、ローテーションでは勝てません。カナリアが発火するころには、連鎖はすでに完了しています。
持ち帰るべきことは、より厳密な後始手順ではありません。経済性が反転したという事実です。私たちは、攻撃者の時間が希少で高価な世界のために資格情報システムを構築してきました——漏洩キーは勝ち目のある競争だった世界です。その世界は終わりました。次の資格情報を見つけられる資格情報は、もはや利便性ではありません。それ自体が攻撃全体であり、あらかじめ書かれた状態で、いずれかのキーが落ちるのを待っています。
攻撃者が眠らない世界に向けて構築してください。その世界は、すでにここに来ています。
Clavitor (@clavitorai) は、AI エージェントのために、そして AI エージェントに対して構築された資格情報ボールトです。clavitor.ai
出典
[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?"(2026 年 5 月) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678
[2] CSO Online — "From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html
[3] Vectra AI — "AWS Compromised by AI Agents in Minutes"(Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes
[4] Help Net Security — "The shocking speed of AWS key exploitation" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/