Kategorie: Erklärer

Ein Assistent führt jeden Morgen denselben Ablauf durch: E-Mails checken, Aufgaben priorisieren, Kalender aktualisieren, Zusammenfassung schreiben. Anfangs erklärst du ihm jeden Schritt in ausführlichen Sätzen. Nach einigen Wochen wiederholt er sich immer gleich. Wäre es nicht sinnvoll, die immergleichen Schritte als festes Programm zu hinterlegen und nur noch Ausnahmen mit dem Assistenten zu besprechen? Ein erfahrener Entwickler hat das umgesetzt und erreichte: 94 Prozent weniger Tokenverbrauch, 87 Prozent niedrigere Latenz bei gleichbleibender Qualität.

Ausgangspunkt war ein täglicher Workflow: Ein KI-Agent – der Coding-Assistent Codex – durchstöberte das Archiv eigener Blogartikel, wählte einen Beitrag aus, prüfte, ob er kürzlich erwähnt wurde, und verfasste einen LinkedIn-Post-Entwurf. Der Entwurf diente als Inspiration, wurde nie automatisch veröffentlicht. Die ursprüngliche Version war vollständig in natürlicher Sprache als Agent Skill formuliert. Der Skill beschrieb Quellen, Prüfungen, Auswahlkriterien und Textstruktur. Bei jedem Durchlauf interpretierte der Agent diese Anweisungen, erstellte einen Plan, rief Werkzeuge auf und verfolgte den Zustand. Das war gut für die erste Version – natürliche Sprache macht den Workflow verständlich und änderbar.

Sobald ein Skill oft ausgeführt wird und immer dieselben Pfade nimmt, wird sein Verhalten festgelegt. Der Workflow kristallisiert sich heraus: Der Skill sucht an denselben Stellen, erstellt dasselbe Inventar, wendet identische Filter an und speichert Zwischenzustände gleich. Das muss nicht jeden Morgen neu durchdacht werden. Vieles braucht kein großes Sprachmodell (LLM). Nur zwei Schritte benötigen ein LLM: die Auswahl eines geeigneten Kandidaten und das Verfassen des LinkedIn-Entwurfs. Alles andere kann deterministischer Code erledigen.

Der Autor kompilierte den Skill in eine spezialisierte Softwareumgebung – eine Harness. Der neue Skill besteht nur noch aus einem dünnen Bootloader, der ein Python-Programm startet. Dieses Programm ruft Quellen ab, baut das Inventar auf, prüft aktuelle Beiträge, wendet Filter an und verwaltet den Workflow. Ein LLM wird nur für Auswahl und Texterzeugung genutzt. Ergebnis: 94 Prozent weniger Tokens, 87 Prozent niedrigere Latenz bei identischer Ausgabequalität. Die Einsparungen kommen nicht von einem kleineren Modell – die LLM-Schritte nutzen dasselbe Modell. Die Einsparung entsteht, weil alle Modellaufrufe entfernt wurden, die regulärer Code direkt und effizienter ausführen kann.

Was bedeutet „Kompilieren“ hier genau?

Der Entwickler hatte historische Spuren (Traces) früherer Ausführungen des Skills – der Workflow lief täglich als Automatisierung in Codex. Diese Traces zeigten Planung, Werkzeugaufrufe, Verzweigungen und benötigten Zustand. Er gab diese Traces, den ursprünglichen Skill und seine Gedanken zu spezialisierten Harnesses einem leistungsstarken Modell. Aufgabe: Identifiziere, welche Schritte wirklich ein LLM erfordern und welche stabil genug für Code sind, und baue die spezialisierte Harness. Der natürlichsprachliche Skill diente als hochrangige Spezifikation, die Traces lieferten operative Details – das Ergebnis vorheriger Modellreasonings. Die Compiler-Analogie passt: Beginne mit einer flexiblen, hochrangigen Darstellung der Absicht. Nachdem der Workflow oft genug ausgeführt wurde, senkt man die stabilen Teile in eine effizientere Repräsentation ab. Das Modell wird weiterhin dort eingesetzt, wo es nötig ist.

Das Ziel: Workflow-Teile unterscheiden, die deterministischer Code sein können, von denen, die Sprachverständnis, Textgenerierung oder Reasoning benötigen. Es geht nicht darum, Sprachverständnis in starre Regeln zu zwängen. Die Kandidatenauswahl hängt davon ab, was die Quelle sagt und ob der Beitrag interessant wäre. Das Verfassen profitiert von Sprachgenerierung. Diese bleiben Modellaufrufe, weil sie modellgeprägte Probleme sind. Die Wertschöpfung liegt darin, das LLM nur auf kleine, wirklich intelligente Aufgaben zu konzentrieren.

Der Workflow: Erst flüssig, dann optimieren

Die spezialisierte Harness von Anfang an zu schreiben, wäre verfrüht gewesen. Der Autor kannte den genauen Workflow nicht, wusste nicht, welche Regeln wichtig sein würden oder wo Urteilsvermögen nötig wäre. Die natürlichsprachliche Version des Skills ermöglichte es, diese Dinge durch wiederholte Ausführung zu entdecken. Doch den gesamten Workflow für immer in natürlicher Sprache zu belassen, hieße, das Modell bei jedem Durchlauf denselben Plan neu finden zu lassen. Das nützliche Muster: 1. Drücke den Workflow als natürlichsprachlichen Skill aus. 2. Führe ihn oft genug aus, um Traces zu sammeln und das Verhalten zu verfeinern. 3. Finde die Teile, die stabil und deterministisch geworden sind. 4. Kompiliere diese Teile in Code. 5. Behalte LLM-Aufrufe an den wenigen Stellen, an denen semantisches Urteilsvermögen erforderlich ist.

Es gibt einmalige Kosten für diesen Kompilierungsdurchlauf. Der Autor nutzte ein leistungsstarkes Modell und viel Kontext, um Traces zu inspizieren und die neue Harness zu erstellen. Diese Kosten werden nur einmal bezahlt. Der kompilierte Workflow kann hunderte Male laufen und spart jedes Mal Tokens und Zeit. Klassische Optimierungsökonomie: einmal ausgeben, über wiederholte Nutzung amortisieren. Der Entwickler betont, dass er lokale Agenten bevorzugt, weil diese genau diese Art von Historie ansammeln: Skills, Traces, Zustände und Artefakte früherer Läufe. Diese Geschichte liefert das Rohmaterial, um die Harness selbst zu verbessern.

Die langfristige Ökonomie der Agenten

Die langfristigen Kosten von Agenten-Workflows hängen von dieser Optimierung ab. Wenn jeder wiederkehrende Workflow für immer ein Frontline-Modell als Planer, Zustandsmaschine und Klebecode verwendet, sinken Kosten und Latenz nie wirklich. Eine spezialisierte Harness erlaubt dem Modell, sich auf den kleinen Bruchteil des Workflows zu konzentrieren, der von Intelligenz profitiert. Der Autor macht einen wichtigen Punkt: Die großen Modellanbieter haben wenig Anreiz, diese Technik aktiv zu promoten. Ihr Geschäft ist der Verkauf von Tokens – möglichst viele von ihren teuersten Modellen. Es gibt einen alten Spruch: Es ist schwer, jemanden von etwas zu überzeugen, wenn sein Gehalt davon abhängt, es nicht zu verstehen. Eine Technik, die die Ausgabequalität erhält und den Tokenverbrauch um 94 Prozent senkt, läuft den wirtschaftlichen Interessen eines Unternehmens zuwider, dessen Einnahmen mit dem Tokenverbrauch steigen.

Der Autor räumt ein, dass es innerhalb dieser Firmen Leute gibt, denen Effizienz wichtig ist – bessere Inferenz, Caching und günstigere Modelle machen deren Produkte nützlicher. Aber es gibt einen Unterschied zwischen günstigeren Tokens und der Hilfe für Kunden, zu entdecken, dass die meisten ihrer Workflows überhaupt keine Tokens benötigen. Derzeit sieht er wenig Anreiz für die großen Anbieter, diese zweite Idee stark zu verfolgen. Also liegt es an Nutzern und unabhängigen Entwicklern, diese Optimierungsmöglichkeiten selbst zu finden. Das ist auch die Chance. Es gibt einen großen offenen Raum für Gründer, die spezialisierte Harnesses, Compiler und Werkzeuge bauen, die wiederkehrende Agenten-Workflows untersuchen und die deterministischen Teile in Code verschieben. Das Wertversprechen ist konkret: Behalte die Ausgabequalität bei, senke Kosten und Latenz.

Die Modellanbieter werden weiterhin leistungsstärkere Motoren bauen. Jemand muss trotzdem sicherstellen, dass wir diese Motoren nicht aufdrehen, um einfache, deterministische Arbeit zu erledigen. Der Ansatz des Autors ist einleuchtend: Nutze natürliche Sprache, um den Workflow zu entdecken. Nutze Traces, um ihn zu verstehen. Dann kompiliere, was sich verfestigt hat. Dieses Prinzip lässt sich auf unzählige alltägliche Automatisierungen anwenden – E-Mails verfassen, Daten auswerten, Projekte verwalten. Es erfordert keine neuen, teuren Modelle, sondern nur den Willen, den eigenen Workflow zu analysieren und die richtigen Grenzen zu ziehen. Wer tiefer einsteigen möchte: Der ursprüngliche Prompt für den „Token Shrinker“ steht zur Verfügung, um ihn im eigenen Agenten auszuprobieren.

Wir können unsere KI-Assistenten effizienter machen, indem wir sie nicht jede einfache Routine neu durchdenken lassen. Stattdessen geben wir ihnen ein festes Skelett für immer gleiche Abläufe und rufen sie nur, wenn echtes Denken gefragt ist. Das spart Geld, Zeit und Rechenaufwand.

Quelle: vivekhaldar.com

Eine Anwendung, die auf KI-Sprachmodelle angewiesen ist, benötigt regelmäßig API-Aufrufe – für Textgenerierung, Bildkreation oder Workflows mit LangChain. Die offizielle OpenAI-API verursacht schnell hohe Kosten, enge Ratenlimits und aufwändige Einrichtung von API-Schlüsseln. Da entstand die Idee: die vorhandene ChatGPT-Oberfläche nutzen, die im Browser läuft und für Abonnenten bereits bezahlt ist. Allerdings gibt es keine offizielle Schnittstelle zur programmatischen Steuerung. Ein Entwickler experimentierte in einem Wochenendprojekt. Das Ergebnis ist CatGPT-Gateway, ein System, das die ChatGPT-UI in eine OpenAI-kompatible REST-API verwandelt. Technisch interessant, aber ethisch und rechtlich fragwürdig. Dieser Artikel beschreibt die Funktionsweise, die Hürden und warum der Nachbau nicht empfohlen wird.

Gautam Vhavle entwickelte das Projekt aus technischer Neugier, nicht aus finanziellen Gründen. Er arbeitete an einer Anwendung mit wiederholten API-Aufrufen und fragte sich, ob er die Chat-Oberfläche automatisieren könnte. Sein Ziel war ein Strukturexperiment – die Grenze zwischen Benutzeroberfläche und programmatischem Endpunkt auszuloten. Was an einem Freitagabend begann, dauerte mehrere Wochen und erforderte Auseinandersetzung mit Browserautomation, Anti-Bot-Systemen und Chromes Verhalten in Docker-Containern.

Die technische Grundlage: Ein Browser, der für eine API gehalten wird

Das Konzept ist einfach, die Umsetzung komplex. Der Entwickler startet einen echten Chrome-Browser – mit sichtbarem Fenster – und lässt ihn auf die ChatGPT-Webseite zugreifen. Ein FastAPI-Server empfängt Anfragen im Standard-OpenAI-Format, zum Beispiel POST /v1/chat/completions. Diese Anfrage wird an einen ChatGPT-Client weitergereicht. Der Client simuliert einen menschlichen Benutzer: Er tippt die Nachricht in das Eingabefeld von ChatGPT, wartet auf die Antwort und extrahiert den Text durch Klicken auf den Kopieren-Button. Der Benutzer erhält eine JSON-Antwort, die der OpenAI-Spezifikation entspricht. Aus Sicht der Anwendung – ob LangChain, CrewAI oder ein einfaches curl-Skript – scheint es, als ob sie direkt mit OpenAIs Servern spricht. Tatsächlich spricht sie mit einem Browser, der von einer Katze gesteuert wird, wie der Autor augenzwinkernd anmerkt.

Der Ablauf hat jedoch einige Hürden. OpenAI verwendet Cloudflare zur Bot-Erkennung. Cloudflare prüft nicht nur navigator.webdriver, sondern auch Canvas-Fingerprinting, WebGL-Signaturen, Plugin-Listen und das Verhalten von Mausbewegungen und Tippgeschwindigkeit. Ein automatisiertes Skript, das Nachrichten sofort einfügt, fällt sofort auf. Der Entwickler setzte Stealth-Techniken ein, um den Browser menschlich erscheinen zu lassen. Er verwendet eine spezielle Variante von Playwright namens Patchright, kombiniert mit playwright-stealth, das viele Fingerprinting-Merkmale überschreibt. Die Texteingabe erfolgt nicht zeichenweise, sondern per Zwischenablage mit zufälligen Verzögerungen. Mausbewegungen werden mit Zwischenschritten simuliert, und die Fenstergröße wird bei jedem Start leicht variiert. Ein Bug trat im Docker-Container auf: Der Aufruf von add_init_script() zerstörte die DNS-Auflösung von Chrome vollständig. Die Lösung war, das JavaScript zur Laufzeit über page.evaluate() zu injizieren und bei jedem Seitenwechsel erneut auszuführen. Ein typischer Fall von stundenlanger Fehlersuche, behoben mit einer einzigen Zeile Code.

Der VNC-Trick: Ein Browser, der gleichzeitig sichtbar und unsichtbar ist

Ein cleverer Teil des Projekts ist der Browserbetrieb. Um Cloudflare zu täuschen, muss ein sichtbarer Browser laufen. Auf einem Server gibt es keinen Monitor. Der Entwickler richtete Xvfb (X Virtual Framebuffer) ein, der eine künstliche Anzeige erzeugt. Diese wird von x11vnc als VNC-Server bereitgestellt, und über noVNC kann man per Webbrowser auf den virtuellen Bildschirm zugreifen. Das Ergebnis: Für Cloudflare sieht es aus wie ein echter Chrome-Browser mit GPU-beschleunigter Anzeige. Für den Server ist es ein kopfloser Prozess ohne physische Anzeige. Als Administrator kannst du über localhost:6080 live zusehen und manuell CAPTCHAs lösen. Der Autor nennt es Schrödingers Browser – gleichzeitig sichtbar und unsichtbar. Diese Architektur erfordert mehrere Prozesse, die von supervisord verwaltet werden: Xvfb, x11vnc, noVNC und den FastAPI-Server. Ein einfaches docker compose up startet die gesamte Umgebung.

OpenAI-kompatible Endpunkte: Mehr als nur Text

Das Projekt unterstützt nicht nur Chat. Der Entwickler gestaltete die API als vollwertigen Ersatz für die OpenAI-API. Endpunkte wie /v1/chat/completions und /v1/images/generations verwenden Pydantic-Schemata, die der OpenAI-Spezifikation entsprechen. Antworten enthalten Felder wie id, choices und usage. Tool Calling (Funktionsaufrufe) wird ebenfalls unterstützt. Da der Browser keine native Funktion zum Aufrufen von Tools hat, nutzt CatGPT einen Prompt-basierten Trick: Es fügt der System-Nachricht die Definitionen der verfügbaren Tools hinzu, mit wenigen Beispielen (Few-Shot). ChatGPT wird aufgefordert, strukturiertes JSON auszugeben. Dieses JSON wird mittels regulärer Ausdrücke extrahiert und in eine tool_calls-Antwort umgewandelt. Frameworks wie LangChain oder AutoGen können nahtlos mit dem Gateway zusammenarbeiten, indem sie einfach die base_url umstellen.

DALL-E-Integration ist ebenfalls möglich. Der Auslöser für das gesamte Projekt war der Bedarf an wiederholter Bildgenerierung. Der Entwickler stellte fest, dass ChatGPT selbst DALL-E-Bilder im Chat erzeugen kann. CatGPT sendet eine entsprechende Textnachricht an ChatGPT, wartet, bis im DOM ein Bild-Element mit der Kennung img[alt='Generated image'] erscheint, und lädt das Bild über die Browsers fetch()-API herunter. Da der Browser bereits authentifiziert ist, werden die Cookies automatisch mitgesendet. Das Bild wird als Base64 oder URL zurückgegeben, wiederum im OpenAI-kompatiblen Format. Der Benutzer erhält sogar den revised_prompt – den intern von DALL-E verwendeten Prompt. Das funktioniert selbst mit dem offiziellen OpenAI Python SDK, wenn der Endpunkt entsprechend konfiguriert ist.

Warum der Nachbau problematisch ist

Der Entwickler betont mehrfach, dass das Projekt nur zu Bildungszwecken und für Cybersicherheitsforschung dient. Es ist keine Aufforderung, die Nutzungsbedingungen von OpenAI zu umgehen. Die Nutzung in Produktion ist aus mehreren Gründen problematisch. Erstens verstößt es gegen die Nutzungsbedingungen von OpenAI, die automatisierte Zugriffe auf die Chat-Oberfläche verbieten. Das kann zur Sperrung des Kontos führen. Zweitens ist die Lösung extrem fragil: Jede Änderung der ChatGPT-Oberfläche – ein neuer CSS-Klasse, ein anderer Button-Text – kann die gesamte Automation zerstören. Drittens ist die Latenz deutlich höher als bei der echten API, da jeder Aufruf einen Browser-Start und die Interaktion mit einer Webseite erfordert. Viertens gibt es Sicherheitsrisiken: Der Browser läuft mit den Sitzungscookies – ein Fehler im Skript könnte diese offenlegen. Der Autor selbst sagt: „Ich bin kein Hacker, das ist kein Bug. Ich bin nur ein neugieriger Entwickler, der die Grenzen der Browserautomation verstehen wollte.“ Diese Haltung ist vorbildlich. Sie zeigt auch, wie verführerisch solche Workarounds sein können, besonders wenn die offizielle API teuer oder umständlich ist.

Was wir daraus lernen können

Das Projekt zeigt: Browserautomation ist weit fortgeschritten, und Plattformen wie OpenAI müssen ihre Schutzmechanismen ständig verbessern. Es unterstreicht den Bedarf an besseren, günstigeren API-Zugängen. Die Umgehung von Nutzungsbedingungen hat rechtliche und ethische Konsequenzen. Bevor du einen Workaround baust, prüfe, ob der offizielle Weg nicht doch bezahlbar oder mit Optimierung nutzbar ist. Die Preise sinken, die Limits steigen. Vielleicht werden solche Proxy-Lösungen bald überflüssig.

Quelle: dev.to

Du suchst einen bestimmten Artikel auf TechCrunch, landest aber auf einer 404-Seite. Nervig. Während du dich umsiehst, fallen dir die Schlagzeilen in der Sidebar auf: Mira Murati launcht ein offenes KI-Modell, ein mit Private Equity finanzierter Startup will KI-Dienste im großen Stil an Unternehmen verkaufen, Apple bringt seine KI nach China – mit Hilfe von Alibabas Qwen-Modell. Das ist ein Querschnitt durch das, was die KI-Welt im Jahr 2026 bewegt. Kein Hype, keine Utopie, sondern konkrete Arbeit. Lass uns die wichtigsten Nachrichten auseinandernehmen und verstehen, was sie bedeuten – für dich, für Unternehmen und für die Technologie selbst.

KI-Modelle sind heute überall: auf deinem Smartphone, in deiner Mailbox, in Produktionshallen. Die Art, wie sie entwickelt, trainiert und ausgerollt werden, verändert sich grundlegend. Zwei gegenläufige Trends prägen die Szene: der Drang zu immer größeren, allumfassenden Modellen und das wachsende Bedürfnis nach spezialisierten, kontrollierbaren Systemen. Die aktuellen Meldungen spiegeln diese Dynamik.

Von Allzweck-Köchen und Spezialisten: Warum Mira Murati auf offene, spezialisierte KI setzt

Stell dir eine Küche vor, in der ein einziger Koch alles zubereiten muss – von der Vorspeise bis zum Dessert, von der japanischen bis zur italienischen Küche. Das Ergebnis wird selten perfekt. Genau so funktionieren die großen Foundation Models: Sie können vieles, aber nichts richtig gut. Thinking Machines Lab, das neue Unternehmen von Mira Murati, setzt mit seinem offenen Modell „Inkling“ genau hier an. Statt einem Modell, das für alle Aufgaben optimiert ist, sollen Unternehmen und Entwickler spezialisierte Modelle bauen können, die auf bestimmte Domänen zugeschnitten sind. „Offen“ bedeutet, dass der Quellcode und die Gewichte des Modells öffentlich zugänglich sind – eine Ansage gegen die Blackbox-Politik großer Anbieter. Das ist kein Bastelprojekt, sondern ein Versuch, KI demokratischer und gleichzeitig leistungsfähiger im Detail zu machen. Ein Modell, das nur eine Sache kann, diese aber exzellent, ist oft wertvoller als ein Allrounder, der bei allem mittelmäßig bleibt. Ein Sushi-Meister serviert bessere Nigiri als ein Küchenchef, der auch noch die Pasta kochen muss. Genau diese Spezialisierung sehen wir jetzt in der KI-Landschaft.

Enterprise-KI aus dem Baukasten: Was steckt hinter Anthropic und Inside Ode?

Während Murati auf offene Spezialisierung setzt, geht ein anderer Player einen Schritt weiter: Inside Ode, ein mit Private Equity finanzierter Startup, der mit Anthropic zusammenarbeitet, wettet darauf, dass Unternehmen KI nicht selbst entwickeln wollen, sondern lieber fertig konfektionierte Dienstleistungen kaufen. Stell dir vor, du betreibst eine Versicherung, eine Bank oder eine Logistikfirma. Du hast keine KI-Abteilung, aber Daten und Prozesse, die optimiert werden können. Inside Ode baut für dich eine maßgeschneiderte Lösung auf Basis von Anthropics Claude-Modellen – und betreibt sie. Das ist der Unterschied zwischen einem Kochbuch und einem Privatkoch. Das Modell heißt „KI als Service“, und es ist ein heißer Markt. Unternehmen sparen sich die teure Infrastruktur und das Spezialwissen, zahlen eine monatliche Gebühr und bekommen eine Lösung, die genau auf ihre Bedürfnisse zugeschnitten ist. Die Partnerschaft mit Anthropic ist kein Zufall: Anthropic legt Wert auf Sicherheit und Ausrichtbarkeit von KI – genau das, was Unternehmen brauchen, wenn sensible Kundendaten im Spiel sind. Diese Nachricht zeigt: KI ist nicht nur für Tech-Giganten, sondern zieht langsam in den Mittelstand ein – nicht als Spielerei, sondern als ernsthaftes Werkzeug.

Apple Intelligence in China: Warum regionale Anpassung mehr als ein Übersetzungsupdate ist

Ein drittes Puzzle-Stück: Apple Intelligence startet in China – mit Alibabas Qwen-Modell im Hintergrund. Warum nicht das eigene Modell oder ChatGPT? KI ist nicht nur Technik, sondern auch Gesetz und Kultur. China verlangt, dass KI-Modelle den lokalen Vorschriften entsprechen. Daten müssen im Land bleiben, Algorithmen müssen zensurkonform sein, Modelle müssen chinesische Sprach- und Kulturkontexte verstehen. Apple hatte zwei Optionen: ein eigenes Modell von Grund auf trainieren – teuer und zeitaufwendig – oder auf einen etablierten Partner setzen. Alibabas Qwen-Modell ist in China erprobt, kennt die regulatorischen Anforderungen und kann in iPhones integriert werden. Kein Kompromiss, sondern eine strategische Entscheidung. Für dich als Nutzer bedeutet das: Dein iPhone wird in Zukunft wahrscheinlich landesspezifisch unterschiedliche KI-Funktionen haben. In China andere als in Europa, in den USA andere als in Indien. Das ist der Preis für allgegenwärtige KI – sie muss sich lokalen Gegebenheiten anpassen, sonst wird sie blockiert. Und das ist gut so: Eine KI, die überall gleich funktioniert, könnte in manchen Ländern gegen Gesetze verstoßen oder kulturell unpassend sein.

Sicherheit durch KI und KI-Sicherheit: Microsofts Patches und Sunos Datenklau

Zwei weitere Nachrichten runden das Bild ab: Microsoft hat eine Rekordzahl von Sicherheitslücken geschlossen und gibt an, dass KI dabei eine zentrale Rolle gespielt hat. Und: Der Musik-KI-Generator Suno hat offenbar YouTube-Videos für sein Training genutzt – ohne Erlaubnis. Zwei Seiten derselben Medaille. Microsoft zeigt, wie KI zur Verteidigung eingesetzt wird: Algorithmen durchforsten Code nach Schwachstellen, simulieren Angriffe und schlagen Patches vor. Das passiert heute, nicht erst morgen. Auf der anderen Seite steht Suno: Um ein KI-Modell für Musik zu trainieren, braucht man riesige Mengen an Audiodaten. YouTube ist eine naheliegende Quelle, aber meist nicht legal nutzbar. Die Meldung, dass Suno Daten ohne Erlaubnis gescrapt hat, wirft ein Schlaglicht auf die dunkle Seite des KI-Trainings. Viele große Modelle wurden mit urheberrechtlich geschützten Daten trainiert – und die Anbieter hoffen, dass sie nicht erwischt werden oder sich die Rechtslage ändert. Für dich als Anwender bedeutet das: Nicht jede KI, die du nutzt, wurde mit sauberen Methoden trainiert. Achte darauf, woher die Anbieter ihre Daten beziehen, vor allem wenn du die KI geschäftlich einsetzt. Die rechtlichen Grauzonen sind noch da.

Was bedeutet das alles konkret?

Wenn wir die vier Nachrichten zusammenlegen, sehen wir ein klares Bild: KI wird spezialisierter, regionaler, dienstleistungsorientierter und gleichzeitig sicherheitsrelevanter. Kein Hype, sondern eine Evolution. Für Unternehmen bedeutet das: Sie müssen nicht mehr selbst Modelle trainieren, sondern können auf offene Modelle wie Inkling setzen oder auf Dienste wie Inside Ode zurückgreifen. Für dich als Privatnutzer: Deine Geräte werden mehr KI-Funktionen haben, aber diese Funktionen variieren je nach Land und Anbieter. Für die Branche: Die Frage nach sauberen Trainingsdaten und ethischer Entwicklung bleibt relevant. Wir stehen nicht am Ende einer Entwicklung, sondern in einer Phase der Konsolidierung und Ausdifferenzierung. KI ist kein Allheilmittel, sondern ein Werkzeug – wie ein Hammer oder ein Kochmesser. Du musst das richtige Werkzeug für die richtige Aufgabe wählen und sicherstellen, dass es nicht gestohlen oder illegal hergestellt wurde. Nüchtern, aber wahr.

Quelle: techcrunch.com

Du arbeitest seit Jahren mit KI-Assistenten. Erst halfen sie beim Vervollständigen von Codezeilen, dann beim Generieren ganzer Funktionen. Heute, im Jahr 2026, gibst du ein grobes Ziel ein. Ein Agent durchforstet deine Codebasis, ändert mehrere Dateien, führt Tests aus und präsentiert das Ergebnis. Das war vor drei Jahren Science-Fiction, heute ist es Realität. Die Frage: Wie baut man zuverlässige Systeme um diese mächtigen, aber unberechenbaren Modelle? Auf der AI Engineer World’s Fair 2026 zeigte sich: Die Antwort liegt nicht in noch schlaueren Modellen, sondern in der Kunst des Systembaus. KI-Engineering ist erwachsen geworden. Hier sind fünf Trends.

Der Begriff „KI-Ingenieur“ ist drei Jahre alt. Im Juni 2023 prägte swyx den Ausdruck für Entwickler, die nach dem Urknall der großen Sprachmodelle entstanden waren. Anfangs sprach man von „Prompt Engineering“, doch die Disziplin entwickelte sich rasant. Die Weltausstellung 2026 zeigte: Statt über einzelne Modelle zu diskutieren, ging es um Systeme, die Modelle in Produktion bringen. Es geht nicht mehr darum, ob KI Ingenieure ersetzt, sondern wie sie sie verstärken. Das erfordert ein neues Verständnis von Architektur, Kontrolle und Zusammenarbeit.

1. Vom Agenten zum Geschirr: Der Aufstieg des Harness Engineerings

Eine Entwicklung lässt sich an zwei Aufsätzen von Lilian Weng ablesen. Ihr Artikel von 2023 über „LLM-betriebene autonome Agenten“ beschrieb Planung, Gedächtnis und Werkzeuggebrauch. Projekte wie AutoGPT und BabyAGI waren Machbarkeitsstudien. Ihr neuer Aufsatz von 2026, „Harness Engineering for Self-Improvement“, verfolgt einen anderen Ansatz. Das System um das Modell herum sei genauso wichtig: das „Geschirr“, das Arbeitsabläufe, Kontext, Berechtigungen, Evaluation, dauerhaften Zustand und kontinuierliche Verbesserung verwaltet. KI-Engineering hat sich vom Prompten zum Entwickeln zuverlässiger Systeme verlagert.

Diese Verschiebung war auf der Konferenz allgegenwärtig. 2023 drehte sich jede zweite Diskussion um AutoGPT, 2026 war das kaum mehr Thema. Stattdessen ging es um Claude Code, Codex, Gemini CLI, Cursor und Warp – und die Infrastruktur für zuverlässige Codierungsagenten in der Produktion. Der Hype um vollständige Autonomie ist einer nüchternen Erkenntnis gewichen: Komplette Autonomie ist nicht nur unzuverlässig, oft auch nicht wünschenswert. Die Botschaft: Agenten sollen den KI-Ingenieur ergänzen, nicht ersetzen.

2. Codierungsagenten werden zum Standard – aber mit menschlicher Aufsicht

Der größte praktische Wandel seit dem ersten Gipfel ist die tägliche Interaktion mit KI. 2023 bedeutete KI-gestützte Programmierung meist Codevervollständigung. Heute gibt es Werkzeuge wie Claude Code, Codex, Gemini CLI, Cursor und Warp. Diese Codierungsagenten verstehen ein übergeordnetes Ziel, erkunden eine Codebasis, ändern mehrere Dateien, führen Tests aus und iterieren selbstständig. Das ist Alltag vieler Teams.

Mit größerer Autonomie wächst die Notwendigkeit der Kontrolle. In seiner Keynote betonte Thariq Shihipar von Anthropic: Modelle werden gezüchtet, nicht entworfen. Claude werde auf ungleichmäßige Weise klüger. Das bringt das Dilemma auf den Punkt: Wie baut man Systeme, um die Ausgaben unberechenbarer Modelle zu evaluieren? Die Antwort liegt in der Architektur der Schleifen.

3. Loop-Engineering: Die Kunst der Kontrollschleifen

Das Schlagwort der Konferenz war „Loops“. Innere Schleifen, äußere Schleifen, Feedback-Schleifen. Die Frage: Wie viel Kontrolle sollen Agenten haben? Viele Ingenieure setzen Agenten in eine innere Schleife, während der Mensch in der äußeren Schleife bleibt. Roland Gavrilescu von Introspection erklärte „Autoresearch“: Eine innere Schleife interagiert mit Nutzern, eine äußere Schleife studiert und wartet das System. Der Mensch bleibt verantwortlich für Richtung und Entscheidungen.

„Loop Engineering“ fiel mehrfach – die Aufgabe des KI-Ingenieurs, diese Schleifensysteme zu bauen. Peter Steinberger von OpenClaw betonte: Der Agent läuft die innere Ausführungsschleife, er selbst gibt die Richtung vor. In einer Debatte wurde diskutiert, ob vollständig autonome Agenten Schleifen in der Realität managen können. Geoffrey Huntley sagte: „Wir sind heute wie Lokomotivführer. Es ist unsere Aufgabe, die Lokomotive auf den Schienen zu halten.“ Der Ingenieur bleibt der Treiber.

4. Forward Deployed Engineers und die Software-Factory

Eine neue Rolle zeigt, wie diese Zusammenarbeit in Unternehmen Einzug hält: der „Forward Deployed Engineer“ (FDE). Diese Ingenieure arbeiten direkt mit Organisationen zusammen. Natalie Meurer von Sierra erklärte: Die Implementierung von KI erfordert viel Orchestrierung. Unternehmen wollen wissen, wie sie ihr agentisches Ökosystem warten können. Pauline Brunet von Cursor sprach über die Arbeit ihrer FDEs. Ziel: nach Ende des Engagements einen klaren ROI hinterlassen.

Ein weiterer Begriff war „Software Factory“. Bei Cursor bedeutet das langlebige Agenten, die Menschen durch den Entwicklungsprozess begleiten. Organisationen entscheiden, welche Teile automatisiert werden und wo Menschen eingreifen. Zach Lloyd von Warp erklärte: Mit „Oz“ kann man Repositories auswählen, Lebenszyklen automatisieren und menschliche Prüfpunkte festlegen. Nicht jede Änderung muss geprüft werden, aber risikoreiche schon.

5. Context Engineering: Das unsichtbare Rückgrat der KI

Ein oft übersehener Trend ist das „Context Engineering“. Prukalpa Sankar von Atlan zeigte, wie Kontext aus Geschäftssystemen in ein gemeinsames Unternehmenshirn fließt und an Agenten weitergegeben wird. Es geht darum, die richtigen Daten zur richtigen Zeit an das Modell zu liefern. Unternehmen kämpfen mit der Integration ihrer Daten. Ohne gutes Kontext-Management bleiben selbst die besten Modelle stumpf.

Pauline Brunet warnte: Die Unternehmensadoption von KI ist noch auf frühe Anwender konzentriert. Die Herausforderung für FDEs ist, die richtigen Verfechter zu finden. Der kulturelle Wandel braucht Zeit. Eine Erkenntnis aus der World’s Fair 2026: KI-Engineering ist keine Disziplin für isolierte Tüftler mehr. Es ist eine Systemfrage, die verschiedene Experten an einen Tisch bringt.

Wer in der Softwareentwicklung arbeitet, kommt an diesen Trends nicht vorbei. Der Weg vom Prompt Engineering zum Loop Engineering zeigt: KI muss in robuste Systeme eingebettet werden. Entwickler entwerfen Schleifen, bauen Harnesses und geben die Richtung vor. Die Werkzeuge sind da. KI-Engineering wird zur Kernkompetenz der Softwareentwicklung.

Quelle: latent.space

Stell dir vor, du hast ein Haus mit einem sehr gut gesicherten Haupteingang. Dafür gibt es Kameras, einen Pförtner und mehrere Schlösser. Die meisten von uns haben in den letzten Jahren viel Energie in diesen Haupteingang gesteckt: Hauptgeschäftssysteme wie Salesforce werden mit Multi-Faktor-Authentifizierung, Conditional Access und strengen Sitzungsregeln geschützt. Aber was ist mit den vielen anderen Türen und Fenstern, die du selbst für vertrauenswürdige Helfer geöffnet hast? Der Briefträger hat einen Schlüssel, der Gärtner hat einen Code, und der Putzdienst kommt durch den Hauseingang, aber dann direkt in alle Räume. Genau diesen blinden Fleck haben Angreifer der Gruppe ShinyHunters ein Jahr lang systematisch ausgenutzt, ohne jemals eine Tür aufzubrechen. Der Microsoft-Bericht vom Juli 2026 zeigt eindrücklich, wie die Angreifer in Salesforce-Umgebungen eindrangen, indem sie das Vertrauen missbrauchten, das Unternehmen bereits in ihre eigenen Integrationen und Apps gesetzt hatten. Und das Schlimmste: Herkömmliche Überwachung hat dieses Verhalten kaum registriert.

Der Microsoft-Bericht dokumentiert drei fundamentale Angriffspfade, die alle auf demselben Prinzip beruhen: OAuth-Verbindungen, die Salesforce mit externen Tools und Drittanbieter-Diensten verknüpfen. Statt eine technische Sicherheitslücke in Salesforce selbst zu suchen, haben die Angreifer die menschliche und organisatorische Komponente ins Visier genommen. Die Forscher bei Microsoft haben diese Kampagnen von Mitte 2025 bis Mitte 2026 verfolgt und dabei ein klares Muster erkannt: Der Zugang erfolgte stets über bereits bestehende Vertrauensbeziehungen. Das ist auch der Grund, warum herkömmliche Authentifizierungsprotokolle keine Warnungen auslösten. Wenn sich ein echter Benutzer anmeldet, der zuvor eine bösartige App autorisiert hat, oder wenn eine Integration ausgeführt wird, die das Unternehmen bereits als vertrauenswürdig eingestuft hat, sehen die Logs aus wie alltäglicher Traffic. Die eigentliche Frage ist, was eine solche App oder ein Konto tut, sobald es sich im Salesforce-System befindet. Genau diese Überwachung hat in den meisten Implementierungen bisher einfach gefehlt. Microsoft hat daher gemeinsam mit Salesforce neue Erkennungs- und Governance-Tools entwickelt, um genau diese Lücke zu schließen.

Der Telefonanruf – Wo die Kette begann

Der erste und öffentlichkeitswirksamste Pfad begann nicht mit einem physischen Einbruch, sondern mit einem ganz einfachen Telefonanruf. Mitte 2025 riefen die Angreifer Mitarbeiter an, gaben sich als IT-Support aus und führten sie durch den OAuth-Zustimmungsbildschirm von Salesforce. Die Mitarbeiter autorisierten dabei eine angebliche Version des legitimen Salesforce-Tools „Data Loader“, die in Wahrheit aber von den Angreifern kontrolliert wurde. Sobald der Benutzer zugestimmt hatte, konnte die bösartige App über die Salesforce-API auf die Daten des Benutzers zugreifen. Keine Schadsoftware, kein Phishing-Link – nur ein Telefonat und ein Klick. Diese Vorgehensweise, auch Vishing genannt, wurde aufgedeckt, als Google selbst im Juni 2025 betroffen war. Die Angreifer erbeuteten überwiegend öffentliche Geschäftskontaktdaten, bevor Google den Zugriff unterband. Mandiant und andere Forscher dokumentierten die Kampagne als UNC6040 (Erstzugriff) und UNC6240 (Erpressung). Die Namen der betroffenen Unternehmen lesen sich wie ein Who’s who der globalen Wirtschaft: Chanel, Pandora, Adidas, Qantas, Allianz Life und mehrere Marken des LVMH-Konzerns. Der wichtigste Ratschlag von Mandiant an Verteidiger war einfach, aber schwer umsetzbar: Diese Anrufe nutzen den natürlichen Hilfsinstinkt von Support-Mitarbeitern aus. Man soll auflegen und selbst über eine bekannte, vertrauenswürdige Nummer zurückrufen.

Der Angriffspunkt ist hier nicht die Technik, sondern die menschliche Psychologie. Die Angreifer wussten, dass viele Sicherheitsprozesse auf die Identität des Menschen abzielen, aber die OAuth-Zustimmung schützt nicht vor einem Menschen, der selbstsicher die richtigen Fragen stellt. Genau hier liegt das Problem: Ein IT-Mitarbeiter, der gebeten wird, eine App zu installieren, folgt oft einer Routine und prüft nicht, ob der Anrufer tatsächlich von der internen IT ist. Die Unternehmenspolitik ist vielleicht vorhanden, aber die Umsetzung scheitert an der Hektik des Alltags. Microsoft betont in seinem Bericht, dass die Unternehmen genau diese Schwachstelle erkennen müssen: OAuth ist mächtig, aber die Zustimmungsprozesse sind oft nicht an die Bedrohungslage angepasst. Deshalb müssen nicht nur technische, sondern auch prozessuale Sicherheitsmaßnahmen wie verpflichtende Second-Level-Autorisierungen für jede App-Installation etabliert werden.

Gestohlene Tokens von vertrauenswürdigen Drittanbietern

Der zweite Pfad verzichtet vollständig auf den direkten Kontakt mit dem Mitarbeiter. Statt einen Benutzer zu überzeugen, haben die Angreifer Drittanbieter kompromittiert, die bereits OAuth-Zugriff auf die Salesforce-Umgebungen ihrer Kunden besaßen. Sie stahlen die Verbindungsgeheimnisse oder Tokens dieser Integrationen und nutzten sie, um parallel in vielen verschiedenen Unternehmen Daten abzurufen. Da der Datenverkehr von einer bereits genehmigten Integration kommt, wird er von den normalen Überwachungssystemen nicht als Angriff erkannt. Microsoft beschreibt drei konkrete Vorfälle, die diese Methode belegen. Der bekannteste ist die Kompromittierung von Salesloft Drift im August 2025. Die Angreifer erbeuteten OAuth- und Refresh-Tokens der Drift AI Chat-Integration und nutzten sie, um auf die Salesforce-Umgebungen von über 700 Organisationen zuzugreifen. Darunter waren bekannte Namen wie Cloudflare, Zscaler, Palo Alto Networks, Proofpoint und PagerDuty. Die Angreifer blieben unerkannt, weil der gesamte Traffic wie legitime geschäftliche Nutzung aussah. Salesforce selbst stellte später fest, dass die Angreifer offenbar schon ab März 2025 Zugriff auf das GitHub-Konto von Salesloft hatten und von dort aus in die AWS-Umgebung von Drift gelangten.

Diese Angriffskette zeigt, wie gefährlich Software-Lieferketten für Unternehmen sein können. Ein kleines, kaum beachtetes Feature eines Drittanbieters kann zur Eintrittspforte für das gesamte Kundenökosystem werden. Der zweite Vorfall ereignete sich im November 2025 bei Gainsight. Auch hier nutzten die Angreifer gestohlene OAuth-Token, um auf Salesforce-Instanzen zuzugreifen. Salesforce zog daraufhin veröffentlichte Gainsight-Apps zurück, nachdem ungewöhnliche API-Aktivitäten aufgefallen waren. Google schätzte, dass über 200 Salesforce-Instanzen betroffen waren. Die Gruppe, die sich selbst als ShinyHunters ausgibt, behauptete damals, die Attacken auf Salesloft und Gainsight hätten gemeinsam fast 1.000 Organisationen erreicht – eine Zahl, die unabhängig nicht bestätigt werden kann. Der dritte Vorfall im Juni 2026 traf Klue, eine Competitive-Intelligence-Plattform. Hier war der Einstiegspunkt ein veraltetes Legacy-Credential, das aus einer Testintegration stammte, die nie ausgerollt worden war. Die Angreifer nutzten es aus, um einen Code-Update zu pushen, der die OAuth-Token der Kunden erntete. Damit griffen sie auf Salesforce- und Gong-Daten von Klue-Kunden zu, darunter Huntress und Recorded Future.

Die Benennung der Angreifer ist in diesem Bereich notorisch ungenau. Microsoft verfolgt den Klue-Akteur als Storm-3138, während andere Forscher die Gruppe Icarus nennen. Ein Telegram-Kanal, der vorgab, ShinyHunters zu sein, reklamierte die Tat ebenfalls für sich. Diese Überschneidungen sind kein Zufall: Die Identitäten werden opportunistisch beansprucht, um den Druck auf die Opfer zu erhöhen. Das macht die Bedrohungsanalyse komplizierter, aber das grundlegende Problem bleibt dasselbe: Unternehmen vertrauen blind darauf, dass ihre Drittanbieter sicher sind, aber die Sicherheitspraxis der Anbieter ist oft nicht auf dem gleichen Niveau. Microsoft weist daher darauf hin, dass nicht nur die eigenen Systeme, sondern auch die Integrationspartner einer regelmäßigen Überprüfung bedürfen. Die Tokens müssen regelmäßig rotiert werden, und der Zugriff sollte auf das absolut Notwendige beschränkt sein.

Gastzugang, der niemals geschlossen wurde

Der dritte und vielleicht überraschendste Pfand benötigt überhaupt keine Anmeldeinformationen. Microsoft beobachtete einen Anstieg verdächtiger Gast-Benutzeraktivitäten gegen Salesforce-Aura-Endpunkte, dem Framework hinter Experience Cloud-Seiten. Wenn die Berechtigungen für den Gastzugang falsch konfiguriert waren, konnten die Angreifer auf Aura-Funktionen zugreifen, ohne sich zu authentifizieren. Sie verwendeten speziell die GraphQL-Aura-Steuerung, um mit cursor-basierter Paginierung Datensätze über die standardmäßige Grenze von 2.000 Datensätzen hinaus abzurufen. So entwendeten sie weit mehr Daten, als die Gastrolle eigentlich hätte preisgeben dürfen. Microsofts Erkennungslogik zielt dabei auf das Tool AuraInspector ab, das für solche Sondierungen verwendet wird. Wieder einmal: kein technischer Exploit. Die Organisation hatte die Gastrolle so konfiguriert, dass sie mehr sehen konnte als nötig, und die Angreifer nutzten diese Fehlkonfiguration einfach aus.

Dieser Pfad zeigt, wie selbst grundlegende Sicherheitseinstellungen wie Gastzugänge vernachlässigt werden können. Oft werden Experience Cloud-Seiten für temporäre Zwecke eingerichtet und dann nicht mehr angepasst. Die Gastrolle erhält standardmäßig Lesezugriff auf viele Objekte, und wenn niemand die Berechtigungen im Detail prüft, bleibt die Tür offen. Microsoft empfiehlt hier eine konsequente Überprüfung der Gastzugänge und den Einsatz von Least-Privilege-Prinzipien. Zudem sollten Unternehmen den Zugang zu Aura-Endpunkten auf ein Minimum beschränken und sensible Daten hinter zusätzlichen Authentifizierungsschichten schützen. Der Bericht ist hier besonders deutlich: Es gibt keinen Angriff, wenn die Konfiguration von Anfang an sicher ist.

Was Microsoft und Salesforce gemeinsam dagegen tun

Die Herausforderung besteht darin, die Signale zu finden, die ein Angriff hinterlässt, ohne den normalen Geschäftsbetrieb zu stören. Das Signal liegt in dem, was nach dem Zugriff passiert: Welche verbundene App hat einen API-Aufruf getätigt? Welche OAuth-Bereiche besitzt sie? Wie viele Daten hat sie abgefragt, und ist das im Kontext des Mandanten normal? Microsoft und Salesforce haben daraufhin gemeinsam eine Reihe von Verbesserungen in Microsoft Defender for Cloud Apps implementiert. Für Kunden, die Salesforce Shield Event Monitoring nutzen, wird der aktualisierte Salesforce-Connector das Real-Time Event Monitoring-Framework für nahezu Echtzeit-Erkennung integrieren. Zusätzlich wird jetzt die verbundene App direkt einer Aktivität zugeordnet: Man sieht, welche App einen Aufruf getätigt hat, welche OAuth-Bereiche ihr gewährt wurden und um welche Sitzung oder API-Kontext es sich handelt. Das ist ein massiver Fortschritt gegenüber den bisherigen Logs, die nur die Aktion, aber nicht die Quelle zeigten.

Neben der Erkennung hat Microsoft die Posture- und Governance-Funktionen für verbundene OAuth-Apps erweitert. Das umfasst eine Ansicht überprivilegierter Apps mit erhöhten Berechtigungen, die Möglichkeit, ungenutzte Apps zu identifizieren, die seit 90 Tagen oder länger inaktiv sind, aber weiterhin aktive Berechtigungen haben, und eine Risikobewertung von 0 bis 100 für jede App. Diese Risikobewertung kann direkt in Warnungen und Richtlinien eingebunden werden. Ziel ist es, die überprivilegierten und vergessenen Integrationen zu finden, bevor ein Angreifer sie findet. Das ist der Schlüssel, denn in den meisten Unternehmen gibt es Dutzende, manchmal Hunderte von OAuth-Integrationen, und niemand hat einen vollständigen Überblick. Microsofts Ansatz macht diese Transparenz erzwingbar und reduziert die Angriffsfläche.

Die Angriffsfläche verkleinern: Was Unternehmen jetzt tun können

Microsofts Handlungsempfehlungen sind pragmatisch und decken sich mit den Lektionen, die jede der betroffenen Unternehmen nach den Vorfällen gelernt hat. Erstens: Verbinde die Salesforce-Instanzen mit Defender for Cloud Apps, um die erweiterte Telemetrie zu erhalten. Zweitens: Aktiviere und überwache tatsächlich die Salesforce-Ereignisprotokolle – viele Kunden schalten sie ein, schauen aber nie hinein. Drittens: Schränke den Gastzugang zu Experience Cloud-Seiten auf das absolute Minimum ein. Darüber hinaus gelten die immer gleichen, aber dennoch wichtigen Schritte: Führe ein vollständiges Inventar aller verbundenen Apps, entferne diejenigen, die niemand mehr nutzt, schränke die verbleibenden auf die geringstmöglichen Berechtigungen ein, und sei bereit, Tokens sofort zu widerrufen und zu rotieren, sobald eine Integration ein ungewöhnliches Verhalten zeigt.

Diese Liste mag trivial erscheinen, aber nur, weil sie so häufig wiederholt wird. Die Realität ist eine andere: In den meisten Unternehmen gibt es keine automatisierte Erkennung für OAuth-Missbrauch. Die Identitätskontrollen der letzten zehn Jahre waren auf menschliche Anmeldungen ausgelegt: MFA, Conditional Access, Sitzungsrichtlinien. Die OAuth-Apps, Integrationskonten und Service-Anmeldeinformationen, die die eigentliche Arbeit in einer modernen Salesforce-Umgebung erledigen, stehen meist außerhalb dieses Schutzes. Sie sind unbeaufsichtigt, überprivilegiert und vergessen. Die Angreifer von ShinyHunters haben genau diese Lücke erkannt und über ein Jahr systematisch genutzt. Mehr als einmal war der Zugang nicht mehr als eine Berechtigung, die jemand abzuschalten vergessen hatte. Es ist nicht die spektakuläre Sicherheitslücke, die Schlagzeilen macht, sondern die alltägliche Nachlässigkeit, die uns verwundbar macht. Der Microsoft-Bericht ist ein Weckruf, der zeigt, dass Sicherheit nicht aufhört, wenn der Benutzer authentifiziert ist. Sie muss das gesamte Ökosystem aus Vertrauen umfassen, das wir um unsere Systeme herum aufbauen. Und genau dieses Vertrauen müssen wir kontrollieren, sonst tut es jemand anderes für uns.

Quelle: thehackernews.com