Kategorie: Einblicke

Ein Entwickler mit jahrzehntelanger Infrastruktur-Erfahrung beschreibt, wie er seinem KI-Coding-Agenten direkten Zugriff auf sensible Produktionsgeheimnisse gewährt: Tailscale-Auth-Key, SSH-Private-Keys, OAuth-Tokens für Anthropic und Codex sowie ein Gmail-App-Passwort. Die Werte liegen in einem Passwort-Tresor; der Agent nutzt sie, ohne die Klartext-Inhalte zu sehen. Das Setup liegt bewusst jenseits dessen, was viele Sicherheitsrichtlinien empfehlen. Der Autor macht das transparent.

Wie funktioniert dieses Setup? Wo geht er bewusst Risiken ein, wo ist die Argumentation nachvollziehbar? Wer mit Coding-Agents arbeitet, steht früher oder später vor genau dieser Frage: Wie viel Vertrauen bekommt ein Werkzeug, das Texte aus dem Internet liest und Root-Rechte auf einem Produktionssystem haben könnte?

Hintergrund des Autors: Infrastruktur-Erfahrung und KI-Agenten-Plattform

Der Autor stellt seinen Werdegang voran, um die Tragweite seiner Entscheidung zu begründen. Er arbeitete in Rechenzentren, betrieb jahrelang Linux-Infrastruktur, war Security- und Network-Engineer und baute Produktionssysteme für verschiedene Firmen – darunter eine Plattform für KI-Coding-Agents, die nach seinen Angaben Hunderttausende nutzen. Diese Selbstauskunft soll Glaubwürdigkeit schaffen. Wer Sicherheitsfragen behandelt, sollte wissen, wovon er spricht.

Die Doppelrolle erzeugt eine Spannung: Wer eine Agent-Plattform mit großer Verbreitung betreibt, will Agents als produktiv und sicher zugleich wahrgenommen sehen. Das macht seine Aussagen nicht falsch. Aber man sollte sie vor diesem Hintergrund lesen, statt sie ungeprüft zu übernehmen. Am Ende sind es die persönlichen Trade-offs einer einzelnen Person, keine allgemeingültige Sicherheitsempfehlung.

Simon Willisons tödliche Dreiheit: Alle Risiken sind erfüllt

Der Autor beruft sich auf Simon Willisons Konzept der ›lethal trifecta‹ – der tödlichen Dreiheit. Ein KI-Agent besitzt darin drei Fähigkeiten gleichzeitig: Zugriff auf private Daten, die Fähigkeit, nicht vertrauenswürdige Inhalte zu lesen, und die Möglichkeit, nach außen zu kommunizieren. Die Kombination ist gefährlich, weil ein Angreifer in einem scheinbar harmlosen Dokument, einer Webseite oder einem Issue versteckte Anweisungen unterbringen kann. Der Agent befolgt sie, ohne dass der Mensch am Bildschirm es merkt.

Das beschriebene Setup erfüllt genau dieses Profil. Der Agent hat über den Passwort-Tresor Zugriff auf produktive Geheimnisse, liest in seinem Aufgabenbereich Code, Webseiten, Issues und möglicherweise E-Mails und kann über das Netzwerk nach außen kommunizieren. Ein einziger geschickter Prompt-Injection-Vektor könnte ihn dazu bringen, diese Geheimnisse nach außen zu senden. Der Autor verschweigt das nicht. Er benennt das Risiko ausdrücklich und verwendet bewusst das Wort „in theory“, um zu zeigen, dass er es kennt.

Produktivitäts-Tradeoff: Warum der Zugriff sinnvoll ist

Das Vertrauen folgt einer einfachen Rechnung. Ein Agent mit Produktionszugriff kann bei einem Ausfall selbstständig Logs lesen, Hypothesen bilden, einen Fix deployen und prüfen, ob er funktioniert. Ohne den Zugriff übernimmt der Mensch diese Schritte manuell – genau diese Schleife kostet bei Vorfällen wertvolle Minuten.

Dazu zieht er einen Vergleich, der in Diskussionen über KI-Agenten selten fällt: den mit einem neuen, unerfahrenen Teamkollegen. Auch einem neuen Mitarbeiter gibt man Zugriff auf Produktionssysteme, obwohl er versehentlich Malware installieren oder auf eine Phishing-Mail hereinfallen könnte. Man gibt den Zugriff trotzdem – die Alternative, gar nichts zu delegieren, würde den Betrieb unmöglich machen. In dieser Sicht ist der Agent keine Blackbox, sondern ein Teammitglied mit einer anderen Fehlerklasse. Die Analogie ist gewagt, weil ein Mensch rechtlich und organisatorisch eingebunden ist, ein Agent nicht. Das Grundprinzip der Abwägung ist aber plausibel.

Frontier-Modelle und Prompt-Injection: Warum das Risiko neu bewertet wird

Ein zentraler Punkt: Aktuelle Frontier-Modelle sollen besser zwischen Anweisungen des Nutzers und Anweisungen in gelesenen Inhalten unterscheiden können. Der Autor arbeitet laut eigenen Angaben ausschließlich mit Astra und Fable für schwierige Probleme sowie Sol und Opus für Routineaufgaben. Ältere Modelle hätte er mit diesem Setup nicht betraut; bei den aktuellen sei die Sorge vor Prompt-Injection deutlich geringer.

Vorsicht ist angebracht. Die Aussage, Modelle würden besser zwischen Nutzer- und Inhaltsanweisungen trennen, wiederholt das, was Labore in ihren Berichten schreiben. Das Problem ist damit nicht gelöst. Die Forschung ist sich weitgehend einig: Eine robuste, nachweisbare Lösung gegen Prompt-Injection gibt es nicht. Es gibt nur Modelle, die in Benchmarks und Red-Teamings seltener darauf hereinfallen. Wer das anders darstellt, macht sich etwas vor.

Der Autor grenzt weiter ein: Das Vertrauen gilt Agents, die in der eigenen, als vertrauenswürdig eingestuften Codebase arbeiten. Ein zufälliges GitHub-Projekt mit derselben Zugriffsstufe zu öffnen, wäre eine sehr schlechte Idee. Wichtiger Hinweis: Die Angriffsfläche wächst mit der Menge an unvertrautem Input, den ein Agent verarbeitet.

Docker als Sandbox: Isolation statt Sicherheitsgrenze

Trotz des Vertrauens laufen seine Agents in isolierten Docker-Containern. Der Autor sagt ehrlich, warum: Die Container trennen die Arbeitsverzeichnisse der Agents, verhindern, dass sich parallele Dev-Server stören, und fangen wilde rm -rf-Kommandos auf – oder Prozesse, die man später aufräumen müsste. Wer schon einmal erlebt hat, wie ein Agent die eigene Festplatte oder einen Git-Worktree demoliert, weiß den Komfort zu schätzen.

Gleichzeitig machen die Container für ihn keine Sicherheitsgrenze aus. Geheimnisse und Zugriff auf Produktionsmaschinen bleiben verfügbar; einen Prompt-Injection-Angriff hält eine Sandbox nicht auf. Diese Unterscheidung zwischen Komfort und Sicherheit ist ehrlich – und sie fehlt in vielen Blogposts.

Least Privilege und die Frage nach der feinkörnigen Kontrolle

Der klassische Einwand lautet: Prinzip der minimalen Rechte, „least privilege“. Jeder Agent soll nur die Zugriffe bekommen, die er für seine Aufgabe braucht. Der Autor widerspricht nicht im Prinzip, bezweifelt aber, dass die Praxis schon so weit ist. Feinkörnige Kontrollen stünden im Weg, wenn ein Agent spontan von einer Log-Analyse zu einem Deployment wechseln muss, um ein Problem zu beheben.

Ein weiterer Punkt wird in der Security-Community gern übersehen: Das Verstecken von Credentials allein löst das größte Risiko nicht. Ein Agent, der nie einen SSH-Key im Klartext sieht, aber eine Root-Shell auf einem Produktionsserver bekommt, kann trotzdem rm -rf ausführen und das System zerstören. Credential-Hygiene ist wichtig, aber sie ist nicht Zugriffskontrolle. Diese Unterscheidung sollte man sich merken – viele Secrets-Management-Lösungen laufen an der eigentlichen Gefahr vorbei.

Die philosophische Frage: Wetten wir gegen die Modelle?

Zum Schluss blickt der Autor nach vorn. Wer annimmt, Agents müssten auf absehbare Zeit streng kontrolliert werden, wettet gegen weitere große Modellverbesserungen. Treten sie ein, könnten wir Agents irgendwann mehr vertrauen als uns selbst. Das klingt provokant, ist aber eine logische Konsequenz des aktuellen Trends: Modelle werden in Benchmarks zuverlässiger, die Fehlerquote bei klassischen Aufgaben sinkt messbar.

Offen bleibt, ob sich Zuverlässigkeit in Benchmarks auf die offene Welt übertragen lässt. Wählt ein Agent in 99 Prozent der Fälle die richtige Aktion, ist er im verbleibenden Prozent ein kaum kalkulierbares Risiko – gerade wenn dieser eine Fall das rm -rf ist. Modell-Updates helfen dann nicht mehr. Nötig ist Architektur: Read-only-Tools für gefährliche Operationen, Bestätigungsschritte für destruktive Aktionen, Audit-Logs, die zeigen, was passiert ist.

Was das für die eigene Arbeit mit Coding-Agents bedeutet

Was bleibt von diesem Erfahrungsbericht? Erstens: Eine wachsende Zahl von Entwicklern gibt ihren Agents deutlich mehr Vertrauen, als die Sicherheitsliteratur empfiehlt – mit bewusster Risikoabwägung. Das ist kein Grund, es nachzumachen. Aber es zeigt, dass die Diskussion über Agent-Sicherheit nicht nur aus Verboten bestehen kann.

Zweitens: Die tödliche Dreiheit bleibt real, auch wenn Modelle besser werden. Wer Agents mit Produktionszugriff ausstattet, muss fragen, ob der gelesene Input kontrolliert ist und ob sich die Kommunikation nach außen einschränken lässt. Drittens: Docker sorgt für Komfort und Reproduzierbarkeit, ist aber keine Verteidigung gegen Prompt-Injection. Viertens: Wer Least Privilege umsetzen will, braucht Tools, die granulare Freigaben erzwingen – nicht nur versteckte Geheimnisse.

Die zentrale Botschaft ist keine Empfehlung, sondern eine Einladung zum Nachdenken. Coding-Agents mit Produktionszugriff sind längst Alltag in vielen Teams. Wie viel Vertrauen wir ihnen geben, ist keine rein technische Frage. Es ist eine Entscheidung zwischen Produktivität und Kontrolle – nicht verallgemeinerbar, aber bewusst treffbar.

Quelle: jacob.gold

In der KI-Forschung gilt das Training moderner Basismodelle als Spiel der ganz Großen: Zehntausende Spezialchips, hunderte Millionen Dollar Rechenbudget und ein Heer von Ingenieuren scheinen die notwendige Ausstattung zu sein. Genau dieses Bild stellt ein technischer Bericht des KI-Labors Magic infrage, denn dort wurde ein Pretraining-Rezept entwickelt, das mit einem Bruchteil der üblichen Rechenleistung das Niveau führender offener Basismodelle erreicht. Wirft man einen Blick auf die Zahlen, wird klar, warum diese Ankündigung in der KI-Community Aufsehen erregt. Das Team von Magic arbeitet an Coding-Agenten und automatisierter KI-Forschung und sieht sich selbst als kleinstes Team der Welt, das Modelle im Billionen-Parameter-Bereich anstrebt.

Der Effizienzsprung in Zahlen

Die zentrale Behauptung: Magics Pretraining-Rezept sei mehr als zehnmal recheneffizienter als das führender Open-Weight-Basismodelle. Konkret schreiben die Autoren, sie erreichten mit einem ihrer Modelle das Leistungsniveau von DeepSeek V4 Pro Base – mit ungefähr fünfzigmal weniger Trainings-FLOPs. Als Maßeinheit dient die übliche Näherung 6·N·D, also sechs mal aktivierte Parameter mal Trainings-Token. Das kleinste aktuell beschriebene Modell besitzt danach ein Budget von rund 1,6 × 10^23 FLOPs.

In Dollar umgerechnet ist das wenig: Auf Nvidia-GB200-Systemen entsprächen rund 1,6 × 10^23 FLOPs geschätzten 500.000 Dollar Rechenkosten. Zum Vergleich: DeepSeek V4 Pro wird in derselben Näherung mit rund 9,7 × 10^24 FLOPs geführt, etwa dem Sechzigfachen. Wer ein Modell auf dem Niveau von DeepSeek V4 Pro bauen will, kann das nach Magics Methode offenbar zu einem Bruchteil der bisher veranschlagten Kosten tun. Nach oben haben sie noch einmal nachgelegt: Ein zehnmal größeres Modell, intern als e24 bezeichnet, kostete auf dem Papier rund vier Millionen Dollar und soll laut den internen Perplexitätsmessungen sämtliche öffentlich verfügbaren Open-Weight-Basismodelle übertroffen haben.

Provokant wird diese Aussage im Vergleich mit den Skalierungsgesetzen der Konkurrenz. Nach Magics eigener Kurvenanpassung würde ein Modell mit diesen Fähigkeiten nach dem Rezept von DeepSeek V4 Pro mehr als 100 Millionen Dollar an Trainingskosten verursachen. Das Team betont deshalb offen, dass man mangels eigener Chip-Armeen nur über einen Hebel verfüge: algorithmische Effizienz. Diese Effizienz treiben sie nun offenbar in einem Ausmaß, das die übliche Logik „viel Rechenleistung schlägt clevere Optimierung“ auf den Kopf stellt.

Perplexität, Bits pro Byte und gehaltene Daten

Bei Basismodellen lassen sich Fähigkeiten nicht einfach per Chatbot-Benchmark abfragen, weil sie noch nicht auf Prompts optimiert sind. Schon minimale Formulierungsunterschiede können die Ergebnisse massiv verändern. Deshalb setzen die Magic-Forscher auf eine direkte Metrik: Bits pro Byte. Diese Größe beschreibt, wie viele Bits ein Modell durchschnittlich benötigt, um ein Byte komprimierter Daten vorherzusagen. Je niedriger der Wert, desto besser das Modell. Gegenüber der klassischen Perplexität hat diese Messung den Vorteil, dass sie Unterschiede in der Tokenisierung normalisiert.

Um sicherzugehen, dass nicht auswendig gelernt wird, statt zu generalisieren, wurden gehaltene Datensätze zusammengestellt: der eigene Code, private Code-Repositories anderer Startups, frische Forschungsarbeiten mit wenig Zitationen sowie private Mathematikaufgaben. Aus dem eigenen Trainingskorpus entfernten die Forscher alle Dokumente, die eine hohe Ähnlichkeit zu diesen Evaluationsdaten aufwiesen – über einen Abgleich normalisierter Textfenster. Zusätzlich nutzen sie für die Eval-Daten ein anderes Parsing- und OCR-System als im Pretraining, damit das Modell nicht die Eigenheiten seines Trainingsparsers ausnutzen kann.

Auch der Ansatz, Wissen zu testen, ist aufschlussreich. Bei Domänen wie Informatik, Mathematik oder Medizin geht es nicht nur um Generalisierung, sondern auch darum, ob relevantes Fachwissen im Modell verankert ist. Das Problem: Genau diese Inhalte sollen im Trainingskorpus vorkommen. Um zu verhindern, dass wörtliche Memorierung belohnt wird, ließen die Forscher Dokumente mithilfe eines dritten Frontier-Modells umformulieren und zusammenfassen. So bleibt der semantische Kern erhalten, aber die Wortkette des Originals hilft bei der Evaluation nicht mehr. Um eine Überanpassung auf diese granularen Tests zu vermeiden, erstellt das Team die Tests bewusst nur einmal pro Modellgeneration. Die aktuellen Eval-Kategorien entstanden erst kurz vor Veröffentlichung des Berichts, was den zeitlichen Abstand zum Trainingsprozess dokumentiert.

Viele kleine Optimierungen statt eines einzelnen Tricks

Wer einen großen Effizienzsprung erwartet, sucht wahrscheinlich nach einem einzelnen revolutionären Einfall. Magics Bericht enttäuscht diese Erwartung: Der Gewinn sei das multiplikative Ergebnis dutzender Änderungen an Architektur, Optimierer, Trainingsziel und Datenaufbereitung. Das klingt unspektakulär, ist aber in der Praxis schwer zu erreichen – gerade weil viele Einzeländerungen bei kleinen Modellen funktionieren, aber bei großen nicht.

Deshalb setzten die Forscher auf einen strikten Validierungsprozess. Jede Kandidatenänderung wird an drei Modellgrößen getestet, deren Rechenbudgets sich über zwei Größenordnungen erstrecken. Nur wenn die Messpunkte im Log-Log-Diagramm eine Gerade ergeben und der Fit für sehr große Skalen einen Vorteil prognostiziert, wird die Änderung ins Rezept übernommen. Diese Methode schützt vor vorschnellen Schlüssen aus NanoGPT-Speedruns, die in der Szene oft als schnelle Feedbackschleife gelten. Das Team fand dabei auch Überraschendes: Manche Features, die heute in fast jedem großen Sprachmodell stecken, können ersatzlos entfernt werden, ohne die Leistung großer Modelle zu schädigen.

Der Weg zu diesem Punkt war steinig. Ende 2024 scheiterten die ersten Skalenversuche auf vielfältige Weise, wie es in dem Bericht heißt. Also arbeitete man zunächst an den Grundlagen: stabile Konvergenz, niedrige Präzision, die der Qualität von FP32 entspricht, schnelle Infrastruktur und korrekte Hyperparameterskalierung. Vor allem: konsequente Fehlersuche. Erst danach ließ sich mit den eigentlichen Effizienzexperimenten beginnen. Alle paar Wochen erlaubt sich das Team einen Lauf auf einem Zehntel der Zielgröße, alle paar Monate einen vollständigen Hero-Lauf. Fortschritt entsteht hier nicht durch punktuelle Eingebung, sondern durch kontinuierliche Iteration.

Warum das die Ökonomie des KI-Trainings verändert

Die wichtigste Implikation liegt nicht in einem einzelnen Modell, sondern in der Frage, wer überhaupt noch Grundmodelle trainieren kann. Bisher galt: Wer die Skalierungsgesetze ernst nimmt, muss sein Rechenbudget aggressiv erhöhen, um bessere Modelle zu bekommen. Chips und Kapital wurden zum bestimmenden Faktor. Wenn ein Team mit einem Bruchteil der Ressourcen das gleiche Niveau erreicht, wird algorithmische Effizienz zur strategischen Waffe.

Für Open-Weight-Modelle bedeutet das eine ungewohnte Dynamik. Nicht mehr nur die Großlabors mit proprietären Infrastrukturen könnten die besten Basismodelle hervorbringen. Auch kleinere Organisationen und Forschungseinrichtungen bekämen die Möglichkeit, Modelle mit weniger FLOPs zu trainieren und anschließend in nachgelagerte Bereiche zu investieren: Alignment, Reinforcement Learning, lange Kontexte. Diese Kombination aus effizientem Pretraining und anschließender Optimierung könnte den Abstand zwischen kommerziellen Giganten und unabhängigen Labors verkleinern.

Eine Einschränkung bleibt: Der Bericht ist bislang eine Eigenauswertung. Die Loss-Messungen wurden intern durchgeführt, öffentliche Vergleichsmodelle testete das Team zwar in mehreren Inferenz-Backends wie vLLM und SGLang und ließ die Ergebnisse von Fireworks gegenprüfen, doch unabhängige Reproduktionen stehen noch aus. Hinzu kommt eine Schwierigkeit: Kontamination lässt sich nur bei den eigenen Modellen kontrollieren, nicht bei den offenen Vergleichsmodellen. Wenn ein Teil der gehaltenen Internet-Daten schon in deren Trainingsdaten auftaucht, würde das die Vergleichsmodelle eher begünstigen als Magics Modelle, wodurch der gemessene Vorsprung konservativ sein dürfte. Trotzdem ist Vorsicht angebracht, bis weitere externe Tests die Ergebnisse bestätigen.

Nächste Schritte: Vom Basismodell zum Coding-Agenten

Magic hat ein klares Ziel vor Augen: Das Pretraining zusammen mit Long-Context-Techniken und agentischem Reinforcement Learning soll ausreichen, um übermenschliche Coding-Agenten zu bauen und schließlich große Teile der KI-Forschung zu automatisieren. In dem Blogpost wird dieser Plan nur grob skizziert, aber die Prioritäten sind erkennbar. Die Pretraining- und Long-Context-Arbeit gelte inzwischen als ausgereift, heißt es, nun wolle man das Training von Agenten über lange Zeiträume angehen. Konkrete offene Probleme sind die Erkundung in langen Zeithorizonten und die Zuordnung von Belohnungen, dazu die nötige Systemarbeit, um solche Trainingsläufe überhaupt zu bewältigen.

Auch das Thema Sicherheit wird angesprochen. Das Labor will eine aktualisierte „AGI-Readiness Policy“ veröffentlichen, die Einsatzgrenzen, Sicherheitsanforderungen während des RL-Trainings und den Umgang mit latenten Wissenskonflikten regeln soll. Für all das sucht das Team neue Mitarbeitende, denn ausdrücklich heißt es: Ein einzelner Mensch mit gutem Urteilsvermögen könne heute einen großen Einfluss auf die Entwicklung dieser Technologie nehmen.

Was bedeutet das nun für die KI-Landschaft? Wenn sich die Zahlen von Magic bestätigen, sinkt die Eintrittsschwelle für eigene Grundmodelle deutlich. Statt Hunderte Millionen Dollar nur für das Pretraining einzuplanen, würden einige Millionen und ein durchdachtes Rezept genügen, um mit den besten offenen Modellen mitzuhalten. Die Skalierungsgesetze im Deep Learning verlieren dann ihren Schrecken, weil ihre Steilheit von der Effizienz des Trainingsalgorithmus abhängt. Die nächsten Monate werden zeigen, ob das Modell hält, was die Kurven versprechen – und ob aus einem effizienteren Pretraining tatsächlich die versprochenen autonomen Coding-Fähigkeiten entstehen. Eines ist jetzt schon sichtbar: Der Wettbewerb um die besten Basismodelle ist nicht mehr allein eine Frage des Budgets, sondern auch eine Frage der Ideen.

Quelle: magic.dev

Wie schnell kann ein Angreifer ein Unternehmen heute durchdringen, wenn er KI-Agenten einsetzt? Der Incident-Response-Report von Unit 42, dem Sicherheitsforschungsteam von Palo Alto Networks, liefert eine konkrete Antwort: Was früher rund zwei Wochen dauerte, lief in weniger als zehn Stunden ab. Eine kleine Gruppe von Analysten rund um Renzon Cruz, Nicolas Bareil, Eric Semaan und Omar Jbari dokumentierte einen Vorfall, bei dem ein einzelner menschlicher Akteur mehrere spezialisierte KI-Agenten orchestrierte, um ein Unternehmensnetzwerk autonom zu kompromittieren. Der Angriff zielte auf eine Lösegeldzahlung. Was ihn besonders macht, ist nicht ein neuartiger Zero-Day-Exploit oder überlegene handwerkliche Fähigkeiten, sondern schlicht die Geschwindigkeit, mit der die Angreifer vorgehen konnten.

Die Angreifer nutzten sogenannte frontier AI models, also moderne Sprachmodelle mit hoher Leistungsfähigkeit, sowie spezialisierte agentic AI frameworks. Diese Frameworks sind im Grunde Software-Skelette, die einem KI-Modell erlauben, eigenständig Aufgaben zu planen, Werkzeuge aufzurufen und Entscheidungen in einer Schleife zu treffen. Der Mensch blieb der Dirigent. Er gab das Ziel vor und traf die wesentlichen Entscheidungen, etwa wann Verhandlungen aufgenommen werden. Die operative Kleinarbeit jedoch, das Sondieren von Netzen, das Auslesen von Quellcode, das Sammeln von Schlüsseln, delegierte er an die Agenten. Diese beobachteten Ergebnisse, bewerteten sie und planten den nächsten Schritt in Echtzeit.

Der Angriff im Zeitraffer: Zehn Stunden statt zwei Wochen

Die Aufschlüsselung des Vorfalls liest sich wie ein Drehbuch, das in fünf Akte gegliedert ist. Zunächst verschaffte sich der Akteur Zugang über eine öffentliche API-Schnittstelle, also über eine programmierbare Schnittstelle, die ein Unternehmen externen Diensten zur Verfügung stellt. Durch diese Lücke tunnelte er in das interne Netz und setzte einen Aufklärungs-Agenten ein, der die internen Microservices kartierte. Microservices sind kleine, eigenständige Programmbausteine, die gemeinsam eine Anwendung bilden. Wer ihre Struktur kennt, kennt die Anatomie der gesamten Software.

Im zweiten Akt suchten Unteragenten in den Code-Repositorys, also den zentralen Ablagen für Quelltext, nach hartkodierten Tokens und Service-Passwörtern. Solche Geheimnisse, die direkt im Programmtext stehen, sind seit Jahren ein bekanntes Problem, werden aber in der Realität weiterhin fleißig produziert. Mit den gefundenen Tokens infiltrierte der Angreifer im dritten Schritt das zentrale Secrets-Management-System und erbeutete administrative Hauptschlüssel, die ihm Root-Zugriff, also volle Systemrechte, verschafften.

Danach missbrauchte der Akteur eine CI/CD-Pipeline, also jene automatisierten Abläufe, die normalerweise dafür sorgen, dass neuer Code getestet, gebaut und ausgeliefert wird. Über diese Pipeline exfiltrierte er Cloud-Zugriffsschlüssel. Er versuchte zudem, Hintertüren in Terraform-Konfigurationen zu platzieren. Terraform ist ein Werkzeug, mit dem Infrastruktur als Code beschrieben wird. Hier blockierten allerdings strenge Branch-Protection-Regeln, also Schutzmechanismen, die unautorisierte Änderungen am Hauptzweig des Codes verhindern, den letzten Schritt. Im letzten Akt nutzte der Angreifer gestohlene Cloud-Schlüssel, um die KI-Endpunkte des Opferunternehmens selbst in Angriffsinfrastruktur zu verwandeln. Er missbrauchte schlicht die Rechenleistung und die Modelle des Opfers, um seine nächsten Schritte vorzubereiten.

Spurensicherung im Code: Woran man Agenten erkennt

Eine zentrale Frage für jedes Verteidigungsteam lautet: Woran erkenne ich, dass ein KI-Agent am Werk ist und kein gewöhnlicher menschlicher Angreifer? Die Unit-42-Analysten fanden mehrere verräterische Indikatoren. Da wäre zunächst die parallele Nutzung mehrerer frontier AI agents über direkte API-Aufrufe, also standardisierte Schnittstellenaufrufe an Sprachmodelle, die nahezu gleichzeitig liefen. Menschliche Angreifer arbeiten sequenziell, eine Shell nach der anderen. Agenten hingegen schicken Anfragen in Bündeln.

Zweitens beobachteten die Analysten strukturierte Markdown-Dateien, die zwischen Agenten und Sitzungen als Notizbücher weitergereicht wurden. Markdown ist ein einfaches Textformat, das Überschriften, Listen und Code-Blöcke strukturieren kann. Wenn plötzlich Dateien wie plan.md oder task_status.md in kompromittierten Verzeichnissen auftauchen, ist das kein Zufall. Drittens fielen Skripte auf, die mit hoher Wahrscheinlichkeit von einer KI generiert wurden. Sie enthielten UI-Elemente, die auf Code-Assistenten wie Cursor oder ähnliche Werkzeuge hinweisen, etwa Hinweistexte zur Bedienung, die in menschlich geschriebenem Code selten vorkommen.

Viertens hinterließen die Agenten charakteristische Asset-Ordner, also Verzeichnisse mit temporären Dateien, die beim maschinellen Lernen und beim Codieren anfallen, sowie Python-Caches, also zwischengespeicherte Übersetzungsergebnisse, die der Interpreter bei jedem Programmlauf erzeugt. Solche Spuren sind das digitale Äquivalent zu einem verräterischen Werkzeugkasten am Tatort. Für Verteidiger bedeutet das: Wer in seinen Logs gezielt nach diesen Mustern sucht, kann agentische Angriffe früher erkennen, noch bevor Schaden entsteht.

MITRE ATT&CK und ATLAS: Die Angriffe im Standardrahmen

Unit 42 ordnete die beobachteten Techniken zwei etablierten Frameworks zu. MITRE ATT&CK ist die bekannteste Sammlung von gegnerischen Taktiken und Techniken. Sie reicht von Initial Access bis Exfiltration und wird weltweit von Verteidigern genutzt. MITRE ATLAS hingegen ist eine neuere Matrix, die sich auf Angriffe gegen Systeme mit künstlicher Intelligenz konzentriert. ATLAS ist die logische Ergänzung für eine Zeit, in der KI nicht mehr nur Werkzeug, sondern selbst Ziel oder Mittel ist.

Die initiale Kompromittierung einer öffentlichen API-Schnittstelle entspricht der ATT&CK-Technik T1190, dem Ausnutzen öffentlich erreichbarer Anwendungen. Die parallele Kartierung interner Dienste fällt unter T1046, das Aufspüren von Netzwerkdiensten. Das Absuchen von Code-Repositorys nach Tokens bildet T1552.001 ab, also das Sammeln von Anmeldedaten aus Dateien. Das Eindringen in das Secrets-Management-System fällt unter T1555, das Auslesen von Passwortspeichern. Im ATLAS-Framework spiegeln sich diese Schritte in AML.T0000 (Initial Access), AML.T0002 (AI-Automated Reconnaissance), AML.T0014 (Credentials Harvesting) und AML.T0016 (Privilege Escalation via Automated Pivot).

Besonders aufschlussreich ist die letzte Phase. Der Missbrauch der KI-Infrastruktur des Opfers durch gestohlene API-Schlüssel findet sich in ATT&CK unter T1078 (Valid Accounts) und im ATLAS-Framework unter AML.T0043 (LLM Invocations via Stolen API Keys). Diese letzte Kategorie existiert in den klassischen Bedrohungsdatenbanken gar nicht. Sie zeigt, dass Frameworks wie ATLAS nicht nur Theorie sind, sondern bereits konkrete Vorfälle abbilden.

Redundante Persistenz: Wenn Agenten überall Fuß fassen

Ein Aspekt, der in der öffentlichen Diskussion über KI-Cyberangriffe oft untergeht, ist die Frage der Persistenz. Ein Angreifer will nicht nur kurz hineinkommen, sondern sich dauerhaft festsetzen. Im dokumentierten Fall nutzten die Agenten ihre Geschwindigkeit, um an mehreren Stellen gleichzeitig Vorkehrungen zu treffen. Sie installierten zusätzliche SSH-Schlüssel auf Servern, also alternative Anmeldemethoden, die einen späteren Zugang erlauben. Sie registrierten serverlose Funktionen, also kleine Cloud-Programme, die nur bei Bedarf ausgeführt werden, als schlafende Hintertüren. Sie manipulierten Container-Restart-Policies, also Regeln, die bestimmen, wann ein containerisierter Dienst nach einem Absturz neu startet, um schädliche Container wiederzubeleben. Sie schufen neue Cloud-Identitäten und hinterlegten Trigger in CI/CD-Pipelines.

Diese verteilte Persistenz ist gefährlich, weil sie die spätere Säuberung enorm erschwert. Wer einen Kanal stopft, entdeckt drei weitere. Die Unit-42-Analysten werten das als klares Indiz dafür, dass Agenten dem Angreifer nicht nur Schnelligkeit, sondern auch eine breitere Angriffsfläche verschaffen. In menschlichen Operationen erfordert jede dieser Persistenzmaßnahmen Zeit und Sorgfalt. Agenten erledigen sie im Vorbeigehen, während sie ohnehin schon im System sind.

Was bedeutet das für Verteidiger?

Die Untersuchung liefert keine sensationellen neuen Exploits, sondern eine nüchterne Erkenntnis: Die Werkzeuge, mit denen Unternehmen täglich ihre Software entwickeln, lassen sich gegen sie selbst richten. CI/CD-Pipelines sind ein Segen, weil sie Releases beschleunigen. Sie sind ein Fluch, weil ein einziger gestohlener Token ausreicht, um den gesamten Veröffentlichungsprozess zu kapern. Cloud-KI-Endpunkte sind praktisch, weil sie Teams schnellen Zugriff auf leistungsfähige Modelle geben. Sie sind gefährlich, weil gestohlene Schlüssel dem Angreifer nicht nur Daten, sondern Rechenzeit und Modellzugang verschaffen.

Für die Praxis folgt daraus ein Katalog von Maßnahmen, der unspektakulär klingt, aber in der Realität noch immer selten konsequent umgesetzt wird. Secrets gehören nicht in Quellcode, sondern in dedizierte Tresore mit engmaschigen Zugriffsregeln. API-Schlüssel brauchen kurze Laufzeiten und klare Scope-Begrenzungen. CI/CD-Pipelines benötigen starke Branch-Protection, also den Schutz des Hauptzweigs vor unautorisierten Änderungen. KI-Endpunkte verdienen dasselbe Maß an Zugriffskontrolle wie produktive Datenbanken. Und wer agentische Angriffe erkennen will, sollte gezielt nach den oben genannten Spuren suchen, nach Markdown-Notizbüchern, Python-Caches und Spuren paralleler API-Aufrufe.

Was bleibt, ist eine verschobene Erwartung. Die Vorstellung, dass ein Angriff Wochen braucht, um unbemerkt zu bleiben, stimmt nicht mehr. Der dokumentierte Vorfall zeigt, dass die neue Taktung in Stunden gemessen wird. Verteidiger müssen sich darauf einstellen, nicht in Monaten, sondern in Minuten zu reagieren. KI-Agenten verändern nicht die Frage, ob ein Unternehmen angegriffen wird, sondern wie viel Zeit bleibt, um zu reagieren. Wer sich auf das alte Tempo verlässt, läuft der Realität hinterher.

Quelle: unit42.paloaltonetworks.com

Ein Entwickler lehnt sich zurück, während ein Agent eine Migration vorbereitet. Auf dem Bildschirm läuft ein Terminal, das jede Sekunde von der Postgres-Instanz neu liest. Links erscheinen die Unterschiede zur Baseline, rechts steht das Objekt selbst, vorher und nachher. So sieht Arbeit mit einem Sprachmodell heute aus: Man beschreibt, was man will, etwas schreibt das SQL, man liest es, gibt es frei, und Sekunden später ist das Schema ein anderes. Die aufregenden zehn Minuten danach sind das eigentliche Problem.

Was git diff nicht sehen kann

Wer mit Agenten arbeitet, kennt das Gespann aus Commit-Text und SQL-Datei. Das Versionskontrollsystem zeigt die Migrationsdatei. Es zeigt nicht, was die Migration tatsächlich getan hat. Und es zeigt schon gar nicht die Zeile, die ein Agent nebenbei aktualisiert hat, weil ihm das vernünftig erschien. Gute Schema-Diff-Tools existieren, aber sie funktionieren meist nach demselben Prinzip: Man startet sie hinterher, vergleicht zwei Datenbanken, und sie liefern ein Delta. Nichts davon bleibt während der Arbeit offen neben dem Agenten auf dem Bildschirm stehen.

Diese Lücke adressiert das Projekt diffium-db. Es handelt sich um ein Terminal-UI, das während der Arbeit geöffnet bleibt. Die Idee dahinter ist einfach, aber folgenreich: Nicht die fertige Aktion bewerten, sondern den Verlauf der Aktion am Bildschirm mitlesen. So entsteht ein Werkzeug, das für Datenbanken dieselbe Rolle spielt, die ein Datei-Diff-TUI für Quellcode schon längst spielt.

So arbeitet das Terminal-UI

Man zeigt diffium-db auf eine Postgres-Datenbank, nimmt eine Baseline, und lässt den Watcher laufen. Ab diesem Moment listet die linke Spalte alles auf, was sich seit der Baseline verändert hat. Die rechte Spalte zeigt das gewählte Objekt im Vorher-Nachher-Vergleich. Das Programm liest die Datenbank einmal pro Sekunde neu, schreibt eine Hash-Signatur für jede Zeile und vergleicht sie mit der Baseline. Wenn ein Agent eine Spalte anlegt, taucht sie in der linken Liste auf, fast so, wie eine Datei in einem Datei-Diff auftaucht.

Das Werkzeug beobachtet Tabellen mit ihren Spalten, Defaults, Identity-Spezifikationen, Constraints, Indizes und Triggern. Es beobachtet Views, materialisierte Views, Enums und Funktionen. Es beobachtet aber auch Zeilen, und genau das stellt sich als die interessantere Hälfte heraus. Wer nur Struktur prüft, sieht nur die Hälfte dessen, was passiert.

Vier Kommandos gehören zum Handwerk: `watch` öffnet das TUI, `snapshot` nimmt eine Baseline, `baselines` listet die gespeicherten Baselines, und `diff` gibt die Aenderungen aus und beendet sich. Letzteres nimmt `–exit-code` und liefert den Rückgabewert 1, sobald sich etwas geändert hat. Genug, um einen CI-Lauf scheitern zu lassen oder die Schleife eines Agenten zu stoppen, bevor er den nächsten Schritt macht.

Einrichtung und Demo

Man braucht Bun in Version 1.3 oder neuer und eine Postgres-Instanz, die überwacht werden soll. Es gibt genau eine zusätzliche Abhängigkeit, `@opentui/core`, weshalb die Installation schnell geht. Dann nimmt man eine Baseline und öffnet den Watcher. Das ist im Grunde schon die gesamte Einrichtung.

Das Repository liefert eine Demo mit, die den Ablauf sichtbar macht, ohne dass ein Agent beteiligt sein muss. Das SQL unter `examples/demo/01-baseline.sql` baut ein kleines `demo`-Schema mit Tabellen für Benutzer und Projekte auf. `examples/demo/02-agent-change.sql` simuliert, was ein Agent tut, wenn man ihm sagt: Leg Vertragspläne an, und räum etwas auf. Oeffnet man das TUI in einem Terminal und führt die zweite Datei in einem zweiten aus, landen fünf Aenderungen auf dem Bildschirm: ein neues Enum, zwei neue Spalten und ein neuer Index auf `demo.users`, ein gelöschter Index auf `demo.projects`, eine eingefügte und eine gelöschte Zeile.

Innerhalb des TUI bewegt man sich mit `j` und `k` durch die Liste, `s` wechselt zwischen nebeneinander und untereinander, `e` schreibt den vollständigen Diff in eine Datei. Im Hintergrund werkelt das OpenTUI-Framework, das eine vollständige Terminal-Oberfläche im Speicher zeichnen und damit auch ohne echtes Terminal getestet werden kann.

Warum Datenbank-Branches den Unterschied machen

Die Demo ist eine Demo. Für echte Arbeit richtet man das Werkzeug nicht auf die Produktion. Der Sinn besteht darin, den Agenten laufen zu lassen und hinterher zu lesen, was er gemacht hat, und das soll an einem Ort passieren, den man ohne Bedenken wegwerfen kann. Also geben wir dem Agenten einen Branch. Auf Neon, wo der Autor arbeitet, ist das ein Zweizeiler plus die Projekt-ID, weil dort mehrere Projekte parallel laufen und die CLI nicht raten soll, welches gemeint ist.

Man zeigt `DATABASE_URL` auf das, was der zweite Befehl ausgibt, nimmt dort die Baseline und lässt den Agenten auf dem Branch arbeiten. Der Branch entsteht Copy-on-Write aus seinem Vater, bringt also dasselbe Schema und dieselben Zeilen mit wie die Datenbank, die einen wirklich interessiert. Im vom Autor beschriebenen Beispiel dauerte das 1,2 Sekunden. Ungenutzte Branches legen ihre eigene Compute-Aktivität still, sodass vergessene Branches nicht weiter Strom verbrauchen.

Anschließend liest man den Diff. Wenn die Migration das tut, was man wollte, führt man sie gegen die echte Datenbank aus. Wenn der Agent etwas Unerwartetes getan hat, hat man das auf einer Kopie gesehen, und die Kopie löscht man. Das ist die Schleife. Sie ist billig genug, um sie jedes Mal zu durchlaufen, nicht nur, wenn man daran denkt. Prinzipiell funktioniert diffium-db mit jedem Postgres, nichts im Code ist Neon-spezifisch, aber Branching macht den Ablauf erst praktisch genug für den Alltag.

Was ein Zeilen-Diff beweisen kann

Struktur ist die einfache Hälfte. Zeilen sind die unbequeme. Um zu wissen, dass sich eine Zeile geändert hat, muss man sich merken, wie sie vorher aussah. Es ist unrealistisch, jede Zeile zu speichern, also speichert diffium-db einen Fingerprint: den Primärschlüssel, einen MD5-Hash der Textdarstellung der gesamten Zeile sowie eine kurze Vorschau. Billig in der Datenbank zu berechnen, billig zu halten, und es unterscheidet ein Insert von einem Update von einem Delete sauber.

Wenn der Primärschlüssel neu ist, handelt es sich um ein Insert. Wenn er verschwunden ist, um ein Delete. Wenn der Schlüssel gleich bleibt und der Hash sich bewegt, hat jemand diese Zeile bearbeitet. Das funktioniert, bis die Tabelle eine Spalte dazubekommt. Dann ändern sich alle Hashes auf einmal, und ein naives Werkzeug würde behaupten, jede einzelne Zeile sei bearbeitet worden. Dabei hat niemand sie bearbeitet. Die Form der Tabelle hat sich unter ihnen bewegt.

Das Werkzeug macht diesen Fehler nicht. Die Anzahl wird als `~3?` statt `~3` geschrieben, und die erste Zeile des Diffs erklärt das. Zwei Spalten sind angekommen, also liest sich jede Zeile der Tabelle als bearbeitet, und die Update-Zahl ist der Teil der Aussage, für den das Werkzeug nicht einstehen kann. Inserts und Deletes bleiben exakt, weil sie aus dem Primärschlüssel kommen und der Schlüssel sich nicht für die Form interessiert. Nur die Update-Zahl ist Raterei, und eine blanke Vermutung inmitten von Zahlen, die es beweisen kann, wäre der gesamten Anzeige abträglich. Tabellen ohne Primärschlüssel und Tabellen über `–row-limit` (standardmäßig 5000 Zeilen) bekommen nur die Zeilenzahl und keinerlei Aussage. Dasselbe Prinzip: Lieber weniger sagen als etwas, das nicht stimmt.

Warum der Struktur-Diff mit Text arbeitet

Der strukturelle Diff ruht auf einer einzelnen Entscheidung, die einen großen Teil des Verhaltens erklärt. Jedes Objekt wird in einen kanonischen Textblock mit deterministischer Zeilenreihenfolge gerendert. Eine Tabelle wird zu ihren Spalten, dann ihren Constraints, dann ihren Indizes, dann ihren Triggern, immer in genau dieser Reihenfolge. Der Struktur-Diff ist dann nichts weiter als ein Zeilen-Diff dieser Blöcke.

Diese eine Entscheidung finanziert viel. Eine hinzugefügte Spalte ist genau eine zusätzliche Zeile statt einer Tabelle, die vage anders aussieht. Nebeneinander werden die `+2 -0`-Zähler und das horizontale Scrollen durch einen langen Default-Ausdruck zum Geschenk. Es gibt einen Preis: Das Werkzeug beschreibt, wie die Datenbank jetzt aussieht, nicht das DDL-Statement, das dorthin führen würde. Für einen Watcher ist das die richtige Seite der Abwägung. Wer generierte Migrationen möchte, braucht ein anderes Programm.

Wo die Baseline gespeichert wird

Eine Baseline ist ein gespeicherter Wert, keine Live-Verbindung. Man kann sie jetzt nehmen und morgen dagegen diffen, mehrere benannte Baselines halten oder eine neben der Migration committen, die sie erzeugt hat. Per Default landen sie in `.diffium-db/snapshots/` als JSON. Mit `–store neon –store-url ` landen sie stattdessen in einem `diffium_db`-Schema in Postgres. Diese Variante nutzt man, wenn CI und Laptop sich darüber einigen müssen, was „vorher“ bedeutet.

Der Watcher schaut nie in sein eigenes Schema, also können die Store-URL und die überwachte URL dieselbe Datenbank sein. Mit dem Branch von vorhin kann die Baseline auf dem Branch selbst liegen, ein Schema versetzt von der Sache, die sie beschreibt. Der Branch ist dann das gesamte Experiment, und das Löschen des Branchs nimmt die Aufzeichnung mit.

Was noch fehlt

Was v1 nicht kann, in etwa in der Reihenfolge, in der es der Autor angehen will. Kein Bewusstsein für ORMs: v1 sagt, dass eine Spalte aufgetaucht ist. Es kann nicht sagen, welche Migrationsdatei oder welche Model-Definition sie hervorgebracht hat. Diese Zuordnung gehört zu einem ORM und soll als Nächstes kommen, der Pfad `src/orms/` ist dafür bereits angelegt und bewusst leer. Nur Postgres: Das Lesen des Katalogs lebt isoliert unter `src/pg/`, und nichts oberhalb dieser Grenze weiß, was ein Katalog ist, also hat ein zweiter Dialekt einen offensichtlichen Platz. Er existiert nur noch nicht. Keine Sequences: Jeder `bigserial` erzeugt eine, und sie bewegt sich bei jedem Insert. Reines Rauschen, bis jemand danach fragt. Polling statt Replikation: Das Werkzeug liest einmal pro Sekunde neu. Bei einer großen Datenbank wäre logische Replikation deutlich billiger, und das ist der naheliegende Schritt, falls das Polling jemals weh tut.

Eine Sache steht nicht auf dieser Liste und wird es auch nie sein. Das Werkzeug schreibt nicht in die Datenbank, die es überwacht. Das Einzige, was es schreibt, ist sein eigener Store, und das auch nur, wenn man ausdrücklich darauf zeigt.

Tests, Codeumfang und Haltung

Das Projekt umfasst rund 2.200 Zeilen Quellcode und etwa 900 Zeilen Tests. 64 dieser Tests laufen ohne jede Datenbank, einschließlich der Tests für das Terminal, weil OpenTUI in den Speicher rendert und das Gezeichnete sich prüfen lässt. Eine Aenderung am Layout bricht damit einen Test, statt still vor sich hin falsch auszusehen auf einem Screenshot, den man ohnehin nicht aktualisiert hätte.

Was den Autor nicht loslässt, ist der Zeilen-Diff. Es wäre einfacher gewesen, für jede Tabelle eine Zahl auszugeben und die Leute annehmen zu lassen, sie bedeute etwas. Die Version, die sagt „das kann ich nicht beweisen“, sieht etwas hässlicher aus. Er nimmt sie trotzdem. Ein Werkzeug, das neben einem Agenten sitzt und über dessen Arbeit berichtet, muss sorgfältiger sein als der Agent selbst. Der Code steht unter MIT-Lizenz auf GitHub. Wer es ausprobiert und es sagt etwas Falsches, soll ein Issue eröffnen.

Quelle: denislavgavrilov.com

„Across Vercel, we use coding agents to design and build pages that have to look and feel like Vercel.“ Mit diesem Satz beschreibt das Vercel-Team ein Problem, das viele Unternehmen kennen: KI-Agenten sollen Seiten bauen, die zur Marke passen. Aber Marke lässt sich schwer in Worte fassen. Vercel hat eine pragmatische Antwort gefunden: ein einzelnes öffentliches File namens design.md, das jeder Agent über eine URL laden kann. Dazu kommen ein öffentliches Stylesheet und ein Evaluationsprozess, der Regeln nachweisbar macht. Wer mit Coding Agents arbeitet, findet hier eine konkrete Anleitung, um KI-generierte Seiten konsistent im eigenen Look zu halten.

Warum ein einzelnes öffentliches File nötig ist

Der Ausgangspunkt war ein internes Skill namens product-design. Es liegt in jedem Vercel-Repository neben dem Code, den es steuert. Das Skill erklärt Agenten, wie sie das Designsystem finden, welche Produktrichtlinien gelten und wie die Gestaltung aussehen soll. Das funktioniert, solange Agenten in den Vercel-Codebasen arbeiten, wo Referenzen greifbar sind.

Es gibt Seiten, die außerhalb dieser Umgebung entstehen: Berichte, Proposal-PDFs, Landingpages oder Präsentationsdecks. Diese müssen wie Vercel aussehen, obwohl der Agent keinen Zugriff auf die Repositorys hat. Dafür wurde design.md gebaut. Es ist ein öffentlicher Text, der die wichtigsten Design-Guidelines bündelt und über eine URL abrufbar ist. Beliebige Agenten in beliebigen Umgebungen nutzen dieselbe Grundlage.

Wer versucht hat, Markenidentität in einem Prompt zu beschreiben, ahnt, warum das nicht trivial ist. Design ist subjektiv. Formulierungen wie „halte das Layout sauber“ sagen einem Modell wenig, weil jede KI etwas anderes darunter versteht. Vercels Ansatz ersetzt diese Vagheit durch konkrete Regeln, Beispiele und benannte Fehlerbilder.

Vom Prompt-Fiasko zum getesteten Regelwerk

Der erste Versuch war eine einfache Portierung: Das gesamte product-design-Skill wurde in einen öffentlichen Prompt gepackt. Das Ergebnis war ernüchternd. Jedes Modell interpretierte dieselbe Beschreibung anders und erzeugte unterschiedliche Seiten. In der Codebasis sieht ein Agent echte Komponenten und veröffentlichte Beispiele. Ein statischer Prompt enthält nur Wörter.

Also setzte das Team das File neu auf, mit einer Änderung: Jede Änderung wurde gegen feste Evaluations-Prompts getestet. Sieben Szenarien entstanden, abgeleitet aus realen Anwendungsfällen: ein Nutzungsreport, ein Verlängerungsangebot, ein Benchmark-Report, eine interaktive Planungsseite, ein Build-vs-Buy-Brief, ein Security-Governance-Brief und ein Präsentationsdeck. Die Prompts blieben stabil, während das File sich änderte. So ließ sich jede Verbesserung den Regeln zuordnen.

Der Test kam beim ersten Vergleich. Dieselbe Aufgabe, dasselbe Modell, einmal ohne und einmal mit design.md. Ohne das File erzeugte das Modell ein generisches SaaS-Dashboard. Mit dem File führte die Seite mit der Empfehlung zur Vertragsverlängerung, bündelte die kommerziellen Kennzahlen in einem Raster und stellte Peer-Vergleiche auf eine gemeinsame Skala. Es veränderte also nicht nur Styling, sondern auch Struktur und Hierarchie. Das war das Signal, weiterzumachen.

Drei Ebenen: Anleitung, Stylesheet, Auswertung

Das finale System besteht aus drei Teilen. Der erste Teil ist design.md selbst. Dieses File enthält Regeln, wie eine Seite aufgebaut sein sollte: Sie muss sowohl einen schnellen Executive-Read als auch eine detaillierte Prüfung unterstützen. Es beschreibt, wie man Behauptungen formuliert, wie Hierarchie, Typografie und Farbe zusammenspielen und wie die Wortmarke verwendet werden darf. Das File benennt auch unerwünschte Muster. Wiederkehrende generierte Design-Klischees bekommen Namen. Das hilft Agenten, sie zu erkennen und zu vermeiden.

Der zweite Teil ist ein öffentliches Stylesheet. Agenten hatten zuvor eigene Typografie, Abstände und Layouts erfunden. Vercel hat diese Entscheidung dem Modell entzogen. Das Stylesheet definiert eine dokumentierte Sammlung von Klassen und Tokens für Header, Tabellen, Statistik-Blöcke und Diagrammstile. design.md verweist auf diese Klassen, sodass der Agent sie direkt im HTML verwenden kann. Der Agent muss das Stylesheet nicht lesen, es wird im Browser geladen. So bleibt der Kontext des Modells frei für die Design-Regeln.

Der dritte Teil ist eine Auswertungsschleife. Deterministische Checks fangen mechanische Fehler ab, etwa eine Tabelle, die die verfügbare Breite ignoriert. Menschliche Reviewer beurteilen subjektive Aspekte: Hierarchie, Komposition und die Frage, ob die Seite liefert, was der Leser braucht. Alle drei Ebenen zusammen bilden ein System, das besser wird.

Wie Regeln entstehen: Szenarien, Runden, Korrekturen

Jede Regel in design.md hat ihren Platz über die Evaluationsschleife verdient. Dafür werden die sieben Szenarien mit festen Eingaben und gleichen Viewport-Einstellungen ausgeführt. Eine Runde besteht daraus, für jedes Szenario eine frische Seite gegen die aktuelle Version des Files zu generieren. Volle Runden laufen mit zwei Modellen: Claude Opus 4.8 und Codex mit GPT-5.5. Wenn nur ein bestimmtes Verhalten untersucht werden soll, reichen die betroffenen Szenarien erneut.

Die Ergebnisse werden in einer lokalen App angezeigt. Jede gespeicherte Ausführung enthält Prompt, Eingaben, Modellkonfiguration, die Version von design.md, Screenshots und das Feedback der Reviewenden. Dieses Feedback wird gegen die exakte Ausführung protokolliert. Daraus entstehen die Regeln: Urteilsfragen landen als Prosa in design.md, wiederverwendbare Mechanismen im Stylesheet, und prüfbare Aspekte werden deterministische Checks.

Ein Beispiel zeigt, wie konkret das wird. In einem frühen Verlängerungsangebot war die Tabelle mit den Vertragskonditionen auf die Breite des Fließtexts zusammengequetscht, obwohl doppelt so viel Platz zur Verfügung stand. Das gleiche Muster tauchte in anderen Ausgaben auf. Die Korrektur kam in zwei Formen: als Regel im File und als Check im Code. Spätere Läufe erzeugten vollbreite Tabellen. Um solche Änderungen abzusichern, wiederholte das Team die betroffenen Szenarien. Bei Meilensteinen gab es blinde A/B-Vergleiche zwischen alter und neuer Version.

Was die Messung zeigt

Bis das File fertig war, liefen über 200 Generierungen, volle Runden, gezielte Tests, Sackgassen inklusive. Am Ende wollte das Team wissen, ob die eingebauten Korrekturen verhindern, wofür sie gedacht sind. Dazu wurden drei Desktop-Szenarien ausgewählt. Für jedes Szenario erzeugte ein Modell die Seite zweimal: einmal mit und einmal ohne design.md. Die allererste Generation wurde verwendet, ohne Neustart. Danach liefen alle sechs Seiten durch die deterministischen Checks.

Das Ergebnis: Mit design.md traten 39 bekannte Fehler auf, ohne das File 91. Das sind 57 Prozent weniger in diesem Test. Die Zahlen haben zwei Einschränkungen. Die Checks können nur Fehler finden, die bereits entdeckt und dokumentiert wurden. Sechs Seiten sind eine kleine Stichprobe. Jede einzelne Seite hatte mindestens einen Fehler, der ein Shipping verhindert hätte.

Was der Test zeigt, ist der Wert der Methode: Wenn man einen Fehler benannt und als Regel codiert hat, bleibt dieser Fehler in der Regel aus. Das klingt bescheiden, ist aber in der Arbeit mit KI-Agenten der Unterschied zwischen zufälligen Ergebnissen und kontrollierter Qualität. Es ist ein Fortschritt, der sich messen lässt, ohne dass man behaupten müsste, die KI sei jetzt „gut“.

Was du daraus mitnehmen kannst

Der Weg von Vercel lässt sich auf andere Teams übertragen, auch wenn das Designsystem kleiner ist. Der Kern ist die Kombination aus einer schriftlichen Design-Referenz, einem begrenzten Satz wiederverwendbarer Bausteine und einem Feedback-Loop, der aus Ausgaben lernt. Wer versucht hat, einem Agenten per Chat beizubringen, wie die eigene Marke aussieht, weiß, wie frustrierend das sein kann. Mit einer öffentlichen URL, die alle relevanten Regeln enthält, wird daraus ein kontrollierbarer Prozess.

Der aufwendigste Teil ist die Evaluationsschleife, aber sie ist auch der wichtigste. Ohne feste Szenarien und ohne die Bereitschaft, jede Regel durch die Brille der Ergebnisse zu prüfen, bleibt design.md nur ein weiterer Prompt. Mit dieser Schleife wird aus dem Dokument ein lebendes Regelwerk, das sich an Fehlern orientiert. Das unterscheidet Vercels Ansatz von üblichen Quick-Fixes: Es geht nicht um magische Prompts, sondern um Engineering.

Für alle, die mit Coding Agents arbeiten, ist das eine beruhigende Nachricht. Markenqualität muss nicht dem Zufall überlassen werden. Sie lässt sich in Dateien packen, in Checks gießen und durch Wiederholung verbessern, vorausgesetzt, man nimmt sich die Zeit, die Ausgaben systematisch zu bewerten. Auch in Zeiten generativer Modelle bleibt guter Geschmack eine Frage von klaren Regeln, ehrlichem Feedback und der Disziplin, beide gegeneinander zu testen.

Quelle: vercel.com