Selbst Google kann nicht mehr mithalten – Die Sicherheit im Zeitalter der KI ist zu einem "sekündlichen" Kampf geworden.

Sogar Google tritt in eine Ära des „Schutzes während des Laufens“ ein

KI ist gleichzeitig ein Werkzeug zur Steigerung der Produktivität von Unternehmen und eine neue Angriffsfläche für Sicherheitsverantwortliche. Generative KI, interne Agenten, Lerndaten, Eingabeaufforderungen, externe SaaS und Multi-Cloud-Umgebungen. Früher konzentrierte sich der Schutz auf Netzwerkgrenzen, Endgeräte, Server und Identitätsmanagement, doch heute erstreckt sich der Schutz auf „alles, womit KI in Berührung kommt“.

Die von TechCrunch berichteten Aussagen von Google Cloud COO Francis de Souza spiegeln diesen Wandel wider. Er betonte, dass Sicherheit von Anfang an in die Plattformgestaltung integriert werden sollte, wenn Unternehmen KI einführen, und nicht nachträglich hinzugefügt werden sollte. „Schatten-KI“, die unkontrollierte Nutzung externer KI-Tools durch Mitarbeiter, Datenmanagement über mehrere Clouds, Prüfungsfähigkeit und Governance sind bereits Risiken, die nicht nur von der IT-Abteilung, sondern auch von der Führungsebene und dem Vorstand behandelt werden müssen.

Besonders wichtig ist, dass die Einführung von KI nicht nur als „praktische neue Funktionserweiterung“ angesehen werden kann. Sobald KI-Agenten in der Lage sind, sich durch interne Systeme zu bewegen, besteht die Möglichkeit, dass alte, vergessene Datenspeicher, nicht aktualisierte Zugriffsrechte, verlassene SharePoint-Ordner und alte Geschäftsdokumente ans Licht kommen. Daten, die bisher „kein Problem darstellten, weil sie niemand fand“, werden durch KI plötzlich sichtbar. Das bedeutet, dass KI nicht nur Angreifer, sondern auch „vergangene Managementfehler“ innerhalb des Unternehmens schnell aufdecken kann.

Angriffe verlaufen nicht mehr in „Stunden“, sondern in „Sekunden“

De Souza erklärt, dass die durchschnittliche Zeitspanne vom Eindringen bis zum nächsten Angriffsabschnitt von früheren Stunden auf Sekunden geschrumpft ist. Dies hat eine immense Bedeutung für Sicherheitsverantwortliche. Während Menschen Alarme überprüfen, die Situation bewerten, Beteiligte zusammenrufen, Entscheidungen treffen und manuell blockieren, ist der Angriff bereits in die nächste Phase übergegangen.

In diesem Kontext schlägt Google Cloud eine „KI-native Verteidigung“ vor. Anstatt dass Menschen alles direkt steuern, überwachen, verteidigen und reagieren KI-Agenten, während Menschen diese überwachen. Wenn Angriffe mit Maschinengeschwindigkeit erfolgen, muss auch die Verteidigung mit Maschinengeschwindigkeit arbeiten.

Dieser Ansatz ist zwar rational, birgt jedoch auch große Widersprüche. Um mit KI zu schützen, muss diese selbst sicher sein. Die Daten, auf die KI zugreift, die APIs, die sie aufruft, die Authentifizierungsinformationen, die sie verwendet, und das Abrechnungssystem, das ihre Nutzung verwaltet – wenn es in diesen Grundlagen Lücken gibt, wird die KI-Verteidigung zu einem neuen Risiko anstatt zu einem Schutz.

Der Zusammenbruch der „alten Annahmen“, wie das Problem mit dem Gemini-API-Schlüssel zeigt

Der TechCrunch-Artikel ist interessant, weil er nicht nur die Sicherheitsempfehlungen von Google Cloud vorstellt, sondern auch auf Probleme eingeht, mit denen Google selbst konfrontiert ist. Besonders beachtet wurde die Reihe von Vorfällen mit hohen Rechnungen im Zusammenhang mit der Gemini-API.

Im Mittelpunkt des Problems steht der Umgang mit API-Schlüsseln von Google Cloud. Lange Zeit war es bei Google Maps oder Firebase nicht ungewöhnlich, dass API-Schlüssel im Client-Code eingebettet wurden. Für Entwickler fühlte sich das nicht unbedingt wie eine „Veröffentlichung von Passwörtern“ an. Sie wurden eher als öffentlich zugängliche Schlüssel für die Dienstidentifikation und Abrechnung behandelt.

Doch wenn teure KI-Dienste wie die Gemini-API im selben Projekt aktiviert werden, könnten bestehende API-Schlüssel auch für KI-Anfragen verwendet werden. Wenn diese Schlüssel in altem JavaScript von Websites, öffentlichen Repositories oder alten Einstellungen verbleiben, könnten Angreifer sie finden und eine große Anzahl von Anfragen an Gemini oder Bild- und Videogenerierungsmodelle senden, was zu enormen Kosten auf dem Abrechnungskonto der Entwickler führen könnte.

Dies ist nicht nur eine Frage von „Entwicklern, die die Schlüsselverwaltung vernachlässigt haben“. Einige Entwickler folgten den damaligen Dokumentationen und gängigen Praktiken, als sie die Schlüssel verwendeten. Ein Identifikator, der als öffentlich angesehen wurde, erhielt später eine Rolle, die der Authentifizierung für teure KI-Dienste nahekommt. Hier liegt die Schwierigkeit der Sicherheit im KI-Zeitalter. Ein Design, das bis gestern sicher war, kann durch die Hinzufügung neuer Funktionen heute gefährlich werden.

Das Misstrauen gegenüber „Limits“, die keine sind

Ein weiteres Problem, das das Misstrauen der Entwickler verstärkte, waren die Fragen zu Nutzungslimits und Abrechnungslimits. Laut einem Bericht von The Register gab es Fälle, in denen Google Cloud-Entwickler aufgrund unbefugter API-Nutzung Rechnungen in Höhe von mehreren Tausend bis Zehntausend Dollar erhielten. In einigen Fällen stieg die Nutzung, die normalerweise bei etwa 50 Dollar pro Monat lag, in kurzer Zeit auf über 10.000 Dollar an, oder ein Limit von etwa 250 Dollar wurde automatisch auf ein höheres Nutzungslimit angehoben, basierend auf dem Kontoverlauf.

Googles Argumentation ist, dass dies dazu dient, Dienstunterbrechungen zu vermeiden und wachsenden Kunden eine reibungslose Nutzungserweiterung zu ermöglichen. In der Tat können starre Limits für legitime Dienste, deren Traffic plötzlich ansteigt, hinderlich sein. In einer Ära, in der KI-Anwendungen schnell wachsen, kann die automatische Erweiterung der Nutzungslimits auch die Entwicklererfahrung verbessern.

Doch im Moment des Missbrauchs wirkt dieses Design in die entgegengesetzte Richtung. Für Angreifer erweitert sich der Spielraum für die Nutzung gestohlener Schlüssel. Für die Nutzer entsteht das Gefühl, dass „es nicht aufhört, obwohl ein Limit gesetzt wurde“. Die stärkste Reaktion in den sozialen Medien konzentrierte sich ebenfalls auf diesen Punkt. Entwickler fordern „echte Limits, die nicht nur Alarme auslösen, sondern tatsächlich stoppen“.

Die Wut und Angst, die sich auf Reddit ausbreitete

Im Reddit-Forum r/googlecloud häufen sich die Beiträge zu hohen Rechnungen im Zusammenhang mit der Gemini-API und Google Cloud. Ein Nutzer erklärte, dass er ein B2B-SaaS betreibt und die Google Cloud-Rechnung, die normalerweise etwa 50 Dollar pro Monat beträgt, durch Veo 3 und Gemini-Bildausgabe-Token auf über 10.000 Dollar anstieg. Er selbst nutzte diese Dienste nicht in seinem Produkt und wandte sich an den Google-Support, um unbefugte Nutzung zu melden, erhielt jedoch zunächst die Antwort, dass „keine Beweise für Missbrauch gefunden wurden“.

In einem anderen Beitrag wurde berichtet, dass ein alter API-Schlüssel für Google Maps nach der Aktivierung der Gemini-API missbraucht wurde, was zu einer Rechnung von etwa 36.800 Euro führte. In den Kommentaren äußerten sich Nutzer überrascht darüber, dass „dieses Problem bereits gemeldet wurde, aber das Verhalten sich noch nicht geändert hat“, und andere sagten: „Die Google Cloud Console macht mir Angst. Ich kann einem Schlüssel, der Zehntausende von Dollar verursachen kann, nicht vertrauen.“

Ein Nutzer, der sich als kleines japanisches Unternehmen ausgibt, sah sich ebenfalls mit einer Rechnung von etwa 128.000 Dollar aufgrund unbefugter Nutzung der Gemini-API konfrontiert und erwähnte sogar die Möglichkeit einer Insolvenz. In den Kommentaren war die Meinung vorherrschend, dass Google eine Möglichkeit bieten sollte, eine harte Grenze zu setzen, die ein Projekt oder eine API sicher stoppt, sobald ein bestimmter Betrag überschritten wird. Mit der Verbreitung von KI-Codierungstools und der zunehmenden Nutzung von Google Cloud durch Entwickler wird die Annahme, dass „jeder seine Schlüssel perfekt schützen kann“, immer unrealistischer.

Die Reaktionen auf Reddit beinhalteten nicht nur Wut, sondern auch praktische Lösungen zur Vermeidung von Problemen. Vorschläge waren, auf Servicekonten oder restriktivere Authentifizierungsmethoden umzusteigen, die Gemini-API auf Organisationsebene zu deaktivieren, öffentliche Dienste und KI-Nutzung in separate Projekte zu trennen und immer API-Beschränkungen festzulegen. Die Community diente also nicht nur als Plattform zur Kritik an Googles Vorgehen, sondern auch zum Austausch von Selbstschutzmaßnahmen.

Auf Hacker News ist die Kritik an der „Designphilosophie“ stark

Auf Hacker News war die Diskussion stärker auf die Designphilosophie fokussiert. In einem Thread über die Untersuchung von Truffle Security wurde kritisiert, dass Google API-Schlüssel lange Zeit als „öffentlich zugängliche Identifikatoren“ behandelt wurden, aber durch Gemini effektiv zu Schlüsseln für teure KI-Nutzung und Datenzugriff wurden.

Ein Kommentar verglich die Situation mit der Möglichkeit, für jeden API-Schlüssel klare Ausgabenobergrenzen von 10 oder 100 Dollar festzulegen. Es wurde darauf hingewiesen, dass bei OpenAI oder OpenRouter die Ausgabenverwaltung pro Schlüssel oder Konto einfacher ist und dass die Abrechnungsalarme von Google Cloud verzögert sind und daher keine wirkliche Barriere darstellen.

Es verbreitete sich auch die Kritik, dass „dies wie die Verwendung eines Benutzernamens als Passwort ist“. Natürlich gibt es auch Gegenargumente, dass es zu einfach wäre, die gesamte Verantwortung auf Google zu schieben. Die Gemini-API wird nicht standardmäßig für alle Projekte aktiviert; der Projektinhaber muss sie aktivieren. Daher gibt es auch starke Meinungen, dass Projekte getrennt, Schlüssel eingeschränkt und das Prinzip der minimalen Rechte beachtet werden sollten.

Insgesamt überwiegt jedoch die Ansicht, dass „alte Cloud-Praktiken“ durch KI gefährlich geworden sind. Öffentlich zugängliche Schlüssel, teure KI-Schlussfolgerungen, verzögerte Abrechnungsdaten und automatisch erweiterte Nutzungslimits – auch wenn diese Spezifikationen einzeln erklärbar sind, ergeben sie zusammen ein tödliches Risiko für kleine Entwickler.

Das Problem der „23 Minuten“, das nicht endet, selbst wenn der Schlüssel gelöscht wird

Eine weitere Untersuchung von Aikido Security wirft zusätzliche Bedenken auf. Laut ihren Tests kann es bis zu etwa 23 Minuten dauern, bis einige Anfragen nach dem Löschen eines Google API-Schlüssels weiterhin authentifiziert werden. In großen verteilten Systemen ist es nicht ungewöhnlich, dass es Zeit braucht, bis sich Konfigurationsänderungen auf alle Server ausbreiten. Doch bei der Ungültigmachung von Authentifizierungsinformationen wird diese Verzögerung direkt zur Angriffszeit.

Selbst wenn ein Angreifer einen durchgesickerten Schlüssel besitzt und der Nutzer den Schlüssel in Panik löscht, könnte der Angreifer weiterhin eine große Anzahl von Anfragen senden. Wenn die Gemini-API aktiviert ist, besteht nicht nur das Risiko von Kosten, sondern auch von Zugriff auf hochgeladene Dateien oder zwischengespeicherte Gesprächsinhalte.

Dieser Punkt liegt nahe am Kern der KI-Sicherheit. Bei herkömmlichen Cloud-Ressourcen mag eine Verzögerung von einigen Minuten in bestimmten Situationen akzeptabel gewesen sein. Doch Anfragen an KI-Modelle sind teuer und die Daten hochsensibel. In wenigen Minuten könnte ein Angreifer eine große Menge an Schlussfolgerungen durchführen. Im KI-Zeitalter ist die Vorstellung von „letztlich konsistenter“ Authentifizierung sowohl aus Kosten- als auch aus Datenschutzgründen riskant.

Googles Vorschläge sind richtig. Gerade deshalb werden sie hinterfragt

Hier ist wichtig zu betonen, dass die Vorschläge von Google Cloud COO nicht falsch sind. Eine KI-Strategie erfordert eine Datenstrategie und eine Sicherheitsstrategie, und Schatten-KI darf nicht ignoriert werden. Eine konsistente Sicherheitsposition sollte über Multi-Cloud, SaaS, externe Partner und interne Agenten hinweg eingenommen werden. Da Angriffe mit Maschinengeschwindigkeit erfolgen, muss auch die Verteidigung KI nutzen.

Das Problem ist, inwieweit die Plattformanbieter selbst eine sichere Grundlage bieten können, um diese richtigen Vorschläge umzusetzen. Wenn Unternehmen gesagt wird, „Sicherheit nicht nachträglich hinzuzufügen“, dann muss auch die Cloud-Seite vermeiden, dass „durch das nachträgliche Hinzufügen von KI-Funktionen die bestehende Authentifizierungs- und Abrechnungsstruktur gefährlich wird“.

Diese Kontroverse betrifft nicht nur Google. Es ist eine Warnung, die für alle Cloud-Anbieter, KI-Plattformen und SaaS-Unternehmen gilt. Wenn KI-Funktionen in bestehende Dienste integriert werden, müssen die alten Designannahmen unbedingt überprüft werden. Schlüssel, die öffentlich sein dürfen, Schlüssel, die nur intern verwendet werden, Abrechnungslimits, Datenzugriffsbereiche, Ungültigkeitsprozesse, Prüfprotokolle, Supportsysteme. Wenn die vor-KI-Ära-Praktiken unverändert übernommen werden, wird es irgendwo zu einem Zusammenbruch kommen.

Was Unternehmen und Entwickler jetzt sofort überprüfen sollten

Die praktischen Lehren aus diesem Problem sind klar. Erstens, Projekte, die KI aktivieren, von Projekten zu trennen, die für öffentliche Frontends oder Dienste wie Maps und Firebase verwendet werden. Zweitens, für alle API-Schlüssel API-Beschränkungen und Anwendungsbeschränkungen festzulegen und unnötige APIs zu deaktivieren. Drittens, nicht nur Abrechnungsalarme, sondern tatsächliche Ausgabenlimits oder Quoten zu überprüfen, die den Dienst stoppen. Viertens, alte Schlüssel in alten Websites, Repositories und mobilen Apps zu inventarisieren. Fünftens, bei der Nutzung von KI statt API-Schlüsseln auf Servicekonten, OAuth und minimal berechtigte Authentifizierungsdesigns zu setzen.

Und das Management muss die Einführung von KI nicht als „praktisches Werkzeug für den Arbeitsplatz“, sondern als Infrastrukturänderung behandeln, die finanzielle Risiken und Risiken von Datenlecks birgt. Wenn das Leck eines einzigen Schlüssels zu Rechnungen im Millionenbereich oder zum Verlust vertraulicher Daten führen kann, dann ist das ein Thema nicht nur für CISO und Entwicklungsteams, sondern auch für CFO, Rechtsabteilung und Managementmeetings.

Die wirkliche Herausforderung der KI-Sicherheit liegt nicht im „Geschwindigkeitsunterschied“, sondern im „Design der Verantwortung“

Die Sicherheit im KI-Zeitalter wird zweifellos in Echtzeit umgesetzt. Angriffe sind schnell, und auch die Verteidigung muss schnell sein. Doch die wirkliche Herausforderung liegt nicht nur in der Geschwindigkeit. Wer trägt das Risiko, wer hat die Befugnis, zu stoppen, was ist standardmäßig sicher, welche Priorität hat das Design zur Vermeidung von Störungen gegenüber dem Design zur Verhinderung von Missbrauch? Es geht um das „Design der Verantwortung“.

Sogar Google tastet sich durch diese Übergangsphase. Deshalb ist es gefährlich, wenn andere Unternehmen unvorbereitet KI einführen. KI kann schützen, KI kann erkennen, KI kann automatisieren. Doch bevor man solche Erwartungen hegt, muss man zuerst die Authentifizierung, Abrechnung, Daten, Berechtigungen und Prüfmechanismen rund um KI überprüfen.

KI-Sicherheit ist keine Zukunftsfrage. Wir sind bereits in einer Phase, in der ein einziger API-Schlüssel, ein altes Projekt oder ein verzögerter Alarm über das Überleben eines Unternehmens entscheiden kann.

Quellen-URL

TechCrunch „Everyone is navigating AI security in real