Google も含め、誰もがリアルタイムで AI セキュリティに対処している
Google Cloud の COO は、AI セキュリティを後付けではなくプラットフォーム設計の初期段階から統合し、マルチクラウド環境における統一的なガバナンスと「シャドウ AI」対策の重要性を強調した。
キーポイント
セキュリティの早期統合とプラットフォームアプローチ
AI セキュリティは後付けや個人の裁量に任せるべきではなく、戦略の初期段階からデータ戦略・ガバナンス・監査可能性を備えたプラットフォームとして構築する必要がある。
シャドウ AI とマルチクラウド環境への対応
従業員が管理外の消費者向けツールを利用する「シャドウ AI」のリスクに対し、単一クラウド依存ではなく、SaaS やパートナー企業を含む多様な環境全体で統一的なセキュリティ姿勢を維持することが不可欠である。
攻撃速度の劇的変化と新たな脅威領域
初回侵入から次段階への移行時間が 8 時間から 22 秒に短縮され、モデル、データパイプライン、エージェント、プロンプトなど従来のネットワーク境界外が新たな保護対象となっている。
AI エージェントによる忘却データの露呈リスク
内部システムを自律的に移動する AI エージェントが、長年放置されていた古いデータリポジトリ(例:SharePoint サーバー)やアクセス制御の不備を発見・利用する新たな脅威が指摘された。
AI エージェントによる忘却データの露出リスク
企業内の古いデータリポジトリや更新されていないアクセス制御を、AI エージェントが探索して発見し、意図せずデータを曝露する新たな脅威が存在する。
人間主導から AI ネイティブ防御への転換
セキュリティ対策は人間の速度では追いつかないため、AI エージェントが防御を駆動し、人間がそれを監督する「AI ネイティブで完全自律的な防御」へ移行する必要がある。
プラットフォーム側の予期せぬ請求と設定変更
Google Cloud において、API キーの範囲拡大や自動課金ティアの引き上げにより、ユーザーが意図せず高額な請求を受ける事例が相次いでいる。
重要な引用
Security is not something you can bolt on later, and it's not something you can leave up to employees to do on their own.
There's no such thing as an AI strategy without a data strategy and a security strategy. They need to go hand in hand.
The average time between an initial breach and the handoff to the next stage of an attack has dropped from eight hours to 22 seconds.
"A lot of organizations have old SharePoint servers [and access controls] they haven't really updated, but it didn't matter because nobody really knew where they were. But agents roaming your enterprise will find those data assets and will expose the data on them."
"We're now seeing the emergence of an AI-native, fully agentic defense where organizations can run agents driving their defense... Instead of having a human-led defense or even a human in the loop, you can now have humans overseeing a fully agentic defense."
attackers can apparently continue using that key for up to 23 minutes because Google's revocation propagates gradually across its infrastructure
影響分析・編集コメントを表示
影響分析
この記事は、Google Cloud の経営陣による提言を通じて、企業における AI セキュリティの考え方を「事後対応」から「設計段階での統合」へと根本的に転換させる必要性を浮き彫りにしています。特に攻撃速度の劇的な短縮と、AI エージェントがもたらす新たなデータ露出リスクは、従来のネットワークセキュリティモデルの見直しを迫る重要な示唆を含んでおり、今後数年間の AI ガバナンス戦略の方向性を決定づける内容です。
編集コメント
Google の COO が「後付けは不可能」と断言した点は、業界全体が直面している共通の課題を象徴しており、単なる製品宣伝を超えた本質的な警鐘となっています。特に攻撃時間が秒単位に短縮されたというデータは、セキュリティ担当者が即座に戦略を見直すべき強力な根拠となります。
私は最近、ロサンゼルスのイベントの裏側で、Google Cloud のCOOであるフランシス・デ・ソウザ氏と座談する機会を得ました。イベントの周囲の騒音の中で、大学教授のような落ち着いた、計画的な話し方をするデ・ソウザ氏は、私たちが今まさに生きているAIセキュリティの局面を企業どう乗り切るかについて有用な助言をくれました。「移行期間があり、その後、私たちはより良い場所に行き着けると思います」と彼は述べました。
彼はその瞬間にGoogleについて話していたわけではありませんが、Googleでさえもまだ物事を模索していることは明らかです。
デ・ソウザ氏の核心的なメッセージは、セキュリティ専門家が何年もかけて経営陣に理解させようとしてきたものでしたが、AIによって緊急性が増しています。セキュリティは後付けの考えであってはならないのです。「企業がこのAIの旅に出る際、プラットフォームアプローチを取る必要があります」と彼は言いました。「セキュリティは後に付け加えるものでもなく、従業員に任せて各自で行わせるようなものでもありません。」彼は特に「シャドウAI」— 組織の監督なしに消費者向けツールを利用する従業員 — について警告し、企業は最初からプラットフォームに対してセキュリティ、ガバナンス(管理・統制)、監査可能性を要求すべきだと主張しました。「データ戦略とセキュリティ戦略のないAI戦略など存在しません。これらは一体となって進められる必要があります。」
注目に値する点:彼は Google Cloud だけを訴えていたわけではありません。彼のアドバイスがまるで Google の広告のように聞こえると私が指摘した際、彼は反論しました。Google はマルチクラウドアプローチにコミットしており、単一のクラウド上で運営していると考えている企業はほぼ確実にそうではないと主張しました。「たとえ単一のクラウドを選んでも、SaaS アプリケーションに依存しており、ビジネスパートナーの中には異なるクラウドを使用しているところもある」と彼は述べました。「企業がクラウド間、モデル間で一貫したセキュリティ姿勢を持つことは重要です。」
また、脅威の状況が根本的に変化し、従来の防御モデルでは遅すぎるとも主張しました。彼は、最初の侵害から攻撃の次の段階への引き継ぎまでの平均時間が 8 時間から 22 秒に短縮されたと指摘し、攻撃対象領域が従来のネットワーク境界を大きく超えて拡大したと述べました。「通常の資産に加え、今やモデルがあります。モデルを訓練するためのデータパイプラインもあります。エージェントもあり、プロンプトもあります。これらすべてを保護する必要があります。」
デ・ソウザ氏が指摘した、十分に注目されていない脅威の一つは、エージェントが企業の内部システムを移動する際に、何年も誰も気にしていなかったデータリポジトリが表面化することです。「多くの組織には、長年更新されていない古い SharePoint サーバー [およびアクセス制御] がありますが、どこにあるのか誰も知らなかったので問題にはなりませんでした。しかし、企業内を徘徊するエージェントはそれらのデータ資産を見つけ出し、そこに保存されたデータを露呈させてしまいます。」
彼の考えでは、その答えは機械の速度で機械の速度に対処することです。「現在、組織が防御を駆動するエージェントを実行できる、AI ネイティブで完全な自律型防御の出現が見られています」と彼は述べました。「人間主導の防御、あるいは人間の関与を含む防御ではなく、現在は人間が完全な自律型防御を見守る体制が可能になっています。」さらに、これは単なる技術的な問題ではなく、リーダーシップの問題になったと付け加えました。「これは取締役会レベルおよび経営陣レベルの課題です。セキュリティチームだけの問題ではありません。」
しかし、AI が防御業務の多くを担うようになる一方で、それを監督できる資格を持つ人材は不足しており、AI 自体がもたらす脆弱性がセキュリティチームの対応速度を上回るペースで増殖しています。LinkedIn のチーフインフォメーションセキュリティオフィサーであるリー・キスナー氏は今週、『ニューヨーク・タイムズ』に対して「バグ・アポカリプス(虫食い終末)に対処できる人材が必要になります」と語り、業界が AI セキュリティを少なくとも数年間は持続可能な長期的な方法で理解できるとは考えていないと付け加えました。
これがプラットフォームプロバイダー自身へと話を戻します。The Register は過去数週間にわたり、Gemini モデルへの不正な API 呼び出しにより 5 桁の請求書を受け取った Google Cloud の開発者たちに関する一連のレポートを公開しました。これらのサービスは、多くの開発者が一度も使用したことがなく、意図的に有効化していたものでもありませんでした。これらの事例にはよくあるパターンが見られました:Google Maps 用に展開された API キーが、Google 自身の指示に従って公に置かれていたものが、Google がそのスコープを拡大して Gemini へのアクセスが可能になったにもかかわらず、この変更を明確に開示しなかったために、静かに Gemini にアクセスできる状態になっていたのです。
インタビュー準備プラットフォーム「Prentus」のCEOであるRod Danan氏は、攻撃者が彼の乗っ取られたAPIキーを悪用した結果、約30分間で請求額が10,138ドルに達したと語っています。シドニー在住の開発者Isuru Fonseka氏も同様にアカウントが乗っ取られ、250ドルの支出上限を設定していると考えていたにもかかわらず、目覚めた時には約17,000豪ドルの請求額に直面しました。二人とも知らなかったのは、Googleの自動システムがアカウント履歴に基づいて課金ティアをアップグレードし、明示的な同意なしに実質的な上限を最大10万ドルまで引き上げていたという事実です。
The Register が最初の報告書を公開した後、Google は両者に対して返金を行いました。それでもなお、Google は The Register に対し、自動的なティアアップグレードポリシーを変更する予定はないと伝えました。その理由として、ユーザーが設定した予算優先事項を厳格に適用することよりも、サービスの停止を防ぐことを最優先しているためだと説明しています。
その一方で、開発者がシステムを停止させようとした際に何が起こるのかという別の問題もあります。The Register は今週、セキュリティ企業 Aikido の調査結果について報じました。それによると、侵害されたキーに気づいて即座に削除した開発者であっても、安全とは限りません。Aikido の調査結果によれば、攻撃者はそのキーを最大 23 分間使い続けることができる可能性があります。これは Google の失効処理がインフラ全体に段階的に伝播するためです。
Aikido の研究者である Joseph Leon は The Register に対し、この時間窓の間は成功率が予測不能であり、ある分ではリクエストの 90% 以上が依然として認証されている場合もあると語りました。また、攻撃者はこの時間を活用して Gemini からファイルを転送したり、キャッシュされた会話データを盗み出したりできると指摘しています。
Leon はさらに、Google の最新の資格情報フォーマットには同様の問題がないとも述べています。サービスアカウントの API 資格情報は約 5 秒で失効し、Gemini の新しい AQ プレフィックス付きキー形式では約 1 分かかります。「どちらも Google スケールで動作しています」と彼は Aikido の関連論文に記しました。「両方とも、Google API キーについても技術的に解決可能であることを示唆しています。」要するに、Leon によれば、この 23 分の時間窓はエンジニアリング上の制約ではなく、同社の優先順位の問題なのです。
これは、デ・ソウザのアドバイスを読む際に考慮する価値があります。彼のアドバイスは妥当であり、非常に真剣に受け止めるべきものです。彼が間違っているわけではありませんが、現在、プラットフォームが推奨することと、それらが自分自身で適応する速度との間にギャップがあり、この点にも注意を払うことは有益です。
*当記事内のリンクを通じてご購入いただいた場合、私たちは少額のコミッションを獲得する可能性があります。これは私たちの編集の独立性には影響しません。
原文を表示
I recently had the opportunity to sit down with Francis de Souza, COO of Google Cloud, backstage at an eventin Los Angeles. Amid the din around us, de Souza, who speaks in the calm, measured manner of a university professor, offered useful advice for companies navigating the AI security moment we’re all living through, noting that “there’ll be a transition period, and then I think we get to this better place.”
He wasn’t speaking about Google at that moment, but it’s clear that even Google is still figuring things out.
De Souza’s core message was one security professionals have been trying to get executives to internalize for years, now made urgent by AI: security can’t be an afterthought. “As companies embark on this AI journey, they need to take a platform approach,” he said. “Security is not something you can bolt on later, and it’s not something you can leave up to employees to do on their own.” He warned specifically about “shadow AI” — employees reaching for consumer tools without organizational oversight — and argued that companies need to demand security, governance, and auditability from their platforms from the start. “There’s no such thing as an AI strategy without a data strategy and a security strategy. They need to go hand in hand.”
Worth noting: he wasn’t pitching Google Cloud alone. When I observed that his advice sounded like a Google advertisement, he pushed back. Google, he said, is committed to a multicloud approach, and he made the case that companies that think they’re operating on a single cloud almost certainly aren’t. “Even if they pick a single cloud, they’re relying on SaaS applications, there are business partners that may be using different clouds,” he said. “It’s important for companies to have a security posture that is consistent across clouds, across models.”
He also made the case that the threat landscape has changed so fundamentally that old defensive models are too slow. He noted that the average time between an initial breach and the handoff to the next stage of an attack has dropped from eight hours to 22 seconds, and that the attack surface has expanded well beyond the traditional network perimeter. “In addition to your usual estate, you have models now. You have data pipelines used to train the models. You have agents, you have prompts. All of this needs to be protected.”
One threat de Souza flagged that doesn’t get enough attention: agents moving through a company’s internal systems can surface forgotten data repositories that nobody has thought about in years. “A lot of organizations have old SharePoint servers [and access controls] they haven’t really updated, but it didn’t matter because nobody really knew where they were. But agents roaming your enterprise will find those data assets and will expose the data on them.”
The answer, in his view, is to meet machine speed with machine speed. “We’re now seeing the emergence of an AI-native, fully agentic defense where organizations can run agents driving their defense,” he said. “Instead of having a human-led defense or even a human in the loop, you can now have humans overseeing a fully agentic defense.” He added that this has become a leadership issue, not just a technology one. “This is a board-level issue and an executive team issue. It’s not just a security team’s issue.”
But even as AI takes on more of the defensive workload, the people qualified to oversee it are in short supply — and the vulnerabilities that AI itself is introducing are multiplying faster than security teams can address them. “We’re going to need people to deal with the bug-pocalypse,” LinkedIn’s chief information security officer Lea Kissner told the New York Times this week, adding that she doesn’t expect the industry to understand AI security in any sustainable long-term way for at least several years.
Which brings us back to the platform providers themselves. The Register has published a series of reports over the past several weeks documenting a wave of Google Cloud developers hit with five-figure bills following unauthorized API calls to Gemini models — services many of them had never used or intentionally enabled. The cases followed a familiar pattern: API keys originally deployed for Google Maps, placed publicly per Google’s own instructions, had quietly become capable of accessing Gemini after Google expanded their scope without clearly disclosing the change.
Rod Danan, CEO of interview-prep platform Prentus, said his bill hit $10,138 in roughly 30 minutes after attackers exploited his compromised API key. Isuru Fonseka, a Sydney-based developer whose account was similarly compromised, woke up to charges of roughly AUD $17,000 despite believing he had a $250 spending cap in place. What neither knew was that Google’s automated systems had upgraded their billing tiers based on account history, raising their effective ceilings to as high as $100,000 without explicit consent.
Google refunded both after The Register published its initial report. Still, Google told The Register it has no plans to change its automatic tier-upgrade policy, saying it prioritizes preventing service outages over enforcing users’ stated budget preferences.
In the meantime, there is the separate question of what happens when a developer tries to shut things down. The Register reported this week on research by security firm Aikido finding that even developers who catch a compromised key and immediately delete it may not be safe. According to Aikido’s findings, attackers can apparently continue using that key for up to 23 minutes because Google’s revocation propagates gradually across its infrastructure. Aikido researcher Joseph Leon told The Register that during that window, success rates are unpredictable — in some minutes over 90% of requests still authenticated — and attackers can use the time to exfiltrate files and cached conversation data from Gemini.
Leon also noted that Google’s own newer credential formats don’t appear to have the same problem: service account API credentials revoke in about five seconds, and Gemini’s newer AQ-prefixed key format takes about a minute. “Both run at Google scale,” he wrote in Aikido’s related paper. “Both suggest this is technically solvable for Google API keys, too.” In short, according to Leon, the 23-minute window isn’t an engineering constraint but a matter of priorities for the company.
That’s worth considering when reading de Souza’s advice, which is sound and should be taken very seriously. He’s not wrong, but there is currently a gap between the platforms are prescribing and how fast they are themselves adapating, and it’s good to be aware of this, too.
*When you purchase through links in our articles, we may earn a small commission. This doesn’t affect our editorial independence.*
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み