Googleが長年にわたり「APIキーは秘密ではない」と説明してきたが、Geminiの登場で状況が一変した。Truffle Securityの調査によると、Google MapsやFirebaseなどで使われる公開用APIキー（AIza...形式）が、GeminiのAPIにアクセスする認証資格として機能するようになり、意図せずセキュリティリスクが拡大している。同社は2025年11月のCommon Crawlデータセットを分析し、2,863個の公開されたGoogle APIキーがGeminiにアクセス可能であることを確認。これらのキーは当初、バッティングやリファラー制限で保護される「プロジェクト識別子」として設計されており、開発者に「クライアント側に埋め込んでも安全」と明言されてきた。 しかし、Gemini APIがプロジェクトに有効化されると、既存のAPIキーが自動的にGeminiの機密エンドポイントにアクセスできるようになり、警告や承認プロセスなしに権限が拡張される。この「リトロアクティブな権限拡張」は、開発者が意図せず、かつ気づかぬうちにセキュリティリスクを抱える状況を生んだ。さらに、新規キーのデフォルト設定が「無制限」であるため、悪意ある攻撃者が公開ページからキーをスクレイピングするだけで、アップロードファイルの閲覧、キャッシュデータの取得、AI利用料金の不正請求が可能になる。 調査チームはGoogle自身のウェブサイトにも同様のキーが公開されていることを発見。2023年から公開されていたキーで、Gemini APIのモデル一覧取得に成功。Googleは当初「意図された動作」と反論したが、実例を提示した後、12月に「バグ」と認定し、対策を開始。2026年2月時点で根本的修正を検討中だが、既存キーの再評価やユーザーへの通知は未実施。 この問題は、AI機能が既存インフラに追加される際、旧来の認証設計が危険にさらされる典型例。開発者は、Google CloudプロジェクトにGemini APIが有効化されているかを確認し、公開されているキーにGeminiアクセス権が付与されていないかを点検すべき。また、TruffleHogなどのツールでコードやWebページをスキャンし、実際の有効性を確認する必要がある。Googleは将来、キーの分離や新たな認証アーキテクチャの導入を計画しているが、現時点ではユーザー自身の対応が不可欠である。