キーは一度も失効しなかった

Truffle Security が今週センサス（実態調査）を公開し、 BleepingComputer が木曜にそれを取り上げた。 2022 年 8 月以降、同社は AWS のアクセスキーが公開の場に現れる場所、すなわち git の履歴、 Hugging Face のデータセット、Docker イメージ、パッケージレジストリ、CI ログから収集を続けてきた。 そのうえで、まだ使えるかどうかを確かめた。

報告書 は検証済みの AWS 検出 431,875 件を数え、重複を除いて 50,654 の異なるアカウントにまたがる 64,024 個の ユニークなアクセスキーにまとめている。そのうち 10,616 組が再テストに足る材料を備えていた。その 88% が今も認証を通る。つまり 9,308 個のキーが、この四年のどこかで誰でも公開の場から拾えた状態のまま、 今日も生きている。

検証の範囲は狭く保たれ、読み取り専用のメタデータ呼び出しだけが使われた。 sts:GetCallerIdentity、iam:ListAccessKeys、ポリシー名の列挙、予算の読み取り、アカウントごとに Cost Explorer 呼び出し一回。データは一切読まず、何も変更せず、公開前に 10,616 人のうち 10,260 人の 所有者へ通知している。

次に、キーの古さを見てほしい。

五年、そしてまだ続く

いまも動くキーの年齢の中央値は 1,831 日。最古のものは 17.4 年。この集合のうち直近三十日以内のものは 25 個、1% の十分の九にすぎない。

この分布が描いているのは、新しい事故が次々に捕まって片づけられていく流れではなく、堆積物だ。キーは 漏れたら漏れたままになる。AWS の静的アクセスキーには失効がないからだ。時計もなく、更新もなく、 十八か月で古びる証明書もない。誰かがコンソールを開いて削除するまで、そのキーは動き続ける。Truffle は その「誰か」がどれくらいの頻度で現れるかを測った。研究者が列挙できたユーザーのうち、漏えいしたキーの 隣に新しいキーを持っていたのは 2,903 人中 398 人、13.7% である。残る 2,505 人は一度もローテーション していない。

これを検知の段階のせいにすることもできない。発見はすでに Amazon が済ませていたからだ。AWS は自社の キーが公開の場にあるのを見つけると、そのユーザーに AWSCompromisedKeyQuarantine というポリシーを 付与し、キーにできることを絞り込み、アカウントへメールを送る。誰かが頼む必要はない。Truffle は、 アクティブな 7,590 人の 12% にあたる 929 人の IAM ユーザーが、今まさにそのポリシーを身にまとって いるのを見つけた。そのうち 112 人は初期版のポリシーを付けており、つまり AWS は少なくとも三年前に 彼らを警告していて、それでもキーはまだ応答する。

検知は働き、メールは送られ、そして三年後もキーはまだ使える。

漏えい面は、削除ボタンのない場所へ移った

センサス全体で最大の単独ソースは Hugging Face だった。3,394 のデータセットにまたがる 8,482 個の ユニークな有効キー、そして 17.9% というルートキー率で、これは他の集団を大きく上回る。

Truffle はこの配管の先の方をすでに測っていた。6 月にチームは Hugging Face の公開データセットをすべてクローンした。 1 億 8,690 万個のユニークファイル、7.6 ペタバイト、およそ 815,000 のデータセットリポジトリである。 Parquet、Arrow、JSONL、アーカイブをスキャン可能なテキストに展開し、見つけたものをすべて検証した。 結果は 6,003 のデータセットに存在する 221,303 件の有効かつユニークな資格情報だった。内訳は AI プロバイダーのキーが 11,496 件、3,811 プロジェクトにまたがる Google Cloud のサービスアカウントキーが 8,557 件、実際に使えるデータベースのログイン情報が 8,594 件、STS の ID チェックを通る AWS キーが 3,343 件、GitHub の個人アクセストークンが 349 件で、うち 223 件はコードを push でき、130 件は CI ワークフローを書き換えられる。

彼らの挙げた二つの例が、たった一つのミスがどこまで旅をするかを示している。ある人がブラジルの フィンテック企業の AWS キーをチャットボットに貼り付け、それは今や異なるコーパスにおよそ十八回 複製されて現れる。同じ経路で捕まった Infura のキーは、1,131 のデータセットと 10,162 か所の ファイル位置に行き着いた。Truffle が見つけたユニークな有効秘密の 44% は、複数のデータセットに 現れている。

そして人々はそのデータセットで学習を回す。StarCoder の公開された学習データにはこれらのキーが 25,217 件、Swallow には 22,484 件、OLMo 3 には 21,278 件含まれる。大手のプロプライエタリなモデルは コーパスを非公開にしているので、外部の誰にもわからない。

Truffle の結論は身も蓋もない。ローテーションだけが唯一の対処である。学習データを遡って掃除できる者は いないからだ。公開リポジトリ、ウェブページ、チャットボットに一度でも届いたキーは、焼けたものとして 扱うしかない。

そのリストに並ぶソースは、どれもエージェントが書くものだ

Truffle がどこへ買い物に行ったかをもう一度見てほしい。git の履歴、Docker イメージ、パッケージ レジストリ、CI ログ、データセットのアップロード。これらはビルドの出力であり、いまやコーディング エージェントが、人の目が届かないまま夜通し、どんなチームもレビューしきれない速度で生み出している 成果物そのものだ。

あなたが寝ている間にバックログを片づけるエージェントは、コミットを書き、ロックファイルを書き換え、 イメージをビルドし、ブランチを push し、ログを埋めていく。そのどれもが公開面であり、その間ずっと エージェントの手元には ~/.aws/credentials がある。SDK がそれを見つけるように設計されているから だ。

コーディングエージェントはこれらの成果物を、かつてのどんなツールよりも速く書く。そして 13.7% は 動いていない。

署名する側の半分は、あなたの Mac に残る

Bromure Agentic Coding はエージェントを、Apple の Virtualization フレームワーク上の使い捨て Ubuntu VM で走らせ、外への経路はホスト側のプロキシだけにする。この設計では AWS だけ扱いが特別になる。 SigV4 は秘密を回線に載せない。SDK がプロセス内でそれを消費して HMAC を計算するからで、通信の途中で プロキシが差し替えられるものは何もない。そこで Bromure は署名そのものを動かす。

VM の中では、~/.aws/config が credential_process ヘルパーを指す。SDK が資格情報を求めると、 ヘルパーは本物のアクセスキー ID と、セッションごとに新しく作られる 40 文字の偽の秘密鍵を組にして 返す。アクセスキー ID は識別子であって秘密ではなく、どの IAM ユーザーが呼んでいるかを示す側の半分 である。シークレットアクセスキーは署名する側の半分であり、そちらは VM のアドレス空間に一度も入らな い。Bromure は AWS_ACCESS_KEY_ID も AWS_SECRET_ACCESS_KEY もゲストの環境変数に渡しさえしない。 環境変数は /proc、ps -E、シェル履歴から漏れるからだ。VM が受け取るのはリージョンの文字列だけ である。

SDK は、署名が正しくなりようのないリクエストに署名する。外へ出る際にホストがその署名を剥がし、本物 の材料で SigV4 を計算し直す。aws も boto3 も terraform も普段どおり動く。プロキシを迂回したものは Amazon から InvalidSignatureException を受け取る。それこそが望ましい失敗の形だ。

ここで Bromure のワークスペースを Truffle の方法論にかけてみよう。彼らがキーを 1 件と数える基準は、 署名済みの sts:GetCallerIdentity が有効として返ってくることだ。侵害された依存パッケージがゲストの 資格情報ファイルを収穫したとしよう。あるいはエージェントが言いくるめられてそれを cat したとしよう。 あるいはビルドがそれを公開バンドルに埋め込んだとしよう。外へ出るのは識別子と、はじめから秘密では なかった 40 文字だけだ。それは漏れたその日に失敗するので、堆積層に加わることは決してなく、その後ろに 五年の尾が伸びることもない。

これは、人間を待つローテーションの手順も取り除く。本物の秘密鍵は一か所、あなたの Mac のプロファイル の資格情報ペインにだけ存在する。そこで変えれば次のセッションが拾う。九十回の夜間実行のうちどれが どの成果物を書いたのかを、誰かが突き止める必要はない。

署名するキーより狭い、署名済みリクエスト

センサスのもう一つの見出しは到達範囲だ。企業に紐づく 817 個のキーのうち、768 個がアカウントの完全な 制御を与えていた。内訳はルートキーが 526 個、AdministratorAccess を持つ IAM ユーザーが 242 人。 そのルートキーのうち 130 個は組織管理アカウント、つまり組織内のすべてのメンバーアカウントを統べる アカウントのものだ。研究者が列挙できたユーザー全体では、976 人、率にして 84% が AdministratorAccess を持っていた。

これらは何年も前に、三つの権限で足りる作業のために、便宜上つくられたキーである。

Bromure の Guardrails 設定は、資格情報を使用の時点で狭める。だから、発行元で狭めるのを覚えておく 必要がない。これはプロキシの中にあるホスト側のポリシーエンジンだ。AWS については、DynamoDB や Lambda のような JSON プロトコルのサービスでは X-Amz-Target ヘッダーから、EC2、IAM、SQS のような クエリプロトコルのサービスでは Action= パラメーターからアクション名を読み、S3 では HTTP メソッドに フォールバックする。Delete*、Terminate*、Remove*、Purge*、Destroy* は破壊的に分類され、 Get*、List*、Describe* は読み取りに分類される。プロファイルを読み取り専用にすれば、変更 操作は硬い 403 として返り、エージェントはそれをありふれた API の失敗として読む。破壊的操作を ブロックにすれば、作成と更新は通り、削除は通らない。

これを強制するのはあなたの Mac であって VM ではない。だから何かを言いくるめられたエージェントが、 理屈をこねて通り抜けることはできない。ホストが署名に使う資格情報は、資格情報そのものより狭くなる。 列挙できたユーザーの 84% が管理者権限を持っていた集団を思えば、これは持っておく価値がある。

記録は請求書より先に現れる

報告書からもう一つ数字を。研究者が予算を読めた 2,754 のアカウントのうち、予算アラートを設定して いるのはそもそも 262 件、9.5% にすぎず、その上限の中央値は八ドルだった。同じ集合が 7 月に使った額は 420,631 ドル、1,000 ドル超が五十アカウント、10,000 ドル超が九アカウントある。所有者の多くは、 侵入者と請求書の上で出会うことになる。

Bromure は作業が進むそばから記録を書く。ホストが署名したリクエストはすべて、ウィンドウ → セキュリティタイムラインに credential.aws_sign の行を出す。そこにはサービス、メソッド、ホスト、 リージョン、マスクされたアクセスキー ID が載り、パッケージの取得、ファイアウォールの判定、資格情報の 差し替えと並ぶ。Bromure はこのログを Mac 側に置くので、VM の中の何ものもそれを編集できない。より 厳しい形が必要なら、AWS → 使用時に承認を求めるが署名呼び出しのたびに同意プロンプトを出し、期限 付きの許可を与えるので、本気で作業する午後でも聞かれるのは一度で済む。

Bromure は同じ考えを一段階手前、プロファイルを最初に立ち上げるときにも適用する。取り込んだエージェント 設定をリダクション（伏せ字化）にかけるのだ。構造化された JSON、TOML、YAML はキー名で、つまり token、secret、password、apikey、credential、authorization、private_key、access_key に一致するものを濾し取り、地の文はトークンの形、つまり AKIA、ASIA、sk-ant-、ghp_、glpat-、 AIza、npm_ に一致するものを濾し取る。あなたの Mac のドットファイルにどんな本物の秘密が入って いようと、それが設定の残りと一緒に VM へ乗り込むことはない。

センサスが証明したこと

Truffle Security の進め方は真っ当だった。読み取り専用の呼び出し、データには一切触れず、公開前に 10,616 人のうち 10,260 人の所有者へ通知。AWS も見出しが思わせるより良い振る舞いをしている。隔離 ポリシーとは、Amazon が頼まれもせず自社の漏えいキーを見つけ、所有者に警告している姿だからだ。検知の 両半分とも、仕事をしていた。

それでも結果は、年齢の中央値が五年の有効なキー 9,308 個と、13.7% というローテーション率だった。

うまくいっていない管理策は、ミスから数か月あるいは数年も経ってから、もはや本人のものではないかも しれないシステム上で、何の問題も示さないキーのために、人間に面倒な作業を求める。この形の管理策は 規模の前で壊れる。しかも、何かが夜通しコミットを書き始めるより前から壊れていた。

だから、面倒な作業に重さを背負わせるのはもうやめよう。はじめから資格情報ではなかった資格情報を ワークスペースに置けば、センサスに数えるものはなくなり、コーパスに複製するものはなくなり、五年の尾は 誰か別の人のものになる。

---

出典: Truffle Security「Leaked Corporate AWS Keys Held Full Admin Rights」（2026 年 8 月 19 日） · Truffle Security「Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets」（2026 年 6 月 1 日） · Truffle Security「Introducing TruffleHog AWS Analyze」（2026 年 8 月 20 日） · BleepingComputer「Hundreds of leaked AWS keys give full control over corporate accounts」（2026 年 8 月 21 日） · Cybernews「Massive exposure: researchers test leaked AWS keys, 9 out of 10 still authenticate」（2026 年 8 月 21 日）