Kategorie: KI-News

Observability handelt nicht nur von Servern, Containern und Antwortzeiten. Diese Annahme greift zu kurz, sobald KI-Systeme und autonome Agenten in Produktion gehen. Dynatrace hat am Donnerstag angekündigt, den KI-Observability-Spezialisten Arize für rund 915 Millionen US-Dollar in bar und Aktien zu übernehmen. Ziel ist, Arizes Sicht auf Modellausgaben, Agenten-Pfade und Tool-Nutzung mit Dynatraces klassischer Telemetrie für Anwendungen, Services und Infrastruktur zu verbinden. Beide Seiten erwarten davon eine neue Qualität der Fehlersuche und Verantwortungsnachverfolgung in verteilten Systemen.

Immer mehr Unternehmen setzen KI-Modelle nicht nur testweise ein, sondern in Produktionsumgebungen. Genau dort stoßen herkömmliche Monitoring-Ansätze an ihre Grenzen. Wenn ein klassischer Service ausfällt, suchst du in Logs, Metriken und Traces nach der Ursache. Bei einem KI-Agenten kommt eine Dimension hinzu: Du musst wissen, welche Eingaben das Modell erhalten hat, welche Werkzeuge es aufgerufen hat und warum es zu einer bestimmten Ausgabe kam. Diese Informationen liegen oft in getrennten Systemen, sodass du die gesamte Geschichte mühsam zusammensetzen musst. Die Übernahme will das ändern.

Warum klassische Observability an KI-Agenten scheitert

Die Herausforderung ist nicht neu, aber KI verschärft sie massiv. In einem verteilten System verfolgst du Transaktionen über mehrere Dienste hinweg. Du siehst, wo ein Request hängt, welche Datenbank zu langsam antwortet oder welcher Service einen Fehler wirft. Das funktioniert, weil alle Komponenten nach ähnlichen Regeln arbeiten und standardisierte Telemetrie liefern. Ein KI-Agent verhält sich anders. Er trifft dynamische Entscheidungen, sucht in Wissensdatenbanken, ruft APIs auf und generiert nicht-deterministische Antworten.

Wenn etwas schiefgeht – etwa weil ein Agent eine falsche Empfehlung ausspricht oder einen kostspieligen externen Dienst unnötig oft anruft – ist die Fehlerursache selten ein einzelner Codeabschnitt. Es ist ein Zusammenspiel aus Modellqualität, Kontext, Tool-Verhalten und der zugrunde liegenden Infrastruktur. Bisherige Observability-Tools bilden dieses Zusammenspiel nicht ab. Du siehst die Auswirkung im Application-Performance-Monitoring, aber nicht den Grund im Agentenverhalten. Im KI-Tooling siehst du die Modell-Metriken, aber nicht, welcher Server gerade überlastet war, als der Agent seine Entscheidung traf.

Diese Trennung schafft eine praktische Notlage. DevOps- und SRE-Teams sind es gewohnt, bei einer Störung alle verfügbaren Datenquellen zu durchforsten. Bei KI-Agenten müssen sie zwischen verschiedenen Dashboards wechseln, Daten von Hand korrelieren und am Ende oft raten, was tatsächlich passiert ist. Die Zeit bis zur Lösung eines Problems wächst, und die Fehlerkultur leidet, weil Symptome statt Ursachen behandelt werden.

Was Arize konkret in die Übernahme einbringt

Arize ist in der KI-Community kein Unbekannter. Das Unternehmen bietet eine Plattform zur Beobachtung und Bewertung von Modellen und Agenten. Arizes Tools verfolgen, was während eines Agentenlaufs passiert: Modellaufrufe, Abfragen an Retrieval-Systeme, die Nutzung externer Werkzeuge und die daraus resultierenden Trajektorien – also den kompletten Weg von der Eingabe bis zur Ausgabe. Diese Informationen dienen nicht nur der Fehlersuche, sondern auch der laufenden Qualitätskontrolle. Du kannst bewerten, ob ein Agent zuverlässig arbeitet, ob er in einer Schleife hängt oder ob er ungewollte Aktionen ausführt.

Jason Lopatecki, Mitgründer von Arize, sagte gegenüber DevOps.com, dass sein Unternehmen täglich Milliarden von Ereignissen aus Agentenläufen sammelt. Das zeigt die Größenordnung, in der moderne KI-Systeme arbeiten. Jeder Schritt eines Agenten hinterlässt eine Spur, die für die spätere Analyse unerlässlich ist. Lopatecki sieht in der Verbindung mit Dynatraces Telemetrie die Chance, diese beiden Sichten zusammenzuführen. Arize liefert die Perspektive des Agenten, Dynatrace die Perspektive der Umgebung – also die Transaktionen, Services und Server, mit denen der Agent interagiert.

Diese Kombination ist mehr als eine einfache Addition. Sie ermöglicht, die bisher getrennten Welten der Modell- und Infrastrukturbeobachtung in einem einzigen Kontext zu sehen. Wenn ein Agent eine fehlerhafte Antwort liefert und gleichzeitig ein bestimmter Microservice überlastet war, kannst du diese Fakten in Beziehung setzen. Du erkennst, ob die Fehlentscheidung auf ein Modellproblem zurückgeht oder darauf, dass der Agent nicht rechtzeitig die richtigen Informationen aus einem überlasteten Backend erhalten hat.

Der Wert der Verknüpfung: Ein durchgängiger Lösungspfad

Mitch Ashley, Vice President und Practice Lead für Software-Lifecycle-Engineering bei der Futurum Group, bringt den Kern der Übernahme auf den Punkt. Er sagt: „Dynatrace zahlt 915 Millionen Dollar für die Observability-native Verbindung zwischen KI-Beobachtung und Agentenverhalten. Ein KI-Ingenieur misst die Ausgabequalität in einem eigenen Tool. Ohne diese Verbindung sieht der diensthabende SRE eine fehlgeschlagene Transaktion und findet keinen Weg zurück zum Prompt.“ Die 915 Millionen sind der Preis für die Brücke zwischen der Welt der Modelle und der Welt der Systeme.

Für dich als DevOps- oder Plattform-Ingenieur bedeutet das im Idealfall einen Sprung nach vorn. Statt bei einem Vorfall mehrere Systeme parallel abzufragen, könntest du künftig von der Agenten-Trajektorie aus direkt in die zugehörigen Infrastruktur- und Transaktionsdaten springen. Du bekommst eine durchgehende Spur, die von der Benutzeranfrage über die Entscheidungen des Agenten bis zum Serveraufruf führt. Das klingt einfach, ist aber ein Paradigmenwechsel in der Fehleranalyse.

Die technische Umsetzung ist nicht trivial. Dynatrace muss die Datenmodelle beider Plattformen integrieren, gemeinsame IDs für Anfragen schaffen und sicherstellen, dass die Telemetrie über verschiedene Systeme hinweg konsistent bleibt. Das ist langwierige Arbeit, die mit der Ankündigung allein nicht erledigt ist. Doch genau diese Integration verspricht den eigentlichen Mehrwert: nicht nur bessere Dashboards, sondern eine neue Art, KI-Systeme in der Produktion zu verstehen und zu steuern.

Verification Debt: Wenn Agenten zur Prüfungsaufgabe werden

Die Herausforderung geht über die technische Fehlersuche hinaus. Sobald Agenten eigenständig Handlungen in der Produktion ausführen – etwa Bestellungen auslösen, Tickets aktualisieren oder auf Datenbanken zugreifen –, brauchst du eine lückenlose Aufzeichnung dessen, was sie getan haben. Diese Aufzeichnung dient der Nachvollziehbarkeit bei Fehlern, der Einhaltung von Compliance-Vorschriften und nicht zuletzt dem Vertrauen in die Systeme. Ohne eine solche Spur ist es unmöglich zu beweisen, dass ein Agent richtig gehandelt hat. Genau da entsteht laut Mitch Ashley eine neue Art von Schulden.

Er nennt es „Verification Debt“ – die Last der Verifizierung, die auf Plattformteams lastet. Wenn Unternehmen Agenten nur so schnell ausliefern können, wie sie beweisen können, dass das Verhalten dieser Agenten verantwortbar ist, wird die Prüfung zu einem zeitlichen und personellen Engpass. Du endest mit einem Backlog an Review-Aufgaben, die manuell abgearbeitet werden müssen, weil die Werkzeuge keine automatische Bewertung ermöglichen. Die Übernahme von Arize durch Dynatrace zielt genau auf dieses Problem ab: Sie will die Daten liefern, die eine automatische oder zumindest halbautomatische Verifikation erlauben.

Ein wichtiger Punkt betrifft die Übergänge zwischen verschiedenen Anbietern. Agenten laufen oft über mehrere Systeme hinweg – sie nutzen Cloud-Dienste von einem Hersteller, interne APIs von einem anderen und externe LLMs von einem dritten. Ashley betont, dass die Spur der Verantwortlichkeit diese Grenzen überstehen muss. Andernfalls verlierst du die Nachvollziehbarkeit genau an den Stellen, wo sie am wichtigsten ist. Diese Anforderung an Kontinuität erklärt, warum eine einzelne Firma wie Dynatrace mit ihrem breiten Telemetrie-Angebot als Käufer auftritt – sie will die Lücken von vornherein schließen, statt mit vielen Einzellösungen zu flicken.

Wie sich das Investitionsklima und die Entwicklerbasis verändern

Abgesehen von der Technologie hat die Übernahme strategische Dimensionen. Rick McConnell, CEO von Dynatrace, erwartet, dass die Nachfrage nach KI-Observability weiter wachsen wird, je mehr KI-Systeme produktiv gehen. Mit Arize holt sich Dynatrace nicht nur Technologie, sondern auch ein Team, das jahrelange Erfahrung im Umgang mit Modell- und Agentenbeobachtung hat. Dieser Know-how-Transfer könnte die Produktentwicklung beschleunigen und neue Funktionen schneller auf den Markt bringen.

Ein zweiter Aspekt ist die Reichweite. Arize hat eine starke Community unter KI-Ingenieuren und Data-Science-Teams. Diese Zielgruppe war bisher nicht im Zentrum von Dynatraces klassischem Kundenstamm, der vor allem aus Unternehmens-DevOps- und SRE-Teams besteht. Durch die Übernahme könnte Dynatrace in diesen Markt eintauchen und das eigene Produkt für Entwickler attraktiver machen, die vorher mit separaten Tools gearbeitet haben. Die mächtige Unternehmensplattform verbindet sich mit der agilen Entwicklerwelt der KI-Spezialisten.

Der Preis von 915 Millionen Dollar ist beachtlich, aber er spiegelt die Dringlichkeit wider. Wer die KI-Infrastruktur der nächsten Jahre kontrollieren will, muss Observability bieten, die mit der Komplexität neuer Systeme Schritt hält. Seit Monaten kursiert in der Branche die Frage, welcher Observability-Anbieter die Nase vorn hat. Dynatrace setzt mit diesem Deal ein klares Zeichen – und die Konkurrenz wird vermutlich nachziehen müssen, um ähnliche Integrationsangebote zu schaffen.

Für dich als praktisch arbeitender Entwickler oder Betreiber ändert sich dadurch zunächst nicht sofort alles. Die Übernahme muss noch abgeschlossen werden, und die Integration wird dauern. Doch die Richtung ist klar: Die Tage, an denen du für KI-Systeme zwei oder drei getrennte Monitoring-Welten pflegst, sind gezählt. Die nächste Generation von Observability behandelt KI-Bausteine als natürlichen Teil des verteilten Systems – mit derselben Selbstverständlichkeit, mit der du heute einen Container oder einen Prozess überwachst. Das ist die logische Konsequenz aus einem Kauf, der zeigt, wie sehr sich das Verständnis von Produktionsreife verändert hat.

Quelle: devops.com

Viele gehen davon aus, dass eine Plattform mit 180 Millionen Nutzern und Milliarden von Code-Repositories unerschütterlich ist. Am Montagmorgen des 17. August 2026 bewies GitHub das Gegenteil. Was als kleiner technischer Haken begann, stoppte innerhalb weniger Minuten Entwicklerteams weltweit. Betroffen waren nicht nur einzelne Repositories, sondern das gesamte Ökosystem moderner Softwareentwicklung.

Als Entwickler oder DevOps-Ingenieur nutzt du GitHub vermutlich so selbstverständlich wie das Atmen. Du pushst Code, startest Pipelines, lässt Copilot Vorschläge generieren. Wenn das plötzlich nicht mehr funktioniert, steht nicht nur dein aktueller Task still, sondern das gesamte agile Getriebe deines Teams. Genau das passierte: Fehlerraten bis zu 50 Prozent bei zentralen Funktionen, Authentifizierungsprobleme, die selbst eingeloggte Nutzer blockierten, und eine Verunsicherung, die sich in sozialen Netzwerken ausbreitete. Dieser Ausfall ist kein Randereignis. Wir sollten genau hinschauen, was schieflief.

Was am Montagmorgen geschah: Die Fakten

Die Störung begann gegen 9:40 Uhr Ostküstenzeit. Nutzer meldeten auf Downdetector fehlgeschlagene Repository-Zugriffe, defekte Downloads und langsame Antwortzeiten. GitHub bestätigte erhöhte Fehlerquoten. Rund 20 Prozent der Anfragen an die Web-Oberfläche und die API schlugen fehl. Das wäre schon störend. Die eigentliche Eskalation folgte bei tiefer liegenden Diensten.

Die Rohdaten für Repository-Inhalte und Archiv-Downloads – die Dateien, die du direkt von GitHub ziehst – wiesen Fehlerraten von nahezu 50 Prozent auf. Für viele Nutzer war die Plattform wortwörtlich ein halbes Nichts. Parallel dazu kollabierten die Enterprise-Authentifizierungsmechanismen: SAML, OIDC, SCIM und Team Sync. Diese Sicherheitsstandards, die Unternehmen für Single Sign-On und Nutzerverwaltung benötigen, waren weitgehend unbrauchbar. Besonders pikant: Auch GitHub Copilot und GitHub Actions meldeten weitreichende Einschränkungen. Sogar Microsoft Teams zeigte kleinere Aussetzer. Das deutet darauf hin, dass die Störung tiefer in der gemeinsamen Infrastruktur verankert war.

Authentifizierung als Flaschenhals: Die technische Bedeutung

Warum ist Authentifizierung so kritisch? GitHub ist nicht nur ein Ort, an dem du Code aufbewahrst. Die Plattform ist mit vielen Identitäts- und Zugriffsprotokollen verzahnt. Unternehmen nutzen SAML oder OIDC, um Mitarbeiter über den eigenen Identitätsanbieter bei GitHub anzumelden. Fällt dieser Teil aus, können sich selbst Nutzer mit korrekten Zugangsdaten nicht einloggen – oder sie werden sofort wieder ausgesperrt. SCIM und Team Sync verwalten die Synchronisierung von Benutzergruppen. Wenn diese Zuordnung kippt, verlieren Entwickler den Zugriff auf private Repositories, CI/CD-Pipelines und Deployment-Umgebungen.

Die Konsequenz ist ein Ketteneffekt: Automatisierte Builds schlagen fehl, Tests lassen sich nicht starten, die ohnehin hektische Montagsroutine kommt zum Stillstand. Viele Teams starten ihre wöchentlichen Sprints genau zu diesem Zeitpunkt. Ein solcher Ausfall trifft sie mitten in der produktivsten Phase der Woche. Die hohe Fehlerquote bei den Rohdaten-Downloads verschärft das Problem: Selbst wenn du dich durchgekämpft hast, kannst du weder aktuelle Branch-Stände noch historische Releases abrufen. Jede Form lokaler Arbeit blockiert.

Copilot und Actions: Wenn die Zukunft zur Achillesferse wird

Ausgerechnet GitHub Copilot und GitHub Actions waren betroffen. Diese beiden Dienste repräsentieren die Zukunft der Plattform – das ist die Ironie. Copilot, der KI-gesteuerte Pair-Programmer, und Actions, das Automatisierungssystem für CI/CD, sind stark von der zentralen Infrastruktur abhängig. Sie benötigen stabile API-Verbindungen, funktionierende Authentifizierung und ein reibungsloses Datenabrufsystem. Wenn eines davon kippt, hilft auch die beste KI nicht weiter.

Viele Unternehmen setzen seit Jahren verstärkt auf diese Werkzeuge. Sie erwarten, dass Copilot Code-Vorschläge liefert und Actions Tests automatisch ausführt. Dass genau diese Systeme bei einem Infrastrukturproblem komplett lahmlegen, zeigt eine grundlegende Verwundbarkeit: Unsere KI-gestützte Arbeitsweise verstärkt die Abhängigkeit von den Plattformen darunter. Wenn du erlebst, wie ein einziger Fehler in der zentralen Infrastruktur deine gesamte DevOps-Kette zum Erliegen bringt, verstehst du: Es geht nicht um ein paar Minuten Wartezeit, sondern um einen fundamentalen Engpass, der selbst ausgeklügelte Automatisierungen überflüssig macht.

Der Zeitpunkt als Katalysator: Warum Montagmorgen so weh tat

Die zeitliche Komponente ist nicht zu unterschätzen. Montagmorgen ist für viele Engineering-Teams der Moment, in dem neue Sprints beginnen, Merge Requests zusammengeführt werden und kritische Releases anstehen. Die Störung traf genau die Phase, in der die Auslastung traditionell hoch ist – und die Frustration ebenfalls. Die Meldungen auf Downdetector zeigen, dass bereits in den ersten zwanzig Minuten Tausende von Nutzern Probleme meldeten. In sozialen Netzwerken füllten sich Screenshots von Fehlermeldungen, sarkastische Kommentare und – bezeichnenderweise – Stimmen, die auf „immer wiederkehrende“ kleinere Aussetzer in den Wochen zuvor hinwiesen.

Diese Beobachtung ist keine Randnotiz. Sie deutet darauf hin, dass die Plattform seit einiger Zeit an Kapazitätsgrenzen arbeitet. Die Entwickler von GitHub haben selbst eingeräumt, dass sie ihre Infrastruktur massiv ausbauen mussten, um mit dem durch die KI-Welle ausgelösten Nutzerwachstum Schritt zu halten. Der Ausfall könnte also weniger ein einmaliger Betriebsunfall sein, sondern ein Symptom struktureller Probleme: Ein System, das ursprünglich für eine kleinere Gemeinschaft konzipiert wurde, verarbeitet heute Hunderttausende gleichzeitiger KI-Anfragen und automatisierter Workflows. Diese Lastspitzen führen zu Engpässen, die sich in solchen großflächigen Störungen entladen.

Was GitHub unternimmt – und was wir daraus lernen können

Bis 12:36 Uhr EDT hatte GitHub die fehlerhafte Komponente identifiziert und erste Korrekturmaßnahmen eingeleitet. Die Statusseite meldete „starke Anzeichen der Erholung“, auch wenn die Fehlerraten noch leicht erhöht waren. Eine offizielle Ursache wurde nicht genannt. Das Unternehmen kündigte an, dass nach vollständiger Stabilisierung aller Regionen eine detaillierte Nachbetrachtung erfolgen werde. Diese Verzögerung ist typisch für große Infrastrukturbetreiber: Sie wollen keine voreiligen Schlüsse veröffentlichen, sondern erst die Daten analysieren.

Für uns als Nutzer bedeutet das: Wir bewegen uns in einem hochgradig vernetzten System, das nicht unbegrenzt skalierbar ist – auch wenn die Plattform noch so groß erscheint. Die DevOps-Praxis lehrt uns, für Ausfälle zu planen. Wenn du in deinem Unternehmen für die Wahl der Tools verantwortlich bist, ist dieser Ausfall ein Argument für eine mehrschichtige Backup-Strategie: lokale Git-Mirrors, alternative CI/CD-Anbieter, redundante Authentifizierungspfade. Der Montag hat klar gezeigt: Auch der größte Player kann stolpern. Wenn das passiert, stehen nicht nur einzelne Repositories still, sondern das komplette globale Gefüge der Softwareentwicklung.

Quelle: devops.com

„Critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents and can still pass established automated security checks.“ – So steht es in einem aktuellen Wiz-Blogpost. Der Satz beschreibt einen Vorfall im Juni 2026. Ein autonomer KI-Agent hat innerhalb weniger Tage eine kritische Schwachstelle in einem öffentlichen GitHub-Repository von Snowflake gefunden und ausgenutzt. Der Code stammte von KI, die Schwachstelle passierte alle automatisierten Prüfungen.

Das ist keine Theorie. Es geht um echten Code, echte Credentials und einen Angriff auf die Infrastruktur eines führenden Cloud-Datenunternehmens. Hier die Schritte: Was ist passiert? Warum versagten die üblichen Sicherheitsmechanismen? Und was heißt das für deine Workflows?

Der Fund: Eine Script-Injection im GitHub-Actions-Workflow

Wiz Research war im Rahmen von Snowflakes HackerOne-Programm unterwegs. Ihr Werkzeug: Red Agent, ein autonomer, KI-gesteuerter Sicherheitsforschungsagent. Er scannte die GitHub-Organisation von Snowflake und wurde im Repository snowflakedb/snowflake-connector-net fündig. In einer Datei namens jira_issue.yml – ein GitHub-Actions-Workflow, der automatisch ein Jira-Ticket erstellt, wenn jemand ein GitHub-Issue eröffnet.

Der Workflow war anfällig für eine Script-Injection. Jeder, der ein GitHub-Issue mit einem manipulierten Titel eröffnete, konnte beliebige Befehle im Runner des Workflows ausführen. Ein unauthentifizierter Angriff. Ohne Zugang oder spezielle Rechte. Das ist bemerkenswert – aber die Hintergründe sind es mehr.

Die Schwachstelle entstand durch eine Kette von Umständen, nicht durch einen einzelnen Fehler. Ein Pull Request (PR #1218) mit dem Titel „SNOW-2069227: Update jira workflows“ brachte die Änderung in den Code. In diesem PR wurde ein sicheres Muster durch eine direkte Interpolation von unkontrolliertem Input ersetzt. Die Zeile nutzte ${{ github.event.issue.title }} direkt in einem Shell-Befehl. Die Absicherung per sed-Escaping kam zu spät – nachdem GitHub die Template-Expansion bereits durchgeführt hatte. Ein einfaches Anführungszeichen im Issue-Titel genügte, um aus der Echo-Zeile auszubrechen und Code einzuschleusen.

Warum die Sicherheitsprüfung versagte

Hier wird es interessant. Der PR wurde nicht blind gemerged. Er durchlief mehrere Sicherheitsstufen, die alle nichts bemerkten. Erste Stufe: GitHub Advanced Security. Dieser Scan analysierte die finale Revision des PRs – genau den Code, der später live ging. Trotzdem wurde die Injection nicht erkannt. Der Scan extrahierte sogar den verwundbaren Workflow – aber ohne Warnung.

Zweite Stufe: die Beteiligung von KI. Innerhalb desselben PRs hatte GitHub Copilot Autofix einen Fix für eine andere Datei (jira_close.yml) beigesteuert. Copilot wird in dem Blogpost als Co-Autor genannt, der den gemergten PR und die Code-Änderung überprüfte – und grünes Licht gab, ohne die kritischen Schwachstellen zu bemerken. Ob die eigentliche Code-Änderung KI-assistiert war, bleibt unklar. Entscheidend ist: Eine KI hat mitgeprüft, und niemand hat den Fehler gesehen.

Dazu kommt eine dritte Komponente, die wie eine offene Sicherheitstür wirkt: Der Workflow hatte eine if-Bedingung, die wie eine Zugriffsbeschränkung aussah. Doch sie prüfte auf github.event.pull_request – und bei Events vom Typ issues ist dieses Feld immer leer. Die Bedingung reduzierte sich also auf einen Vergleich, der immer wahr ist. Jeder Benutzer – ob angemeldet oder nicht – konnte den Workflow auslösen. Ein klassischer Fall von falsch verstandener Sicherheitslogik.

So funktionierte der Angriff

Wiz‘ Red Agent identifizierte die Schwachstelle und nutzte sie bis zur Eskalation aus. Der Agent erstellte ein GitHub-Issue mit einem manipulierten Titel, der nach der Template-Expansion den Shell-Befehl sprengte. Ziel: die Jira-Zugangsdaten aus der Umgebung zu exfiltrieren. Der erste Versuch schlug fehl, weil ein Kommentarzeichen (#) den Rest der Zeile auffraß und zu einem Syntaxfehler führte.

Der Red Agent stoppte nicht. Er analysierte den Fehler, baute den Payload um und schickte einen zweiten Versuch. Diesmal nutzte er ; echo ', um die Shell-Syntax korrekt zu schließen. Innerhalb weniger Sekunden lief der Callback auf einer Azure-IP (20.106.182.197) ein und offenbarte base64-kodierte Zugangsdaten. Der exfiltrierte Token gehörte zu qa@snowflake.net und erlaubte Lesezugriff auf verschiedene Jira-Projekte von Snowflake, darunter Engineering, Security Compliance und Bug Bounty Tracking.

Die Tricktechnik ist bekannt. Bemerkenswert ist, dass ein KI-Agent eigenständig einen Fehler behebt und seine Angriffsstrategie anpasst. Das kannten wir bisher nur aus Forschungslaboren. Jetzt sehen wir es in der Praxis – und es funktioniert schnell.

Die Reaktion von Snowflake: Schnell und sauber

Nachdem der Red Agent die Schwachstelle gefunden und validiert hatte, meldete Wiz sie am 23. Juni 2026 über HackerOne (Report #3819931). Snowflake reagierte professionell. Noch am selben Tag wurde der verwundbare Workflow gepatcht – die sichere env-Variable und das jq --arg-Muster wurden wiederhergestellt. Das Jira-Token wurde rotiert, und eine detaillierte Prüfung der Audit-Logs bestätigte, dass während des fünftägigen Exposure-Zeitraums niemand anderes als Wiz auf die Daten zugegriffen hatte.

Snowflake betont in ihrer offiziellen Antwort, dass man die Verantwortung ernst nehme und die Erkenntnisse mit der Branche teilen wolle. Der Vorfall wurde nicht unter den Teppich gekehrt, sondern als Gelegenheit genutzt, Sicherheitspraktiken zu verbessern. Das ist vorbildlich – auch wenn der Anlass unangenehm war.

Die Timeline zeigt, wie dünn die Zeitfenster geworden sind: Am 18. Juni wurde der verwundbare PR gemerged. Fünf Tage später – am 23. Juni – fand der autonome Agent die Lücke und nutzte sie aus. Innerhalb weniger Stunden. Tagelange manuelle Analyse? Fehlanzeige. Das ist das neue Tempo, auf das sich Unternehmen einstellen müssen.

Was wir daraus lernen müssen

Erste Lehre: der Umgang mit KI-generiertem Code. KI-Tools wie Copilot generieren Code auf Basis wahrscheinlicher Muster – und diese Muster können veraltet oder unsicher sein. Im konkreten Fall hat ein PR das bewährte, sichere Muster durch eine direkte Interpolation ersetzt – vermutlich ein „einfacher“ Fix, wie er in vielen Codebases vorkommt. Sicherheitsteams müssen KI-unterstützte Pull Requests genauso streng prüfen wie von Menschen geschriebene. Static Analysis und Security-Scans dürfen nicht nur auf die letzte Revision schauen, sondern müssen auch die semantische Sicherheit der Änderungen abdecken.

Zweite Lehre: die Erkennungszeiten. Red Agent hat die Schwachstelle in fünf Tagen gefunden und ausgenutzt – vollautomatisch. In einer Welt mit autonomen Angriffsagenten gibt es keine 90-Tage-Fristen mehr. Unternehmen brauchen schnelle Patch-Zyklen und kurzlebige Credentials. Ein Jira-Token, das wochenlang gültig ist, ist ein unnötiges Risiko. Privilege Access Management und regelmäßige Rotation sollten Standard sein.

Dritte Lehre, vielleicht die wichtigste: Sicherheitsmuster müssen explizit durchgesetzt werden. Im verantwortlichen PR wurde ein sicheres Pattern einfach entfernt – ohne dass die Sicherheitslösung angeschlagen hätte. Das passiert, wenn statische Analyse-Regeln auf Code-Snippets abzielen, nicht auf die Abwesenheit von bestimmten Mustern. Prüfe in deiner eigenen CI/CD-Pipeline nicht nur auf bekannte Schwachstellen, sondern auch auf unsichere Codierungsmuster wie direkte Interpolation von Kontextwerten in Shell-Befehle.

Fazit: Die neue Ära von Angriff und Verteidigung

Dieser Vorfall markiert einen Wendepunkt. Zum ersten Mal sehen wir in freier Wildbahn, wie ein autonomer KI-Agent einen kompletten Angriffszyklus durchläuft – von der Entdeckung über die Exploitation bis zur Exfiltration. Gleichzeitig zeigt er, wie verletzlich CI/CD-Pipelines sind, die auf menschliche Prüfer und herkömmliche Scanner vertrauen. Die Lücke war nicht exotisch – eine klassische Script-Injection, nur eben in einem GitHub-Actions-Workflow. Dass GitHub Advanced Security sie nicht erkannt hat, ist ein Weckruf für alle, die blind auf automatisierte Sicherheitschecks vertrauen.

Es gibt Gegenmittel. Kurzlebige Credentials, strikte Validierung von Inputs, Semgrep-Regeln gegen gefährliche Interpolationsmuster und eine Security-Kultur, die KI-Code genauso skeptisch betrachtet wie menschlichen Code. Und vielleicht der wichtigste Punkt: Die Verteidigung darf nicht hinter der Angriffstechnik zurückbleiben. Wiz‘ Red Agent zeigt, wie KI die offensive Sicherheit automatisiert. Dieselbe Technologie steckt auch in defensiven Tools – sie muss nur konsequent eingesetzt werden.

Für dich als Entwickler oder DevOps-Verantwortlicher heißt das: Schau nicht weg, wenn es um deine Workflows geht. Überprüfe, wo du github.event-Daten in Shell-Befehle einbindest. Setze Regeln, die solche Muster verbieten. Der Feind schläft nicht – und lernt auch noch dazu.

Quelle: wiz.io

Ein vertrauliches Update an Investoren zeigt: Anthropics annualisierte Umsatzrate hat Ende Juli die Marke von 65 Milliarden Dollar überschritten. Das ist eine Versiebenfachung im Vergleich zum Vorjahr.

Die Zahl ist eine Hochrechnung: Wenn ein Unternehmen so weiterwirtschaftet wie im letzten Monat, wie viel würde es in einem Jahr einnehmen? Anthropic gibt diesen Wert für Juli mit 65 Milliarden Dollar an – mehr als das Siebenfache des Vorjahreszeitraums.

Was die 65 Milliarden Dollar wirklich bedeuten

Eine Run Rate ist keine echte Umsatzzahl, sondern eine Projektion. Sie entsteht, wenn du den Umsatz eines Monats oder Quartals nimmst und auf zwölf Monate hochrechnest. Bei Anthropic sieht das so aus: Im zweiten Quartal 2026 hat das Unternehmen vorläufig 11,5 Milliarden Dollar umgesetzt – 14-mal so viel wie im gleichen Zeitraum 2025. Hochgerechnet ergibt das rund 46 Milliarden. Die 65 Milliarden im Juli deuten auf ein noch stärkeres drittes Quartal hin.

Die Dynamik ist bemerkenswert. Vor einem Jahr lag die Run Rate bei etwa 9 Milliarden, jetzt sind es 65. Das ist kein lineares Wachstum, sondern eine exponentielle Beschleunigung. Unternehmen, die KI-basierte Werkzeuge wie den Assistenten Claude verkaufen, finden offenbar massenhaft Kunden in der Wirtschaft. Der Hype um künstliche Intelligenz hat sich in konkrete Verträge verwandelt.

Solche Zahlen solltest du mit Vorsicht genießen. Eine Run Rate kann nach oben verzerren, wenn ein Quartal besonders stark war. Trotzdem zeigt der Trend: Anthropic ist kein reines Forschungslabor mehr, sondern ein ernstzunehmendes Geschäft.

Der Wettlauf mit OpenAI und der Markt

Der Vergleich mit dem Konkurrenten OpenAI macht die Dimension klar. OpenAI meldete zuletzt eine annualisierte Umsatzrate von 40 Milliarden Dollar – deutlich weniger als Anthropic. Das überrascht, denn OpenAI war lange das bekannteste KI-Unternehmen. Doch Anthropic konzentriert sich auf Unternehmenskunden, und genau dieser Markt boomt.

Die Nachfrage nach KI-Anwendungen in Firmen ist riesig. Vom automatisierten Kundensupport bis zur Datenanalyse – Unternehmen wollen Produktivitätsgewinne und zahlen dafür. Anthropic bewirbt Claude besonders für sicherheitskritische Umgebungen. Das kommt bei Banken, Versicherungen und Behörden gut an.

Für dich als Nutzer bedeutet das: Die KI-Landschaft wird dynamischer. Neben ChatGPT gibt es mindestens einen zweiten Player, der sogar schneller wächst. Der Wettbewerb treibt Innovation und senkt langfristig die Preise.

Der Weg an die Börse: IPO-Pläne und Fantasie

Hinter den Zahlen steckt eine strategische Mission. Anthropic hat im Juni vertraulich einen Börsenprospekt bei der US-Börsenaufsicht SEC eingereicht. Seitdem führt das Unternehmen Gespräche mit potenziellen Investoren. Die Bewertung liegt bei 965 Milliarden Dollar – fast einer Billion. Das übersteigt den Marktwert der meisten Tech-Riesen.

Ein Börsengang dieser Größenordnung wäre historisch. Er würde Anthropic Kapital verschaffen und den gesamten KI-Sektor befeuern. Du könntest frühzeitig an einem Unternehmen beteiligt sein, das den Markt für Unternehmenssoftware revolutioniert. Aber hohe Bewertungen bedeuten hohe Erwartungen. Wenn das Wachstum nachlässt, kann die Aktie stark schwanken.

Die Reaktionen auf den Börsengang sind gemischt. Manche Investoren sehen die 965 Milliarden als gerechtfertigt, weil der Markt für KI-Anwendungen noch am Anfang steht. Andere erinnern an die Dotcom-Blase. Eine kluge Herangehensweise ist, die Fundamentaldaten im Auge zu behalten – echte Umsätze, nicht nur Projektionen.

Exportkontrollen und Pentagon: Stolpersteine im Aufstieg

So glänzend die Zahlen sind, es gibt Schattenseiten. Im Juni musste Anthropic zwei seiner fortschrittlichsten Modelle, Claude Fable 5 und Mythos 5, vorübergehend vom Netz nehmen. Der Grund: eine Exportkontrollanordnung der US-Regierung, die sich auf „nationale Sicherheitsbehörden“ bezog. Nach zwei Wochen Verhandlungen wurden die Modelle wieder aktiviert. Der Vorfall zeigt, wie eng Technologie und Politik verwoben sind.

Dazu kommt die Blacklist durch das Pentagon. Anfang des Jahres hatte das US-Verteidigungsministerium Anthropic von der Zusammenarbeit ausgeschlossen, nachdem Gespräche über militärische Nutzungsmöglichkeiten eskaliert waren. Für ein Unternehmen, das Sicherheit und Ethik großschreibt, sind solche Konflikte mehr als PR-Probleme – sie können Geschäftsmodelle gefährden.

Technologie entwickelt sich nicht im luftleeren Raum. Regierungen haben ein gewichtiges Wort mitzureden – bei Exporten, in der Forschung, in der Anwendung. Wer in KI investiert oder sie beruflich einsetzt, sollte solche geopolitischen Risiken im Blick behalten. Anthropic hat das selbst erfahren müssen.

Was das für dich und die KI-Zukunft bedeutet

Die 65-Milliarden-Marke ist mehr als eine Zahl. Sie zeigt, dass KI Unternehmen realen Mehrwert liefert. Die Wachstumsraten erinnern an die frühen Tage des Internets – und die damit verbundenen Risiken sind deutlich sichtbar geworden.

Wenn ein Unternehmen solche Zahlen vermeldet, lohnt sich der Blick auf die Details. Woher kommt das Wachstum? Wie nachhaltig ist es? Welche externen Faktoren könnten es ausbremsen? Bei Anthropic sind das die Regierungsbeziehungen und die Abhängigkeit von einigen wenigen Großkunden im Enterprise-Bereich.

Das Tempo ist beeindruckend. Innerhalb von gut einem Jahr hat sich der Umsatz versiebenfacht. Das ist selbst in der Tech-Welt außergewöhnlich. Wenn sich der Trend fortsetzt, sprechen wir in zwei Jahren über andere Dimensionen. Vielleicht ist dann auch der Börsengang Geschichte.

Die KI-Welle ist nicht mehr aufzuhalten. Ob als Chance oder Bedrohung – die wirtschaftliche Realität ist da. Unternehmen wie Anthropic liefern die Werkzeuge, und der Markt belohnt sie dafür. Deine Aufgabe ist es, die Entwicklung aufmerksam zu verfolgen und Entscheidungen auf fundierten Informationen aufzubauen.

Quelle: cnbc.com

„As we scaled post-training, cyber capability developed faster than we expected.“ Mit diesen Worten begründete Z.ai die Entscheidung, die Gewichte von GLM-5.3 zunächst zurückzuhalten. Die Aussage wirkt überraschend, doch die begleitenden Zahlen zeigen ein differenzierteres Bild.

Z.ai hat am vergangenen Freitag GLM-5.3 veröffentlicht, allerdings mit einer wichtigen Einschränkung: Die Download-Gewichte werden erst um den 28. August verfügbar sein. Das ist das erste Mal, dass Z.ai einen Modell-Release verzögert. Bisher galt das Unternehmen als einer der wenigen großen Anbieter, die ihre Modelle offen zum Download anbieten. Jetzt übernimmt Z.ai die Zugangskontrollen, die amerikanische Labs wie Anthropic und OpenAI bei ihren sensibelsten Cyber-Modellen bereits etabliert haben. Die Testergebnisse erklären den Schritt.

Die Benchmark-Zahlen: Ein Sieg mit Schönheitsfehlern

Die zentrale Kennzahl stammt aus Z.ai’s eigenem CyberGym-Test. Dort erreichte GLM-5.3 84,5 Prozent und schlug damit Anthropics Mythos 5 (83,8 Prozent) sowie GPT-5.6 Sol (83,6 Prozent). Das klingt nach einem deutlichen Sieg. Der Test umfasste 1.507 Aufgaben aus 188 Software-Projekten. Zum Vergleich: GLM-5.2 schaffte im selben Setup nur 77,2 Prozent. Die Steigerung um über sieben Prozentpunkte ist beachtlich und erklärt teilweise die Vorsicht des Unternehmens.

Doch der Vorsprung schmilzt, sobald man von der Schwachstellensuche zur Schwachstellenausnutzung übergeht. Auf ExploitBench, einem Benchmark, der die Fähigkeit zur Entwicklung vollständiger Exploit-Ketten misst, erreicht GLM-5.3 nur 54,4 Prozent. Anthropics Mythos 5 kommt dort auf 78,0 Prozent. Ähnlich sieht es bei ExploitGym aus: GLM-5.3 schafft 105 Aufgaben unter einem Zwei-Stunden-Budget, Mythos 5 bewältigt 181. Selbst bei sechs Stunden bleibt die Lücke bestehen – 130 gegen 247 Aufgaben.

Z.ai hat die Lücke bei der Schwachstellensuche geschlossen, liegt aber bei der Exploit-Entwicklung deutlich zurück. Die Fähigkeit, Schwachstellen zu finden, ist nicht dasselbe wie die Fähigkeit, sie auszunutzen. Für die Sicherheitsbewertung zählt vor allem die vollständige Angriffskette, nicht der bloße Fehlerfund.

Die Schwachstellenliste: Was Z.ai tatsächlich gefunden hat

Z.ai hat parallel zu den Testergebnissen eine Schwachstellenliste veröffentlicht. Stand 14. August umfasst diese Liste 2.436 Funde in 269 Open-Source-Projekten. Darunter sind 107 kritische Fehler und 990 als hoch eingestufte Schwachstellen. Nur 53 dieser Funde wurden bereits öffentlich gemacht, 2.383 befinden sich noch unter Embargo.

Die betroffene Software umfasst zentrale Projekte der kritischen Infrastruktur: Linux-Kernel, Redis, WebKit und FreeBSD. Der älteste gefundene Fehler stammt aus dem Jahr 1981. Im Durchschnitt blieben die Schwachstellen 26,6 Jahre unentdeckt. Das zeigt die schleichende Verschuldung in der Softwaresicherheit: Code, der seit Jahrzehnten in Produktion ist, enthält unentdeckte Fehler.

Diese Liste belegt, dass das Modell nicht nur in synthetischen Benchmarks funktioniert. Allerdings stammt auch diese Liste von Z.ai selbst. Eine unabhängige Bestätigung der Cyber-Ergebnisse gibt es bisher nicht. Artificial Analysis, ein unabhängiger Benchmark-Anbieter, hatte GLM-5.3 bis zum 14. August noch nicht in seine Tests aufgenommen. Die Ergebnisse beruhen vollständig auf Z.ai’s eigener Harness-Konfiguration.

Entwicklungsdynamik: Warum die Cyber-Fähigkeiten so schnell wachsen

Z.ai erklärt den Entwicklungssprung mit einem Monat intensivem Post-Training. Das Modell basiert auf dem gleichen Grundmodell wie GLM-5.2, aber mit erweiterten Aufgabenumgebungen, einer breiteren Mischung an Aufgaben und mehr Rechenzeit. Nach den Angaben des Unternehmens hat das Post-Training gezielt Schwachstellen-Findung gefördert – mit unerwarteten Nebenwirkungen.

„Wir haben absichtlich Vulnerability-Discovery-Arbeit hinzugefügt“, sagte das Unternehmen, „aber das Modell entwickelte sich vom Finden isolierter Fehler hin zur Planung kompletter Exploit-Ketten.“ Diese Entwicklung verlief offenbar schneller als erwartet. Diese Eigendynamik bewog Z.ai, die Veröffentlichung der Gewichte zu verschieben. Denn einmal veröffentlicht, verliert das Unternehmen jede Kontrolle über die Nutzung.

Das Vorgehen erinnert an Anthropic, das Mythos 5 im Juni ebenfalls nur an verifizierte Partner freigab. „Da diese Fähigkeit das größte Missbrauchspotenzial im Sicherheitsbereich birgt, beschränken wir den ersten Zugang auf eine kleine Zahl von Partnern“, hieß es damals. Die Industrie geht also einheitlich zu eingeschränkten Zugängen über – Z.ai holt das als Nachzügler nach.

Die Verzögerung: Erste Gewichts-Kontrolle bei Z.ai

Die Gewichte für GLM-5.3 sollen um den 28. August nach Sicherheitsbewertung und Härtung veröffentlicht werden. Das ist die erste derartige Verzögerung in der Geschichte des Unternehmens. Bis dahin läuft der Zugang über den kostenpflichtigen GLM Coding Plan, ZCode und kontrollierte Umgebungen für ausgewählte Sicherheitspartner. Die sensibelsten Funktionen bleiben einer vertrauenswürdigen Zugriffsebene vorbehalten.

Z.ai räumt dabei offen ein, dass es nach der öffentlichen Freigabe keine Kontrolle mehr über Modifikationen oder Nutzung des Modells haben wird. Diese Einsicht ist ehrlich, aber auch folgenreich. Sobald die Gewichte öffentlich sind, kann jeder das Modell feinjustieren, Sicherheitsmaßnahmen entfernen und für eigene Zwecke umbauen. Die Frage ist, ob eine zweiwöchige Verzögerung irgendetwas an diesem Risiko ändert – vermutlich nicht.

Die Marktreaktion fiel jedenfalls negativ aus. Am 14. August, dem Tag der Veröffentlichung, fielen die Z.ai-Aktien. Der Marktwert sank von einem Höchststand von 128 Milliarden Dollar auf rund 75 Milliarden Dollar. Robert Lea, ein Intelligenz-Analyst, kommentierte gegenüber Bloomberg: „Dieses Unternehmen steht auf einem völlig unhaltbaren kommerziellen Fundament. Steigende agentische KI wird Z.ai’s Inferenzkosten und Verluste weiter erhöhen.“ Die Verzögerung der Gewichte dürfte diese Bedenken kaum zerstreuen.

Verifikationsproblem: Die eigene Harness als blinde Flecken

Ein zentrales Problem bleibt: alle Cyber-Werte stammen aus Z.ai’s eigener Testumgebung. Das Unternehmen führte die Tests mit maximalem Reasoning-Aufwand durch, erlaubte einen einzigen Versuch pro Aufgabe und setzte kein Zeitlimit. Bei ExploitGym wurden die Zeitbudgets mit Modell-Durchsatzraten neu skaliert statt mit gemessener Wanduhrzeit. Diese methodischen Entscheidungen sind legitim, aber sie erschweren den Vergleich mit anderen Modellen.

Unabhängige Überprüfungen stehen aus. Die einzige externe Bewertung deckt GLM-5.2 ab, nicht die neue Version. Das UK AI Security Institute stufte GLM-5.2 im Juli als das stärkste Open-Weight-Modell ein, das es für Cybersicherheit getestet hatte, vergleichbar mit geschlossenen Modellen aus einem Zeitraum von vier bis sieben Monaten zuvor. Dieser Abstand hatte sich im Laufe von 2025 bereits auf sechs bis zehn Monate vergrößert.

Die Zahlen von Z.ai sind also eine Selbstauskunft mit interessanten Indizien, aber ohne unabhängige Bestätigung. Dennoch gibt es Praxiserfahrungen: Hugging Face nutzte GLM-5.2 zur Untersuchung eines Server-Einbruchs, nachdem die Sicherheitsvorkehrungen amerikanischer Frontier-Modelle nicht weiterhalfen.

Zwischen Sicherheit und Geschäft: Was die Verzögerung bedeutet

Die Verzögerung der Gewichte hat eine doppelte Dimension. Einerseits zeigt sie Verantwortungsbewusstsein: Z.ai erkennt die Risiken und handelt entsprechend. Andererseits ist sie auch ein Eingeständnis der eigenen Grenzen. Das Unternehmen hat die Entwicklung der Cyber-Fähigkeiten unterschätzt, und die Infrastruktur für sichere Veröffentlichungen ist offenbar nicht vollständig vorbereitet.

Für dich als Entwickler oder Sicherheitsforscher bedeutet das: Du bekommst Zugang zu GLM-5.3 vorerst nur über die kontrollierten Kanäle. Der GLM Coding Plan kostet Geld, ZCode ist ebenfalls kostenpflichtig, und der Zugang für Sicherheitspartner ist begrenzt. Wenn du auf OpenWeights angewiesen bist, musst du bis zum 28. August warten – und hoffen, dass dieser Termin gehalten wird.

Die Cybersicherheit von KI-Modellen entwickelt sich schneller, als die Industrie verantwortungsvoll verarbeiten kann. Offene Modelle liefen früher den geschlossenen hinterher. Jetzt entsteht eine neue Klasse von Modellen, deren Fähigkeiten die Labore selbst überraschen. Das führt zu Zugangskontrollen, die noch vor einem Jahr undenkbar waren. Für die Open-Source-Community ist das ein Rückschlag – für die Sicherheitslage vielleicht ein notwendiger.

Quelle: implicator.ai