Kategorie: KI-News

Wer mit JavaScript oder Node.js arbeitet, kennt den Moment: Man tippt npm install in die Konsole. Das ist der universelle Ausdruck digitalen Vertrauens – ein Knopfdruck, der bedeutet, dass man ein paar Kilobyte fremden Codes in sein Projekt lädt. Meist funktioniert das reibungslos. Doch Microsoft Threat Intelligence hat eine Kampagne dokumentiert, die genau diese Vertrauensbasis angreift. Die Attacke ChainDrop, ein npm-Supply-Chain-Angriff, hat Hunderte Pakete kompromittiert. Der Angreifer manipulierte nicht nur einzelne Bibliotheken, sondern installierte eine selbstverbreitende Malware, die sich wie ein Wurm durch das Ökosystem frisst. Ein einzelner gestohlener Token genügte, um aus einem harmlosen Patch ein massives Sicherheitsproblem für Entwicklerteams weltweit zu machen.

Warum ein Preinstall-Skript zum Einfallstor wird

Um die Gefahr zu verstehen, muss man sich den Lebenszyklus eines npm-Pakets ansehen. Vor der Installation prüft npm die Paketdefinition, die package.json. Dort dürfen Entwickler neben dem Code auch Lifecycle-Hooks definieren – Skripte, die automatisch ausgeführt werden. Kritisch ist der preinstall-Hook, denn er läuft, bevor das Paket final in das Projekt geschrieben wird. Genau hier hat sich der Angreifer eingenistet. Die bösartigen Paketversionen, die im Rahmen von ChainDrop veröffentlicht wurden, schleusen über diesen Hook ein unbekanntes Skript ein, das eine große, stark verschleierte JavaScript-Datei lädt. Laut Microsoft handelt es sich um einen Bun-basierten Payload mit dem Codenamen „Mini Shai-Hulud“. Dieser Code ist nicht darauf ausgelegt, nur einmal zu laufen. Er prüft zunächst, ob er sich auf einer Entwickler-Workstation oder in einer CI/CD-Umgebung befindet. Auf einem lokalen Rechner löst er sich vom Installationsprozess und läuft im Hintergrund weiter. In einer Build-Pipeline bleibt er bewusst im aktiven Prozess, um Workflow-Secrets und OIDC-Berechtigungen zu erbeuten. Der Angriff nutzt keine ausgefallene Sicherheitslücke, sondern die normale Funktionsweise des Paketmanagers – den impliziten Konsens, dass Skripte bei der Installation ausgeführt werden dürfen.

Der Wurm greift um sich: Ein Token, unzählige Pakete

Die Gefahr dieser Malware liegt in ihrer Fähigkeit, sich selbst zu replizieren. Nachdem der Payload auf einem System Fuß gefasst hat, sucht er systematisch nach Zugangsdaten. Er liest lokale Dateien, Shell-Historien, SSH-Schlüssel, Umgebungsvariablen und den Speicher des GitHub Actions Runners. Diese Daten sind die Grundlage für den nächsten Schritt: die Authentifizierung gegenüber externen Diensten. Der Wurm testet, ob er mit den gestohlenen npm-Tokens Schreibrechte besitzt. Ist das der Fall, kommt der entscheidende Automatismus zum Zug. Er kontaktiert die npm-Registry, listet alle Pakete auf, die der kompromittierten Identität gehören, lädt die neuesten Tarballs herunter, fügt den eigenen Malware-Code hinzu, erhöht die Patch-Version und veröffentlicht das manipulierte Paket erneut. Das ist der Kern des „selbstverbreitenden Wurms“. Ein einziger kompromittierter Publisher-Account kann so innerhalb kürzester Zeit hunderte scheinbar legitime Patch-Updates produzieren. Die Analyse zeigt: Über 400 Pakete waren über mehrere voneinander unabhängige Publisher hinweg betroffen. Die Angreifer haben die Token-Hierarchie des Ökosystems verstanden. Für Außenstehende sehen diese Releases aus wie gewöhnliche Versionssprünge, weil sie im Patch-Modus stattfinden. Es gibt keinen Quellcode-Commit, kein Pull Request, keinen Tag. Die Tarballs wurden direkt in der Registry ersetzt, was die forensische Aufarbeitung erschwert.

Datendiebstahl und Persistenz: Die Technik hinter der Tarnung

Abgesehen von der Replikation ist der Wurm ein hocheffizienter Datenspion. Die gestohlenen Anmeldedaten für AWS, Kubernetes, HashiCorp Vault oder GitHub nutzt er nicht nur zur Bestätigung seiner Existenz, sondern zur aktiven Erkundung. Er ruft API-Schnittstellen auf, validiert die Rechte und zieht alle Geheimnisse ab, die mit der jeweiligen Identität erreichbar sind. Die Übertragung der gesammelten Daten erfolgt verschlüsselt: Der Wurm erzeugt einen zufälligen 256-Bit-AES-Schlüssel, verschlüsselt die Daten damit und verschlüsselt diesen Schlüssel anschließend mit einem öffentlichen RSA-Schlüssel des Angreifers. Als Zielserver dient eine dynamische HTTPS-Endpunkt-Adresse, die sich über einen Smart Contract (0xE1f2395ee43e45A1556EC6438a88c31B83493103) oder einen kryptografisch signierten GitHub-Commit ändern lässt. Sollte dieser Kanal nicht erreichbar sein, gibt es einen Fallback: Der Wurm veröffentlicht die verschlüsselten Daten als JSON-Dateien in einem öffentlichen GitHub-Repository mit der Beschreibung „Shai-Hulud: Here We Go Again“. Diese Redundanz sorgt dafür, dass die Operation auch unter widrigen Netzwerkbedingungen fortgesetzt werden kann. Doch damit nicht genug. Um nach der eigentlichen Infektion bestehen zu bleiben, injiziert der Payload schädliche Konfigurationsdateien in Claude- und Visual Studio Code-Verzeichnisse. Die Dateien .claude/settings.json, .claude/setup.mjs oder .vscode/tasks.json werden manipuliert, sodass ein erneuter Start der IDE oder des KI-Assistenten den Malware-Payload wieder aufruft. So entsteht eine Infektionskette, die über die ursprüngliche npm-Installation hinausreicht. Entwickler, die denken, sie hätten die Systeme gesäubert, werden erneut konfrontiert.

Die stille Gefahr: OIDC und die kompromittierte Build-Pipeline

Beunruhigend ist die Fähigkeit des Wurms, die Trusted-Publisher-Funktion von GitHub Actions für npm zu missbrauchen. Moderne CI/CD-Pipelines nutzen OpenID Connect (OIDC), um temporäre, kurzlebige Zugriffstoken zu erhalten. Diese Token sind eine Sicherheitsmaßnahme, da sie nicht dauerhaft gültig sind und das Risiko statischer Secrets verringern. Der Wurm hat diese Logik umgangen. Wenn er in einer CI-Umgebung läuft, die als npm-Trusted-Publisher konfiguriert ist, kann er das OIDC-Token abgreifen und damit Pakete veröffentlichen. Das Tückische: Diese veröffentlichten Pakete tragen eine gültige Herkunftsbescheinigung (Provenance), weil sie tatsächlich von einer legitimierten Workflow-Identität erstellt wurden. Herkömmliche Sicherheitsfilter, die auf Provenance-Daten setzen, können die bösartigen Releases nicht von echten unterscheiden. Die Attacke zielt nicht nur auf direkte Opfer ab, sondern untergräbt das Vertrauen in die gesamte Infrastruktur der Softwarelieferkette. Für Unternehmen, die ihre Softwareproduktion über CI/CD automatisieren, ist das ein Alarmsignal. Es reicht nicht mehr, nur die eigenen Hosts zu schützen; die konfigurierten Rechte der Build-Identitäten müssen kontinuierlich hinterfragt werden. Die Autoren des Microsoft-Berichts weisen ausdrücklich darauf hin, dass dieser Angriff als CI/CD-Pipeline-Missbrauch klassifiziert werden muss.

Konkrete Maßnahmen: So räumst du deine Software nach ChainDrop auf

Microsoft gibt klare Handlungsempfehlungen, um die Folgen dieser Kampagne einzugrenzen. Wer ein betroffenes Paket mit aktivierten Lifecycle-Skripten installiert hat, muss die jeweilige Workstation oder den Build-Runner als potenziell kompromittiert betrachten. Eine reine Wiederherstellung aus Backups reicht nicht aus. Teams sollten unverzüglich alle Zugangsdaten, die von der betroffenen Identität erreichbar waren, von einem sauberen Host aus rotieren – also entfernen und neu vergeben. Dazu gehören npm-Tokens, GitHub-Tokens, Cloud-Zugangsschlüssel und Passwörter für Secret-Stores wie Vault. Ebenfalls essenziell ist die Bereinigung des Caches. Sowohl der npm-Cache als auch der Yarn-Cache müssen auf den betroffenen Endpoints und Build-Hosts geleert werden, besonders wenn kompromittierte Tarballs in geteilte CI-Caches geschrieben wurden. Außerdem sollten Sie die npm-CLI auf Version 12 aktualisieren und die Funktion min-release-age nutzen, die verhindert, dass frisch veröffentlichte, potenziell bösartige Pakete sofort installiert werden. Statten Sie Ihre Entwicklungs- und CI-Assets mit Microsoft Defender for Endpoint und Defender for Cloud aus, um die Telemetriedaten zu erfassen. Schließlich ist eine Überprüfung der Release-Prozesse selbst unerlässlich: Token-Scopes einschränken, Workflow-Approvals einführen, Protected Environments nutzen und Anomalien bei automatisierter Paket-Publikation überwachen. Nach der Bereinigung sollten betroffene Systeme aus einer bekannten, vertrauenswürdigen Abhängigkeitsbasis neu aufgebaut werden – inklusive der Basis-Images für Entwicklungscontainer und Build-Runner.

Einordnung: Was diese Attacke für die Zukunft der Supply-Chain-Sicherheit bedeutet

ChainDrop ist mehr als ein weiterer Zwischenfall in einer langen Liste von Sicherheitswarnungen. Er zeigt, wie fragil das Fundament ist, auf dem die moderne Softwareentwicklung ruht. Wir verlassen uns täglich auf eine unüberschaubare Anzahl von Drittanbieter-Paketen, ohne den tatsächlichen Code zu prüfen. Die Angreifer haben keine ausgefallene Zero-Day-Lücke in einem Browser ausgenutzt, sondern die schlichte Mechanik von Paketmanagern und CI/CD-Pipelines. Das ist die eigentliche Lektion. Einzelne Entwickler können sich kaum gegen einen so hochautomatisierten Wurm schützen, wenn er die üblichen Authentifizierungswege übernimmt. Die Lösung liegt in einem Umdenken: Dependency-Management ist Sicherheits-Management. Lockfiles müssen eingecheckt werden, Software-Bill-of-Materials (SBOM) müssen automatisiert erstellt werden, und die Anzahl der Personen und Identitäten mit Schreibzugriff auf die Produktions-Registry sollte auf ein Minimum reduziert werden. Wer heute noch glaubt, dass npm install ein unbedenklicher Befehl ist, sollte sich ansehen, wie leicht ein einzelner gestohlener Token in dieser Welt zu Hunderten kompromittierter Releases führen kann. Die Werkzeuge sind vorhanden – jetzt liegt es an uns, sie konsequent einzusetzen.

Quelle: microsoft.com

Du tippst npm install ein – vielleicht für ein Nebenprojekt, vielleicht eine Version, die du gerade brauchst. Meistens passiert nichts. Aber genau dieser Moment ist der Ausgangspunkt für eine der größten Sicherheitslücken im modernen Software-Ökosystem: die Lieferkette. Angreifer haben das erkannt. Sie stehlen nicht mehr gezielt einzelne Unternehmen, sie lassen automatisierte Systeme durch die npm-Registry kriechen und übernehmen Pakete wie eine Seuche. Das Team von Evil Martians, ein Entwicklungskollektiv mit mehr als 100 Open-Source-Projekten, hat dazu eine detaillierte Anleitung veröffentlicht. Der Autor beschreibt, wie man im Jahr 2026 ein npm-Paket veröffentlicht, ohne sich selbst zum Opfer zu machen. Die Kernbotschaft vorweg: Die Zeiten, in denen ein geheimer Token auf dem Laptop ausreichte, sind endgültig vorbei.

Warum die „Kleinen“ heute die Hauptziele der Angreifer sind

Der erste Reflex vieler Maintainer ist der Satz: „Niemand will unser kleines Paket hacken.“ Laut dem Autor ist genau das die gefährlichste Annahme. Die Attacken laufen heute semi-automatisch ab. Ein LLM nutzt ein bereits kompromittiertes Paket, um das nächste zu übernehmen, und so weiter. Er erwähnt die Kampagne „Shai-Hulud v2“, bei der an einem einzigen Tag über 500 verschiedene Pakete gehackt wurden. Es funktioniert wie ein Wurm: Es geht nicht darum, die Logik eines Pakets zu verstehen, sondern darum, wie viele Entwickler und deren Maschinen man durch dieses Paket erreichen kann. Dein Paket ist nicht das Ziel, sondern nur ein weiterer Schritt in der Kette.

Selbst ein kleines Utility-Tool mit wenigen tausend Downloads pro Woche ist ein lohnendes Ziel, wenn es als Sprungbrett zu größeren Projekten taugt. Die Kosten für einen Angriff sind durch LLMs enorm gesunken. Du musst also keine perfekte Verteidigung aufbauen, sondern die Kosten für den Angreifer so hoch treiben, dass sein Angriff den Wert der Daten übersteigt. Der Autor stellt klar, dass es keine 100-prozentige Sicherheit gibt. Der Realismus liegt in einer Risikobewertung, die auf echten Angriffsszenarien basiert, nicht auf Sicherheitstheater.

Das Fundament: Trusted Publisher statt NPM_TOKEN

Wer heute noch ein NPM_TOKEN als Geheimnis in der CI-Datei liegen hat, trägt laut dem Autor einen schlafenden Einbrecher im Haus. Ein gestohlener Token ist vergleichbar mit einem Universalschlüssel für dein gesamtes npm-Konto. In den Shai-Hulud-Kampagnen war genau das die bevorzugte Methode: Malware im node_modules liest die Token-Dateien und pusht sie an den Angreifer. Die Lösung heißt Trusted Publisher. Dabei verbindet sich npm direkt mit deiner GitHub-Organisation und dem Repository. npm fragt bei GitHub nach, ob der aktuelle CI-Lauf tatsächlich von dir stammt, und vergibt temporäre, kurzlebige Zugangsrechte.

Der Autor beschreibt die Einrichtung als unkompliziert: In den Einstellungen deines Pakets auf npmjs.com legst du einen Trusted Publisher an, wählst GitHub als Provider und trägst den Repository-Namen sowie den Workflow-Dateinamen ein. Wichtig ist, nur npm stage publish zu erlauben – das wird später noch relevant. Zusätzlich sollte der optionale Token-Zugriff in den npm-Einstellungen komplett deaktiviert werden. Das beste Geheimnis ist einfach keines. Der Vorteil liegt auf der Hand: Selbst wenn der Angreifer die komplette CI-Umgebung übernimmt, findet er dort keinen Token, den er stehlen kann.

Die CI-Kette zur Festung machen: SHA-Pinning und Workflow-Linting

Doch auch ohne Token bleibt ein Angriffsvektor offen: die Drittanbieter-Actions in deinen GitHub-Workflows. Viele nutzen Tags wie @v7. Ein Tag ist nicht unveränderlich. Ein angegriffener Maintainer könnte den Tag verschieben und deine nächste CI-Ausführung mit bösartigem Code infizieren. Das passiert öfter, als dir lieb ist. Der Autor berichtet vom Fall tj-actions/changed-files, wo genau das geschah. Die Lösung ist simpel und genial zugleich: Verwende statt Tags den vollständigen SHA-Commit-Hash der Action, etwa @9c091bb2…. Das wirkt wie ein Lockfile für deine CI-Abhängigkeiten – einmal geprüft, bleibt es bei dieser exakten Version.

Um diese Hashes zu verwalten, nennt der Autor drei Tools: Dependabot, pinact und actions-up. Seine Empfehlung lautet auf actions-up, weil es einen eingebauten Cooldown besitzt und sich sauber in ein npm-Projekt integrieren lässt. Zusätzlich rät er zu einem Workflow-Linter. CodeQL aus dem GitHub-Setup kann erkennen, wenn ein Angreifer versucht, deine Workflows zu missbrauchen. Für mehr Regeln eignet sich zizmor, ein Linter, der nur auf GitHub Actions spezialisiert ist. Wer hier spart, läuft laut dem Autor Gefahr, die eigene Release-Pipeline zum Einfallstor zu machen. Und noch ein Hinweis, der oft übersehen wird: Nachdem du einen Sicherheitsfehler gefixt hast, solltest du alle alten Branches löschen. Das Nx-Team hatte einen Fehler in einem alten Branch korrigiert, aber der alte Branch existierte noch – der Angreifer eröffnete genau dort einen Pull-Request.

Der menschliche Faktor: Staged Publishing und npm Provenance

Bisher klingt alles nach Automatisierung. Doch der Autor spricht einen wichtigen Punkt an: Er mochte npm Provenance anfangs nicht, weil eine reine CI-Veröffentlichung weniger sicher ist als eine manuelle mit Hardware-2FA. Denn ein kompromittiertes CI-System kann dein Paket veröffentlichen, während du schläfst. Die Lösung liegt in einer Kombination aus beidem, genannt „Staged Publishing“. Hier verläuft die Pipeline zweistufig. Im ersten Schritt führt die CI den Build und einen Testlauf durch, publiziert das Paket aber nur als Bühnen-Entwurf. Dazu nutzt sie den Befehl npm stage publish anstelle von npm publish. Im zweiten Schritt musst du selbst, mit deinem Hardware-2FA-Token, das Paket freigeben. Das geschieht über die npm-Webseite im Menüpunkt „Staged Packages“ oder per CLI mit npm stage approve.

Damit bekommst du die Bequemlichkeit von CI-Publishing und zugleich die Sicherheit einer manuellen Kontrolle. Ein pragmatischer Ansatz, der den Hauptnachteil von reinen CI-Release-Pipelines behebt. Wichtig ist: npm stage publish erlaubt dir, das Paket vor der Freigabe zu prüfen. Das Problem dabei: npmjs.com zeigt keinen Diff an. Du könntest also übersehen, dass dein Build-Schritt bösartigen Code eingefügt hat. Deshalb empfehlen die Autoren einen Dienst namens drydock. Dort erstellst du ein Konto, hinterlegst einen Read-Only-Token, und drydock meldet sich per E-Mail, sobald ein neues Stage-Paket auftaucht. Du siehst den Diff, prüfst die Änderungen und gibst das Paket dann erst auf npmjs.com mit deiner Hardware-2FA frei.

Die restliche Ausrüstung: Tag-Regeln, Cooldowns und Paketmanager

Ein weiterer Baustein betrifft die Rollenverteilung auf GitHub. In den Repository-Einstellungen lässt sich per Ruleset festlegen, dass nur Administratoren neue Tags erstellen dürfen. So verhinderst du, dass ein kompromittierter Entwickler-Account heimlich einen alten Tag wie v3 überschreibt und damit das nächste Release sabotiert. Der Autor schlägt außerdem eine Abkühlphase von drei Tagen vor, bevor du eine neue Version deines Pakets verwendest. Das gibt dir Zeit, mögliche Schadenskampagnen zu beobachten, bevor sie dich erreichen.

Ein Punkt, der fast nebenbei erwähnt wird, aber enorm effektiv ist: der Wechsel auf moderne Paketmanager. npm 12, pnpm 10, yarn 4.14 oder bun führen standardmäßig keine postinstall-Skripte der Abhängigkeiten aus. Diese Skripte sind ein beliebter Vektor für Malware, da sie bei der Installation sofort und ohne Zutun des Entwicklers ausgeführt werden. Wenn dein Paketmanager diese Skripte ignoriert, entfernst du eine der gefährlichsten Angriffsflächen in deiner gesamten Entwicklungsumgebung. Zum Abschluss der Konfiguration zeigt der Autor ein Beispiel-Workflow-File publish.yaml. Er rät explizit, auf einen Build-Schritt zu verzichten, wenn es möglich ist – etwa bei einer reinen JavaScript-Bibliothek. Je weniger Verarbeitungsschritte zwischen deinem Quellcode und dem endgültigen npm-Paket liegen, desto geringer ist die Chance, dass dort unerkannt Code eingeschleust wird.

Die nüchterne Einordnung: Wofür das alles gut ist

Was bleibt nach der ganzen Umstellung? Sicherheit ist keine Show. Der Autor betont, dass ein grüner Check beim npm-Provenance-Badge nicht bedeutet, dass dein Paket sicher ist – es bedeutet nur, dass es aus einer bestimmten Pipeline kommt. Es verrät nichts darüber, ob diese Pipeline sauber war. Trotzdem ist das mehr als Theater. Es erhöht die Kosten für den Angreifer enorm. Jeder Schritt, den du hier gehst – Trusted Publisher, SHA-Pinning, Staged Publishing, Cooldown – macht dein Paket zu einem unattraktiven Ziel. Und diese Arbeit lohnt sich auch aus Marketing-Sicht: Immer mehr Unternehmen ziehen bei der Bewertung einer Open-Source-Bibliothek den Sicherheits-Score auf npmjs.com heran.

Der Autor schließt mit einem Blick in die Zukunft: Wenn die eigentliche Programmierarbeit zunehmend von LLMs übernommen wird, wandert der menschliche Fokus zu Absicherung und Kontrolle. Grundlegende Sicherheitskenntnisse werden dann zur Kernkompetenz jedes Entwicklers. Wer seiner Lieferkette nicht vertraut, kann auch seinen eigenen Code nicht vertrauen. Behandle deine Release-Pipeline also wie ein hochwertiges Bankfach: Der Schlüssel ist physisch bei dir, die Transaktion wird überwacht, und du selbst bist der letzte Kontrollpunkt. Genau so – und nicht anders – wird sauberes npm-Publishing im Jahr 2026 aussehen.

Quelle: evilmartians.com

Du kennst das: Ein neuer Kollege oder eine neue Kollegin kommt ins Team. Hochmotiviert, Top-Studium, aber keine Ahnung von euren Prozessen, eurem Jargon oder den Tools. Du erklärst, wo die Daten liegen, was die Abkürzungen bedeuten, wie ihr arbeitet. Und trotzdem dauert es Wochen, bis die Person produktiv ist. Mit KI-Assistenten im Unternehmen ist es ähnlich. Die Modelle können viel, aber sie kennen euer Unternehmen nicht. Sie verstehen eure Terminologie nicht, wissen nicht, wo eure Systeme stehen oder wie ihr typische Aufgaben angeht. Cloudflare OS will das ändern. Der Konzern hat eine Plattform gebaut, die jedem Mitarbeiter einen Agenten gibt, der den Firmenkontext kennt. Und das als Open Source.

Das Problem: KI-Agenten ohne Unternehmenskontext

Wenn du einem KI-Agenten eine Aufgabe gibst, ist er wie ein Fremder in einer neuen Stadt. Er kann Code schreiben, Texte verfassen, Daten analysieren – aber ohne die kulturellen und prozessualen Eigenheiten deines Unternehmens bleibt das Stückwerk. Er weiß nicht, dass ihr bestimmte Begriffe anders verwendet, dass euer CRM eine spezielle Logik hat, welche Qualitätsstandards im Team gelten. Die Entwickler von Cloudflare haben das erkannt. Ihre erste Version von Cloudflare OS, intern seit Mai im Einsatz, zeigte: Der bloße Zugriff auf Tools reicht nicht. Die Agenten müssen eingebettet sein in den Wissensschatz und die Arbeitsweisen des Unternehmens. Erst dann können sie repetitive Aufgaben übernehmen, Dokumente erstellen, Daten visualisieren, Workflows automatisieren.

Die erste Version konzentrierte sich auf einzelne Nutzer mit privaten Workspaces. Doch die Teamarbeit offenbarte ein Grundproblem: Es war unklar, welche Daten ein Agent gesehen hatte und wer was sehen durfte. Wer einen Beitrag teilte, konnte ungewollt sensiblen Inhalt exponieren. Ein Sicherheitsproblem, das viele KI-Plattformen unterschätzen. Cloudflare OS wurde deshalb neu aufgebaut – mit Sicherheit als Fundament, nicht als nachträglicher Zusatz.

Drei Bausteine für produktive Agenten

Wie sieht ein System aus, das Agenten mit Unternehmenskontext und sicherem Zugriff kombiniert? Cloudflare OS besteht aus drei Komponenten, die ineinandergreifen.

Der erste Baustein ist ein Agent-Workspace für jeden Mitarbeiter. Er läuft im Browser, ohne Programmierkenntnisse oder Terminal. Ein Workspace ist mehr als ein Chatfenster: Er vereint Agentensitzungen, persistenten Zustand, Ausgaben und Dateien sowie einen isolierten Laufzeitbereich, in dem der Agent Code schreibt und ausführt. Vorkonfiguriert sind die kuratierten Kontext- und Skill-Bibliotheken des Unternehmens. So muss niemand Prozesse mühsam erklären – wer eine bessere Methode gefunden hat, kann sie teilen.

Der zweite Baustein ist ein Sicherheits- und Governance-Framework, das den Zugriff auf interne Daten regelt. Jeder Agent startet ohne jeglichen Zugriff. Er kann Zugriff auf bestimmte Ressourcen anfragen, du gewährst oder verweigerst ihn. Der generierte Code erhält die Ressource als sogenannte Capability – eine Art Berechtigungsschein. Die Anmeldedaten bleiben isoliert vom Agenten und vom generierten Code. Vergleich: Du gibst einem Handwerker nicht den Generalschlüssel, sondern öffnest pro Raum einzeln die Tür.

Der dritte Baustein ist eine Plattform für individuelle, modifizierbare Apps. Klassische Produktivitätssammlungen haben feste Anwendungen: Textdokumente, Tabellen, Präsentationen. Cloudflare OS dreht das um: Jede „Datei“ kann eine eigene, von einem Agenten generierte App sein. Diese App hat eigene Oberfläche, Logik und Speicherung. Sie kann live mit Unternehmensdaten verbunden sein und sich aktualisieren, wenn sich Quellen ändern. Du formst das Werkzeug nach deinen Bedürfnissen – nicht umgekehrt.

Sicherheit: Gatekeepers und protokollierte Beobachtungen

Der wichtigste Teil von Cloudflare OS ist das Sicherheitskonzept. API-Keys gewähren breiten Zugriff, sind schwer einzuschränken und zu überwachen. Model Context Protocol (MCP) Server sind eine Verbesserung, weil sie den Agenten mit einem definierten Satz von Werkzeugen verbinden, ohne den Schlüssel herauszugeben. Aber MCP allein verrät nichts darüber, welche Ressourcen der Agent tatsächlich gesehen hat. Er könnte Daten aus verschiedenen Systemen kombinieren und an einen weniger geschützten Ort weiterleiten.

Cloudflare OS geht weiter. Jeder Agent hat initial keinen Zugriff. Um auf eine Ressource zuzugreifen, läuft eine Anfrage über einen Gatekeeper – eine Vermittlungsschicht zwischen Agent und externem Dienst. Der Gatekeeper versteht die API des Dienstes, kennt dessen Ressourcen und Aktionen. Statt Zugriff auf das gesamte GitHub-Konto zu gewähren, kann er den Agenten auf ein Repository beschränken, das Lesen von Issues erlauben, aber das Lesen von Quellcode verbieten. Er kann Felder maskieren, Ratelimits setzen und für einen Pull-Request eine Genehmigung verlangen. Der Agent sieht nur eine schlanke TypeScript-API. Der Gatekeeper übernimmt OAuth, hält die Credentials, erzwingt Richtlinien und protokolliert alles Gelesene.

Entscheidend: Die Plattform merkt sich, welche Ressourcen ein Agent beobachtet hat. Diese Beobachtungsprotokolle bleiben mit dem Agenten und seinen Ergebnissen verknüpft. Wenn jemand auf den Workspace zugreifen oder die Apps ansehen möchte, prüfen die Gatekeepers, ob diese Person Zugriff auf die zugrunde liegenden Ressourcen hat. Beispiel: Dein Agent liest eine vertrauliche Tabelle und erstellt ein Dashboard. Ohne die zusätzliche Prüfung könnte das Teilen des Dashboards zu einer Hintertür zur Tabelle werden. Cloudflare OS verhindert das, weil es die sichere Weitergabe von Ergebnissen ermöglicht, ohne die zugrunde liegenden Daten zu kompromittieren. Außerdem können Richtlinien festlegen, dass ein Agent nach dem Lesen sensibler Daten keine externen Anfragen mehr stellt – etwa um Daten nach außen zu senden oder neue Mitarbeiter einzuladen.

Apps, die leben: Vom Gespräch zur individuellen Anwendung

Die dritte Säule ist die Fähigkeit, Apps zu generieren. Wenn du deinem Workspace eine Aufgabe gibst, etwa einen Report zu erstellen oder eine Kalkulation aufzubereiten, kann der Agent nicht nur Dokumente erzeugen, sondern auch eine vollständige Web-App bauen. Die App hat Clientcode, der im Browser läuft, und Servercode, der als „Dynamic Worker“ ausgeführt wird. Der Server wird bei Bedarf in einer isolierten V8-Instanz geladen und erhält eine eigene SQLite-Datenbank. Die App braucht keine eigene Serverinfrastruktur – sie läuft innerhalb der Cloudflare-Worker-Plattform.

Die Kommunikation zwischen Browser und Server erfolgt über Cap’n Web, eine open-source RPC-Technologie von Cloudflare. Das Besondere: Der Agent kann dieselben Methoden aufrufen wie der Benutzer. Ein Tool, das du selbst entwickelt hast, kann auch vom Agenten verwendet werden, wenn du nicht da bist. Du erstellst eine kleine App, die bestimmte Daten abfragt und aufbereitet – später kann der Agent diese App eigenständig nutzen, um ähnliche Aufgaben zu erledigen. Das ist Zusammenarbeit zwischen Mensch und Maschine, kein simpler Chatbot.

Teilen gehört dazu. Du kannst eine App wie ein Dokument teilen, andere können sie in Echtzeit mitnutzen. Oder du teilst eine „Blueprint“, also die Bauanleitung der App. Andere erstellen dann eine eigene Kopie mit eigenem Datenbestand und eigenen Ressourcen. So verbreitet sich Wissen im Team, ohne dass jeder von vorne beginnt. Die Open-Source-Natur erlaubt jeder Organisation, diese Mechanismen anzupassen.

Open Source: Der nächste Schritt für Unternehmens-KI

Cloudflare OS ist als Open-Source-Plattform veröffentlicht. Das ist keine Marketing-Entscheidung. Jedes Unternehmen kann die Plattform herunterladen, anpassen und mit eigenen Systemen verbinden. Ein deutlicher Kontrast zu geschlossenen KI-Lösungen, die oft kaum konfigurierbar sind und als Blackbox funktionieren. Mit Cloudflare OS gehören dir die Regeln, die Daten und die Sicherheitsmechanismen.

Für Entwickler und Architekten ist das eine Einladung, eigene Gatekeepers zu bauen, Skills zu kuratieren und die Plattform in bestehende Workflows zu integrieren. Unternehmen ohne eigene IT-Abteilung haben vielleicht eine Hürde, aber die Cloudflare-Infrastruktur ist verbreitet, die Integration ins Workers-Ökosystem naheliegend. Die Plattform lässt sich an jede Organisation anpassen – vom Start-up bis zum Großkonzern.

Was heißt das konkret für dich? Wenn du mit KI-Agenten experimentierst, weißt du: Die Herausforderung sind nicht die Sprachmodelle, sondern der Kontext und die sichere Einbindung in Unternehmenssysteme. Cloudflare OS zeigt einen Weg, diese Hürde zu überwinden. Es versucht, KI von einem Spielzeug zu einem Werkzeug zu machen, das in der Arbeitswelt etwas verändert. Die Plattform ist noch jung, aber die Prinzipien – Kontext teilen, Sicherheit eingebaut, Apps als Bausteine – sind tragfähig. Ein Blick darauf lohnt sich, vielleicht ein Test. Die Auswirkungen auf die Produktivität im Team können spürbar sein – wenn man die Balance zwischen Automatisierung und menschlicher Kontrolle findet.

Quelle: blog.cloudflare.com

iCloud Private Relay verspricht, dass keine besuchte Website die echte IP-Adresse eines Nutzers zu sehen bekommt. Genau das stimmt nicht mehr. Zwei Sicherheitsforscher haben drei Wege gefunden, auf denen die Adresse trotz aktiviertem Dienst nach draußen gelangt – und für den wichtigsten davon genügt es, eine präparierte Seite zu öffnen. Die Ursache liegt nicht in einer Einstellung, sondern eine Ebene tiefer: in der WebKit-Engine, auf der Safari und praktisch jeder Browser unter iOS aufsetzt.

Die Entdeckung: Sicherheitsforscher stoßen auf eine undichte Stelle

Die Forscher Tommy Mysk und Talal Haj Bakry, bekannt für ihre Arbeit im Bereich App-Sicherheit, haben eine Schwachstelle im Zusammenspiel von iCloud Private Relay und Passkeys entdeckt. Laut ihrem Bericht kann eine Website, die Passkeys verwendet oder vorgibt, sie zu verwenden, die echte IP-Adresse eines Nutzers auslesen, obwohl Private Relay aktiv ist. Das Problem liegt nicht in einer Konfiguration, sondern im System: in der WebKit-Engine, die Safari und auch viele andere Browser antreibt. Mysk und Haj Bakry haben auf ihrer Website einen Test bereitgestellt, mit dem du selbst prüfen kannst, ob deine IP-Adresse durch diese Lücke offengelegt wird.

Die Passkey-Lücke: Warum WebAuthn den Proxy umgeht

Passkeys basieren auf dem WebAuthn-Standard. Dieser Standard speichert den privaten Schlüssel nicht im Browser, sondern im Betriebssystem – bei Apple im iCloud-Schlüsselbund oder im Secure Enclave. Das erhöht die Sicherheit. Doch hier liegt das Problem: Wenn eine Website eine Passkey-Authentifizierung anfordert, übernimmt das Betriebssystem die Kommunikation mit dem Server. Diese Anfrage läuft nicht durch den Proxy von iCloud Private Relay, sondern direkt über die normale Netzwerkverbindung des Geräts. Der Server sieht also die echte IP-Adresse. Das geht sogar ohne sichtbare Aufforderung: Mit dem Parameter „conditional mediation” kann die Website die Anfrage im Hintergrund auslösen, ohne dass du etwas merkst. Ein Angreifer könnte eine Seite betreiben, die WebAuthn nutzt, und so heimlich die IP-Adresse jedes Besuchers abgreifen.

Nicht nur Passkeys: Auch DNS-Prefetching und WebTransport leaken Daten

Die Forscher fanden zwei weitere Wege. Das erste betrifft das DNS-Prefetching, ein Feature, das in iOS 26 eingeführt wurde. Es lädt DNS-Auflösungen im Voraus, um das Surfen zu beschleunigen – dabei werden aber die echten DNS-Server des Nutzers offengelegt. Das zweite Leck betrifft WebTransport, eine moderne API für bidirektionale Kommunikation, die seit iOS 26.4 verfügbar ist. Auch hier kann eine Website die echte IP-Adresse des Nutzers abfragen, ohne dass Private Relay eingreift. In allen drei Fällen ist der Grund derselbe: Die Anfrage wird nicht von Safari selbst gestellt, sondern von Systemebenen, die den Proxy nicht kennen.

Was bedeutet das für dich? Und was sagt Apple?

Wenn du iCloud Private Relay nutzt, dachtest du bisher, dass keine Website deine echte IP-Adresse sehen kann. Diese Annahme stimmt nicht mehr. Die Lücke betrifft nicht nur Safari, sondern auch andere Browser, die auf WebKit basieren – also zum Beispiel den Browser, den du in manchen Apps verwendest. Apple hat gegenüber 404 Media bestätigt, dass das Problem untersucht wird. Bis ein Fix erscheint, kannst du dir überlegen, ob du zusätzlich ein VPN nutzt. Ein VPN verschlüsselt den gesamten Datenverkehr und leitet ihn über einen externen Server um, bevor er ins Internet geht. Private Relay ist kein VPN, sondern ein Proxy, der nur den Safari-Verkehr abdeckt. Für mehr Schutz könnte ein VPN helfen, auch wenn es keine offizielle Apple-Lösung gibt.

Der Angriff braucht keinen einzigen Klick

Was diese Lücke von vielen anderen Tracking-Methoden unterscheidet, ist der fehlende Bedienschritt. Eine Website kann bei einer WebAuthn-Anfrage die sogenannte rpId frei wählen, also den Bezeichner der Gegenstelle, für die der Passkey gelten soll. In Kombination mit der Option conditional mediation läuft die Anfrage vollständig im Hintergrund: kein Dialog, kein Hinweis, keine Schaltfläche. Der Aufruf feuert allein dadurch, dass die Seite geladen wird.

Damit reicht ein einziger Seitenbesuch. Wer eine präparierte Website betreibt – oder ein Werbeskript darauf unterbringt – bekommt die echte IP-Adresse jedes Besuchers, der sich auf Private Relay verlässt. Klassisches Browser-Fingerprinting liefert nur Wahrscheinlichkeiten und lässt sich mit Gegenmaßnahmen stören. Eine IP-Adresse dagegen ist ein harter Wert: Sie verrät den Provider und den ungefähren Standort und verknüpft Besuche über verschiedene Seiten hinweg. Mysk und Haj Bakry haben deshalb eine Testseite veröffentlicht, auf der sich mit einem Aufruf prüfen lässt, ob das eigene Gerät betroffen ist.

Wo Private Relay endet – und was ein VPN anders macht

Ein Teil des Problems ist eine Erwartung, die der Dienst nie eingelöst hat. iCloud Private Relay ist kein Tunnel für das gesamte Gerät, sondern ein Proxy mit klar umrissenem Zuständigkeitsbereich: der Safari-Verkehr, unverschlüsselte DNS-Anfragen und ein Teil des App-Verkehrs. Alles, was daran vorbeigeht, war nie geschützt. Die drei gefundenen Lecks liegen genau in dieser Zone – sie stammen aus Systemschichten, die den Proxy schlicht nicht kennen.

Ein VPN setzt eine Ebene tiefer an und leitet den Verkehr des ganzen Geräts über einen einzigen Ausgangspunkt. Dadurch fallen die drei beschriebenen Wege weg, weil auch die Anfragen des Betriebssystems durch denselben Tunnel laufen. Umsonst ist dieser Schutz allerdings nicht. Bei Private Relay teilen sich Apple und ein Partnerunternehmen die Kenntnis bewusst auf: Der eine kennt deine IP, der andere das Ziel. Beim VPN sieht ein einzelner Anbieter beides zusammen. Man tauscht also nicht Unsicherheit gegen Sicherheit, sondern ein Vertrauensmodell gegen ein anderes.

Praktisch heißt das dreierlei. Erstens: Private Relay bleibt sinnvoll, es deckt nur weniger ab, als der Name vermuten lässt. Zweitens lohnt der Test auf der Seite der beiden Forscher, weil er in Sekunden zeigt, ob das eigene Gerät die Adresse preisgibt – die Lücken hängen an bestimmten iOS-Versionen, DNS-Prefetching kam mit iOS 26, WebTransport mit iOS 26.4. Drittens gilt für alles, was wirklich vertraulich bleiben soll: Ein Proxy im Browser ist die falsche Ebene. Wer Anonymität braucht, arbeitet auf Geräteebene und weiß, wem er dabei vertraut.

Die Einordnung: Datenschutz ist nie eine Einbahnstraße

Diese Sicherheitslücke zeigt, wie komplex Datenschutz in der Praxis ist. Selbst ein Dienst wie iCloud Private Relay hat blinde Flecken, wenn verschiedene Komponenten des Systems nicht optimal zusammenspielen. Für dich bedeutet das: Verlass dich nicht blind auf eine einzige Schutzmaßnahme. Prüfe, welche Daten du preisgibst, und überlege, ob du für sensible Aktivitäten ein zusätzliches VPN einschaltest. Apple wird das Problem vermutlich beheben, aber bis dahin solltest du wissen, dass deine IP-Adresse möglicherweise nicht so privat ist, wie du dachtest. In der digitalen Welt gibt es selten absolute Sicherheit – nur verschiedene Stufen der Vorsicht.

Quelle: macrumors.com

Du verfolgst seit Jahren ein Sportteam. Du kennst die Spieler, die Taktik, weißt, worauf es ankommt. Dann, an einem Tag, wechseln Kapitän und Trainer, die halbe Startaufstellung kündigt. Genau das passiert gerade bei Google DeepMind. Die Führungsetage der wichtigsten KI-Abteilung des Konzerns hat sich innerhalb weniger Stunden neu aufgestellt. Demis Hassabis, langjähriger Kopf von DeepMind, wird Vorsitzender und Chief Scientist von Alphabet. Koray Kavukcuoglu übernimmt die operative Leitung. Jeff Dean, eine Legende der KI-Forschung, verlässt Google mit drei weiteren Top-Leuten, um ein eigenes Unternehmen zu gründen. Ein ehemaliger Google-Mitarbeiter (2014–2022), der sich intensiv mit KI-Prognosen beschäftigt hat, versucht nun, die Zukunft dieses neuen Googles einzuordnen. Seine Schlussfolgerungen: Der Talentabgang ist weniger schlimm als befürchtet, aber der Rückstand in der KI-Spitze ist größer als gedacht.

Die große Rochade bei Google DeepMind

Am 5. August wurde die Neuorganisation offiziell. Demis Hassabis tritt als CEO von Google DeepMind zurück und übernimmt den neuen Posten des Chief Scientist bei Alphabet, der Muttergesellschaft. Gleichzeitig wird er Vorsitzender des Aufsichtsrats von DeepMind. Das Tagesgeschäft führt nun Koray Kavukcuoglu, Senior Vice President, der direkt an Sundar Pichai berichtet. Bemerkenswert: DeepMind war bisher eine eigenständige Einheit mit eigenem CEO. Jetzt ist es nur noch eine SVP-Abteilung wie viele andere. Dazu kommt der Abschied von Jeff Dean, dem wohl berühmtesten Ingenieur der Google-Geschichte. Zusammen mit Sanjay Ghemawat, Oriol Vinyals und Quoc Le – allesamt Schwergewichte der KI-Forschung – gründet er das Unternehmen Discovery Loop. Diese Firma will wissenschaftliche Forschung automatisieren. Google finanziert sie und liefert Rechenleistung über Google Cloud.

Der ehemalige Google-Mitarbeiter, dessen Analyse auf seiner Website steht, beschreibt, wie er selbst mit Jeff Dean zu tun hatte. Jeff hätte auf technische Anfragen mit unglaublich komplexen Lösungen geantwortet, sagt er. Diese Anekdote zeigt, wie prägend Dean für die Ingenieurskultur bei Google war. Kein Wunder, dass die Aktie von Alphabet nach der Ankündigung um rund fünf Prozent fiel – eine Marktkapitalisierung von etwa 200 Milliarden Dollar. Der Autor glaubt jedoch, der Markt ziehe die falsche Schlussfolgerung. Die Kursschwäche habe weniger mit den Personalien zu tun, sondern mit der Erkenntnis, dass Googles KI-Modelle nicht mehr an der Spitze stehen und Gemini 4 womöglich erst viel später erscheint als erhofft.

Warum Gemini 4 erst 2027 kommen könnte

Wann kommt das nächste große Modell? Der Autor hat dazu verschiedene Prognosen erstellt, basierend auf internen Informationen und Branchenwissen. Seine mittlere Schätzung: Gemini 4 wird am 15. Mai 2027 verfügbar sein, also in über einem Jahr. Ein Launch 2026 liegt außerhalb seines 80-Prozent-Vertrauensintervalls. Das weicht deutlich von den üblichen Branchenerwartungen ab, die oft von Ende 2026 ausgehen. Warum? Das Pre-Training für Gemini 4 habe erst Ende Juli 2026 begonnen – auf dem größten Rechenbudget, das Google je aufgewendet hat. Frontier-Modelle dieser Größenordnung brauchen mindestens hundert Tage reine Rechenzeit, oft mehr. Danach folgt das Post-Training, das ebenfalls mehrere Monate dauert. Und seit 2026 müssen alle großen KI-Modelle eine 30-tägige Überprüfung durch die US-Regierung durchlaufen, bevor sie veröffentlicht werden dürfen. Das schiebt jeden Launch um mindestens einen Monat nach hinten.

Es gibt noch einen weiteren Grund: Google hat in diesem Jahr ein Modell verworfen und neu aufgebaut, weil es bei Programmieraufgaben versagte. Der Konzern kann nicht mehr so schnell liefern wie OpenAI oder Anthropic. Der Autor verweist auf GPT-6 von OpenAI: Das Pre-Training endete im März 2026, Sam Altman versprach einen Start „in ein paar Wochen“. Doch selbst im August ist GPT-6 nicht veröffentlicht. Stattdessen hat OpenAI die Verbesserungen als GPT-5.5 als Punkt-Release herausgebracht. Dieses Muster sieht der Autor auch bei Google: Punkt-Release wie Gemini 3.5 Pro könnten bald erscheinen, aber eine komplett neue Generation lässt auf sich warten. Er rät, nicht auf Versprechen zu achten, sondern auf die tatsächliche Entwicklung.

Verliert Google seine besten Köpfe – oder ist das nur Business as usual?

Eine häufige Befürchtung nach den Abgängen: Google erleidet einen massiven Brain Drain. Der Autor hat diese Frage mit einem statistischen Modell angegangen. Er fragte sich, wie viele der etwa fünfzehn ranghöchsten Forschungs- und Entwicklungsleiter, die bei Google DeepMind noch verblieben sind, innerhalb der nächsten sechs Monate gehen werden. Seine Prognose: zwei, wobei eine mögliche Freistellungsphase von mehreren Monaten den Prozess verlangsamen kann. Das ist beruhigend, wenn man bedenkt, dass bei einem Unternehmen dieser Größe natürliche Fluktuation völlig normal ist.

Der Autor stützt sich auf eine umfassende Analyse von Mike Frantzen, der 157 Frontier-Modell-Veröffentlichungen und 171 Personalwechsel untersuchte. Das überraschende Ergebnis: Labore mit mehr Senior-Abgängen bauten in der Folge bessere Modelle als ihre direkten Konkurrenten. Der Grund ist einfach: Die Gewinner ziehen Talente an, aber die Verlierer behalten den Rest, der oft jahrelange Erfahrung mitbringt. Die eigentliche Stärke eines KI-Labors liegt nicht in ein paar bekannten Namen, sondern in der Trainingsinfrastruktur und den hunderten von Ingenieuren im mittleren Management, die nie im Rampenlicht stehen. Der Autor wendet diese Logik auch auf die britische Niederlassung an: Er erwartet, dass der Personalbestand in Großbritannien bis 2027 um etwa neun Prozent gegenüber 2025 wächst. Und er schätzt die Wahrscheinlichkeit, dass DeepMind als eigenständige Einheit bestehen bleibt, auf 73 Prozent. Hassabis behält zwar einen Titel auf Alphabet-Ebene bis Ende 2027, aber seine Rolle werde zunehmend zeremoniell statt operativ, sagt er.

Googles dunkles Pferd: Die Cloud als Cash-Maschine

Während alle auf die KI-Modelle schauen, übersehen viele, dass Google in einem anderen Bereich enorm wächst. Google Cloud verzeichnete im letzten Quartal ein Plus von 82 Prozent im Jahresvergleich. Der größte Kunde dabei ist ausgerechnet Anthropic, das führende KI-Unternehmen, das mit Googles Konkurrenzmodellen arbeitet. Anthropic hat sich langfristig verpflichtet, rund 200 Milliarden Dollar bei Google Cloud auszugeben – über fünf Jahre, beginnend 2027. Im Vergleich dazu werden die Einnahmen aus Googles eigenen KI-Produkten wie Gemini API und Verbraucher-Abonnements auf etwa 15 Milliarden Dollar pro Jahr geschätzt. Eine enorme Diskrepanz.

Der Autor prognostiziert: Es gibt eine Wahrscheinlichkeit von 60 Prozent, dass die jährlichen Ausgaben von Anthropic bei Google Cloud die Einnahmen aus Googles eigenen Gemini-Produkten vor 2028 übersteigen. Das ist nicht nur eine wirtschaftliche Kuriosität, sondern auch ein strategisches Signal. Google wird zunehmend zur Infrastruktur für die Konkurrenz, während es selbst im KI-Rennen zurückfällt. Der Autor sieht darin eine mögliche Rettung: Selbst wenn Googles eigene Modelle nicht die besten sind, kann das Unternehmen weiterhin Milliarden verdienen, indem es die Recheninfrastruktur für andere stellt. Ähnlich wie ein Softwareunternehmen, dessen Betriebssystem von den Geräten der Konkurrenz genutzt wird – es bleibt profitabel, auch wenn es nicht die innovativste Hardware selbst produziert.

Die zerbröckelnden roten Linien: Militär und Ethik

Ein Aspekt, der in der öffentlichen Diskussion oft zu kurz kommt, sind die ethischen Versprechen, die Google und DeepMind 2014 bei der Übernahme gegeben haben. Damals verpflichtete sich Google in einem internen Übereinkommen, dass eine Ethikkommission die Kontrolle über eine mögliche künstliche allgemeine Intelligenz (AGI) erhalten würde, und dass DeepMinds Technologie nicht für militärische Zwecke verwendet werden darf. Diese Vereinbarungen sind inzwischen weitgehend ausgehöhlt. Die Ethikkommission wurde nie vollständig eingesetzt, und 2025 hat Google offiziell die Prinzipien geändert, um KI für militärische Einsätze zu verkaufen. Bereits im April 2026 unterzeichnete Google einen Geheimvertrag mit dem Pentagon, der Gemini für „alle rechtmäßigen Regierungszwecke“ öffnet – inklusive der Möglichkeit, menschlich überwachte Zielauswahl zu unterstützen. Das ist genau das, was Anthropic im Mai abgelehnt hat.

Der ehemalige Google-Mitarbeiter, der selbst miterlebte, wie Mitarbeiter gegen die militärische Zusammenarbeit protestierten, hat auch hierzu eine Prognose erstellt: Es gibt eine 66-prozentige Wahrscheinlichkeit, dass bis Ende 2027 ein Gemini-basiertes System in einer tatsächlichen Waffen- oder Zielerfassungsrolle eingesetzt wird. Das wäre ein Bruch des ursprünglichen Versprechens von 2014. Mit der neuen Führungsstruktur, die DeepMind zu einer normalen Unternehmensabteilung macht, sieht man keine formalen Hürden mehr für solche Einsätze. Der Autor weist darauf hin, dass Googles interne Governance schwächer sein könnte als die von OpenAI, das zumindest eine Nonprofit-Struktur mit Board-Kontrolle hat, oder von Anthropic, das eigene Sicherheitsmechanismen etabliert. Diese Entwicklung ist potenziell folgenschwerer als jede Marktanteilsverschiebung.

Was bedeutet das für die Zukunft der KI?

Am Ende stellt sich die Frage, ob Googles Niedergang als KI-Vorreiter wirklich eine Katastrophe ist. Der Autor gibt eine überraschend nüchterne Antwort: Die Verluste an Talenten werden überschätzt, aber Googles technologischer Rückstand wird unterschätzt. Er schätzt, dass Google etwa zwölf Monate hinter der Spitze liegt – mehr als die oft genannten sechs bis neun Monate. Das bedeutet: Gemini 4 wird kommen, aber es wird nicht das beste Modell sein. Dafür wird Google weiterhin von seiner Cloud-Infrastruktur profitieren, und das ist eine stabile Einnahmequelle. Gleichzeitig zeigt die militärische Öffnung, wie schnell ethische Prinzipien im Wettbewerb aufgeweicht werden können. Für uns Nutzer bedeutet das: Wir werden weiterhin KI-Assistenten in Google-Produkten sehen, aber die wirklich bahnbrechenden Modelle werden nicht aus Mountain View kommen. Vielleicht ist das auch gut so, denn mehr Konkurrenz bedeutet mehr Vielfalt und mehr Kontrolle. Die nächsten Jahre werden zeigen, ob Google sich auf die zweite Reihe verabschiedet oder ob der Konzern noch eine Überraschung parat hat.

Quelle: futuresearch.ai