Kategorie: Erklärer

Stell dir vor, du bekommst einen neuen Kollegen. Er ist hochmotiviert, lernt schnell und arbeitet rund um die Uhr. Aber er kommt aus einer anderen Welt: Er hat noch nie auf deinem Rechner gearbeitet, kennt deine Skripte nicht und scheitert an den stillschweigenden Absprachen, die in deinem Team einfach jeder zu wissen scheint. So ähnlich erging es dem Unternehmen Cursor, als es seinen Cloud-Agenten eigene Computer gab. Die Entwicklerinnen und Entwickler merkten schnell: Wer Cloud-Agenten produktiv einsetzen will, muss deren Entwicklungsumgebung genauso ernst nehmen wie ein Produkt. Dieser Blogpost erklärt, wie Cursor das angegangen ist und warum die Umgebung zum entscheidenden Faktor wurde.

Vom lokalen Rechner zur Cloud-VM

Der erste Schritt war ernüchternd simpel und gleichzeitig verdammt aufwendig: Die Cloud-Agenten sollten Codeänderungen testen können. Dafür musste das Monorepo von Cursor in einer Cloud-VM lauffähig sein. Wer schon einmal eine Remote-Entwicklungsumgebung eingerichtet hat, kennt das Problem: Was lokal funktioniert, ist in der Cloud nicht automatisch vorhanden. Die meisten Entwicklerinnen und Entwickler bei Cursor arbeiten auf Macs, die Cloud-VMs laufen aber auf Linux. Also mussten Utilities und Setup-Skripte so angepasst werden, dass sie auf Ubuntu funktionieren. Dazu kam ein Dockerfile, das als Startpunkt für jeden Cloud-Agenten dient und die kritischen Entwicklungsabhängigkeiten enthält.

Doch damit war es nicht getan. Denn Agenten brauchen Zugriff auf Secrets, um Tests auszuführen. Das Sicherheitsteam von Cursor hat deshalb Funktionen eingebaut, die den Zugriff kontrollieren: Netzwerk-Egress-Restriktionen, gescopte und proxierte Git-Zugriffe, Secret-Scanning in Commits und Commit-Messages sowie Redaktion von Secrets in Tool-Ergebnissen. Letzteres ist besonders elegant: Selbst wenn der Agent versucht, einen Secret-Wert auszulesen, bekommt er nur maskierten Text zu sehen. Das sind Sicherheitsmaßnahmen, die nicht den Menschen schützen sollen, sondern die Infrastruktur vor ungewolltem Datenabfluss bewahren.

Der Agent als Nutzer einer vereinfachten Oberfläche

Nachdem die Entwicklungsumgebung technisch auf Linux lief, zeigte sich das nächste Problem: Die Agenten waren trotzdem schlecht darin, den Code auszuführen. Das lag nicht an mangelnder Intelligenz, sondern an der Komplexität der Entwicklererfahrung. Bei Cursor gab es zahlreiche Build-Kommandos, Build-Flags und Utility-Skripte, die man erst lernen musste. Ein Mensch merkt sich solche Abläufe nach ein paar Wochen. Ein Agent, der jedes Mal frisch startet, steht vor einem Berg aus undokumentiertem Zusammenhangswissen.

Die naheliegende Lösung waren Skills, also dokumentierte Anleitungen für den Agenten. Sie halfen am Rand, lösten das Grundproblem aber nicht: Die Kommandos selbst waren verschachtelt und voller Stolperfallen. Deshalb entstand bei Cursor ein Werkzeug namens anydev. Diese CLI erlaubt es Agenten, alle Dienste mit einem einzigen Befehl zu starten. Utility-Skripte werden durch anydev geroutet, und jeder Unterbefehl hat ausführliche --help-Menüs. Dazu kommt ein Supervisor-Prozess, der langlaufende Build-Kommandos überwacht und bei Abstürzen neu startet. Der Agent muss sich also nicht mehr darum kümmern, ob ein Prozess noch läuft.

Dieser Schritt war der Wendepunkt. Vorher mussten Agenten mehrere Befehle kennen, versteckte Fußangeln vermeiden und Prozesse im Auge behalten. Nachher war die Komplexität in einem Tool gebündelt, das selbst erklärend war. Skills dokumentierten dann nur noch, wie man anydev benutzt – und nicht mehr, welche kryptischen Flags man für welchen Dienst braucht. Laut dem Cursor-Team war das der Moment, in dem Cloud-Agenten echten Mehrwert gegenüber lokalen Agenten boten. Mit eigenem Rechner, Bildschirmaufnahme und funktionierender Entwicklungsumgebung konnten sie Änderungen end-to-end testen und die Korrektheit ihrer Arbeit nachweisen. Sie zeichneten Demos auf, teilten sie in Slack oder hängten sie an Pull Requests. Ingenieure konnten Merges und Deployments durchführen, ohne den Branch lokal auszuchecken.

Eine selbstheilende Umgebung

Eine Entwicklungsumgebung ist aber kein statisches Gebilde. Sie ändert sich mit jedem Commit, mit jeder neuen Abhängigkeit, mit jeder Verschärfung der Sicherheitsrichtlinien. Ein Cloud-Agent, der heute fehlerfrei arbeitet, kann morgen scheitern, weil sich ein Pfad geändert hat oder ein Secret nicht mehr gültig ist. Cursor hat deshalb eine Diagnose- und Reparatur-Ebene gebaut: den Cursor Cloud MCP. MCP steht für Model Context Protocol, ein offener Standard, der es ermöglicht, Werkzeuge dynamisch bereitzustellen. Der Vorteil: Die Schnittstellen lassen sich ändern, ohne den Agenten-Loop neu bauen zu müssen.

Cloud-Agenten nutzen diese MCP-Schnittstelle, um ihre eigene Umgebung zu inspizieren. Sie prüfen, ob Setup-Fehler vorliegen, ob die Egress-Policy noch stimmt, ob sich Secrets geändert haben. So können sie Probleme erkennen, noch bevor sie zu Fehlern führen. Darauf aufbauend entstand der Cloud Doctor: eine Automatisierung, die regelmäßig nach Fehlern sucht, zwischen transienten und dauerhaften Fehlern unterscheidet, eine Ursachenanalyse durchführt und bei hoher Konfidenz selbst Pull Requests öffnet, um die Umgebung zu reparieren.

Das klingt nach einem versierten DevOps-Team, nur eben als Software realisiert. Der Cloud Doctor ist nicht einfach ein Watchdog, der einen Dienst neu startet. Er versteht den Kontext: Dieser Fehler kam letzten Freitag schon einmal und war harmlos, jener ist neu und deutet auf ein echtes Problem hin. Er erinnert sich, welche Fehler transiente Ausreißer sind und welche auf systematische Schwächen hinweisen. Und er kann nicht nur reparieren, sondern auch die Ursache beheben – indem er einen Pull Request erstellt, der die Umgebung an die neue Realität anpasst.

Die Umgebung als lernendes System

Interessant wird es, wenn der Cloud Doctor nicht nur Fehler behebt, sondern die Umgebung für zukünftige Agenten verbessert. Das passiert laut Cursor über die Analyse von Trace-Daten. Wenn ein Agent einen Fehler gemacht hat, einen umständlichen Weg gegangen ist oder ein Skill ihn in die Irre geführt hat, dann sieht man das in den Logs. Der Cloud Doctor schaut sich diese Stellen an und fragt: Welcher Skill war irreführend? Welches Kommando war nicht eindeutig? Welcher Workflow dauert systematisch zu lange?

Aus diesen Erkenntnissen entstehen dann konkrete Verbesserungen: Ein Skill wird neu formuliert, ein Befehl vereinfacht, die Umgebung wird so verändert, dass der nächste Agent einen kürzeren und sichereren Weg hat. Diesen Kreislauf könnte man als Selbstheilung bezeichnen, aber eigentlich ist es mehr: Es ist eine kontinuierliche Optimierung der Entwicklererfahrung für Maschinen. Cursor behandelt die Agenten wie Nutzer, deren Produktivität davon abhängt, wie gut die Umgebung zu ihrer Art zu arbeiten passt. Und diese Nutzer sind gnadenlos ehrlich: Wenn etwas nicht funktioniert, scheitern sie sichtbar. Das ist ein Vorteil gegenüber menschlichen Nutzern, die oft einfach stillschweigend einen Workaround finden.

Die Zahlen, die das Cursor-Team nennt, sind beeindruckend. Im Dezember verfassten Cloud-Agenten etwa eines von zehn Pull Requests, die in das Monorepo gemergt wurden. Heute, nur wenige Monate später, sind es mehr als die Hälfte. Das ist kein Beweis für überirdische KI-Fähigkeiten, sondern für die Qualität der Umgebung. In einer Umgebung, die regelmäßig repariert, vereinfacht und an die aktuelle Codebasis angepasst wird, können Agenten ihre Stärke ausspielen: Sie arbeiten schnell, parallel und ohne Angst vor Fehlern – solange die Fehler schnell sichtbar und behebbar sind.

Drei Fragen an die eigene Codebasis

Was bedeutet das für Teams, die Cloud-Agenten einführen wollen? Das Cursor-Team schlägt vor, sich drei Fragen zu stellen. Erstens: Haben Agenten Zugriff auf dieselben Werkzeuge und Daten wie ein Entwickler? Zweitens: Können Agenten Skills finden, die dokumentieren, wie die Entwickler wirklich arbeiten? Drittens: Können Agenten die zentralen Workflows testen und verifizieren? Wer diese drei Fragen ehrlich beantwortet, erkennt schnell, wo die eigene Umgebung Lücken hat.

Die erste Frage zielt auf technische Gleichberechtigung. Ein Agent, der nicht dieselben Bibliotheken, Datenbanken oder Secrets nutzen kann wie ein Mensch, wird immer ein Bürger zweiter Klasse bleiben. Die zweite Frage ist eine Frage der Kultur: Viele Teams dokumentieren nicht, wie sie tatsächlich arbeiten. Sie haben Skripte auf dem Rechner eines Kollegen, Notizen in einem Ticket oder gar kein Wissen, weil es nur als Bauchgefühl existiert. Agenten können damit nichts anfangen – sie brauchen explizite, auffindbare Beschreibungen. Die dritte Frage ist der Härtetest: Kann ein Agent eine Änderung machen und dann beweisen, dass sie funktioniert? Wenn dafür zehn manuelle Schritte nötig sind, wird es schwierig.

Auf den ersten Blick mag das wie eine Checkliste für KI-Projekte wirken. Tatsächlich ist es eine Checkliste für gute Softwareentwicklung. Dass Cursor das Monorepo auf Ubuntu lauffähig gemacht hat, ist keine KI-Magie, sondern solides Engineering. Dass anydev die Build-Kommandos vereinfacht hat, ist eine klassische Verbesserung der Entwicklererfahrung – nur eben für einen anderen Nutzer. Und dass der Cloud Doctor Fehler behebt, bevor sie zum Problem werden, ist nichts anderes als Site Reliability Engineering, angewendet auf Agenten.

Was bleibt, ist eine erwachsene Erkenntnis: Cloud-Agenten sind keine Wunderwaffe, sondern Werkzeuge, die nur so gut sind wie ihre Umgebung. Eine chaotische Codebasis mit undokumentierten Skripten wird auch durch die besten Modelle nicht produktiv. Wer jedoch bereit ist, die Entwicklungsumgebung wie ein Produkt zu behandeln – mit Nutzerforschung, Bugfixes und kontinuierlicher Verbesserung – der bekommt Agenten, die nicht nur Code produzieren, sondern auch Verantwortung übernehmen können. Das ist der eigentliche Umbruch: Nicht die KI schreibt die Mehrheit der Pull Requests, sondern die Umgebung macht es möglich.

Quelle: cursor.com

Du kennst das: Du liest einen Artikel, und nach drei Sätzen hast du ein ungutes Gefühl. Das hat eine KI geschrieben. Nicht unbedingt, weil der Text fehlerhaft ist, sondern weil bestimmte Wörter und Floskeln immer wieder auftauchen. Künstliche Intelligenz hat einen eigenen Sound. Ein Tech-Blogger wollte das ändern – mit einem eher unbekannten Hebel: logit_bias. Das ist ein Parameter in manchen KI-APIs, mit dem sich die Wahrscheinlichkeit beeinflussen lässt, mit der ein bestimmtes Wort oder Wortteil erzeugt wird. Klingt trocken, hat aber weitreichende Folgen.

Ein kleiner Eingriff im Kopf der KI

Bevor eine Sprach-KI das nächste Wort schreibt, berechnet sie für jedes mögliche Wort einen Zahlenwert, den sogenannten Logit. Aus diesen Werten entstehen Wahrscheinlichkeiten, und danach wird das nächste Wort ausgewählt. logit_bias greift an genau dieser Stelle ein: Du kannst einen Zahlenwert zu einem bestimmten Wort hinzuaddieren, bevor die KI ihre Wahl trifft. Ein negativer Wert senkt die Chance, dass dieses Wort gewählt wird. Ein Wert wie -100 wirkt praktisch wie ein Verbot.

Stell dir das wie einen Weichenwärter vor, der bei jedem Zug eine Weiche etwas anders stellt. Nicht komplett, nur um ein paar Grad. Die KI kann immer noch viele Wörter wählen, aber ein paar sind plötzlich nicht mehr so attraktiv. Der Unterschied zu einem normalen Prompt ist gewaltig. Wenn du in den Prompt schreibst „benutze das Wort nicht“, liest die KI das als Anweisung. Sie kann es aber ignorieren, wenn andere Anweisungen wichtiger erscheinen. logit_bias fragt nicht, es arbeitet auf der Ebene der Zahlen.

Warum ein Verbot im Prompt nicht reicht

Ein Wort in den Prompt zu schreiben ist einfach und erfordert kein technisches Verständnis. Die KI hat dabei aber Spielraum. Sie kann entscheiden, ob ein Wort wirklich weggelassen werden muss oder ob es in einem bestimmten Satz die beste Wahl ist. Dieser Spielraum ist sowohl eine Stärke als auch eine Schwäche. Manchmal hält sich die KI daran, manchmal nicht. Und wenn sie sich zu genau daran hält, ersetzt sie ein normales Wort durch ein unpassendes Synonym.

Der Autor des Versuchs hat das in einem separaten Test mit einem anderen Modell geprüft. Er fügte eine Liste mit 93 verbotenen Wörtern in den Prompt ein. Fast alle Wörter wurden vermieden, aber in zwei von fünf Artikeln gingen Informationen verloren. Die KI hatte die Anweisung zu wörtlich genommen und dabei Fakten verändert oder weggelassen. Das zeigt: Ein Prompt ist eine Bitte, kein Hebel an der Maschine.

Nicht jede API kann das

Der nächste Punkt ist praktischer Natur. Nicht jedes KI-Modell unterstützt logit_bias. OpenAI erwähnt den Parameter zwar noch in der Dokumentation, aber die aktuellen Modelle lehnen ihn mit einer Fehlermeldung ab. Anthropic, der Hersteller von Claude, hat den Parameter erst gar nicht. Etwas besser sieht es bei OpenRouter aus, einer Art Sammel-Schnittstelle für viele Modelle. Dort gibt es eine Suche nach unterstützten Parametern, und der Autor fand 115 Modelle.

Auch das ist noch kein Grund zur Freude. Manche Anbieter listen den Parameter zwar, ignorieren ihn aber stillschweigend. Der Autor berichtet von einem Modell, das den Parameter akzeptierte, dann aber einen Wert von -100 einfach ignorierte. Man muss also vorher testen, ob der jeweilige Anbieter den Parameter tatsächlich verarbeitet. Im Experiment half es, einen bestimmten Provider festzulegen und Fallbacks zu deaktivieren. Selbst wenn der Parameter in der Modellliste steht, heißt das nicht, dass er überall funktioniert.

Der Selbstversuch: Acht Artikel, zwei Durchgänge

Der eigentliche Test war aufwendig. Der Autor nahm acht komplette KI-generierte Artikel und schickte sie durch das Modell DeepSeek V4 Flash. Jeder Artikel wurde zweimal bearbeitet: einmal ohne besonderen Filter, einmal mit einer Negativ-Bewertung von -8 für eine Liste auffälliger KI-Wörter. Die Aufgabe war immer dieselbe: Den Text bearbeiten, aber alle Fakten, Namen, Zahlen und Schlussfolgerungen beibehalten.

Das Ergebnis war eindeutig. In den Quelltexten kamen 264 Wörter aus der schwarzen Liste vor. In den gefilterten Versionen waren es noch 180. Der Filter entfernte also etwa ein Drittel der auffälligen Wörter. Aber er veränderte auch mehr am Text. Die Übereinstimmung zwischen Quelle und Bearbeitung war geringer, wenn der Filter aktiv war. Sieben der acht gefilterten Versionen blieben inhaltlich korrekt. Eine veränderte eine Entität und strich eine Absicherung – das ist ein Problem, weil dadurch eine vorsichtige Aussage zu einer falschen Gewissheit wurde.

Bei der Bewertung von Grammatik, Klarheit und Stil schnitten drei gefilterte Artikel besser ab als die Quelle, vier waren gleichwertig, einer war schlechter. Dieser eine enthielt Sätze wie „That details why…“, ein offensichtlicher Fehler, der durch den Wortfilter entstanden war. Am Ende bestanden sieben von acht ungefilterten Versionen den Qualitätscheck, aber nur sechs von acht gefilterten. Der Preis für weniger KI-Sprache war also ein verlorener Artikel.

Warum die KI dann dümmer wirkt

Interessant ist ein Nebeneffekt: Die KI wirkte mit Filter manchmal weniger intelligent. Nicht, weil sie weniger wusste, sondern weil ihr die passenden Wörter fehlten. Die schwarze Liste enthielt nur die Wörter, aber keine Hinweise darauf, was stattdessen besser wäre. Die KI musste improvisieren und griff dabei manchmal zu Konstruktionen, die ein Mensch so nicht schreiben würde.

Eine höhere Strafe half nicht weiter. Der Autor testete auch Werte von -4 und -12, aber der Effekt blieb uneinheitlich. Bei -100 verschwanden die Wörter zwar komplett, aber die KI begann, denselben Text immer wieder zu wiederholen. Ein zu starker Eingriff scheint das Gleichgewicht der Textproduktion zu stören. Die KI weiß nicht, warum ein Wort verboten ist, also kann sie nicht gezielt nach einer guten Alternative suchen.

Das ist der entscheidende Unterschied zwischen einer Anweisung im Prompt und einem Eingriff über logit_bias. Der Prompt hat Kontext. Er versteht, dass ein Wort in einer bestimmten Situation wichtig sein kann, auch wenn es auf der Liste steht. Die Zahlenkorrektur sieht nur den Token, nicht die Bedeutung. Sie ist stark, aber unempfindlich.

Was das für den Alltag bedeutet

Die Idee, KI-Texte allein durch das Verbannen bestimmter Wörter menschlicher zu machen, klingt verlockend. Der Versuch zeigt aber, wie fragil dieses Vorgehen ist. Die Wortwahl ist nur ein Teil des KI-Klangs. Rhythmus, Satzstruktur, Gedankensprünge und der Umgang mit Unsicherheit sind mindestens so wichtig. Ein Filter, der nur einzelne Wörter entfernt, behandelt das Symptom, nicht die Ursache.

Für die Praxis bedeutet das: Wer KI-Texte natürlicher machen will, sollte lieber in die Prompt-Formulierung investieren und dem Modell erklären, wann welche Formulierungen angemessen sind. Danach gehört eine manuelle Überarbeitung dazu. Das ist weniger aufregend als ein API-Trick, aber es liefert verlässlichere Ergebnisse. Der Autor räumt selbst ein, dass logit_bias ein Werkzeug für bestimmte Fälle ist – nicht mehr und nicht weniger. Es kann gezielt verhindern, dass ein bestimmtes Token erscheint, aber es kann nicht entscheiden, was stattdessen richtig ist. Diese Entscheidung bleibt weiterhin eine menschliche Aufgabe.

Quelle: vincentschmalbach.com

Stell dir vor, du hast eine KI, die Videos versteht und generiert. Du gibst ihr ein Standbild und eine Anweisung, etwa: „Hier rollt ein Ball durch ein Hindernisparcours – wo landet er?“ Und die KI zeigt dir eine Animation. Oft funktioniert das erstaunlich gut. Aber manchmal liefert sie Unsinn. Sie lassen den Ball durch die Wand plumpsen oder übersehen das Ziel komplett. Was dann? Bei Sprachmodellen kennt man das Problem: Ein schlecht formulierter Prompt führt zu einer schlechten Antwort. Also verbessert man den Text. Doch was, wenn die Eingabe gar kein Text ist, sondern ein Bild? Eine neue Arbeit von Google DeepMind zeigt, dass man auch das Bild selbst „prompten“ kann – und das oft besser wirkt als jeder Text.

Prompt Engineering: Mehr als nur Worte

Seit einigen Jahren weiß man, dass die Qualität von KI-Antworten stark davon abhängt, wie man die Anfrage formuliert. Ein kurzer, vager Satz wie „Erkläre Quantenphysik“ führt zu einem anderen Ergebnis als eine präzise Anweisung mit Beispielen und Zielgruppe. Diese Praxis nennt man Prompt Engineering. Sie ist eine Kunst, die sich ausprobiert, verfeinert und manchmal in Formelsammlungen gegossen wird. Doch mit dem Aufkommen multimodaler Modelle, die nicht nur Text, sondern auch Bilder und Videos verarbeiten, stellt sich die Frage: Gibt es das Pendant für visuelle Eingaben? Genau hier setzt die Forschung von Google DeepMind an.

Die Wissenschaftler nennen ihren Ansatz „Visual Prompt Engineering“ oder kurz VIPE. Die Idee ist bestechend einfach: Wenn ein Video-Modell Schwierigkeiten mit einem Eingabebild hat, dann verändert man eben das Bild, bevor man es der KI gibt. Das kann eine radikale Stiländerung sein, etwa von einer abstrakten Skizze zu einer fotorealistischen Szene. Es kann aber auch eine subtile Anpassung sein, wie das Hinzufügen einer dicken Kontur oder das Ändern des Hintergrunds. Das Entscheidende ist: Man bleibt in der visuellen Domäne, man tippt keine neuen Anweisungen ein, sondern manipuliert das Bild selbst.

Wie VIPE funktioniert

Die Methode ist verblüffend unkompliziert. Man nimmt das ursprüngliche Aufgabenbild und lässt es von einem Bildbearbeitungsmodell umwandeln. Solche Modelle sind inzwischen so gut, dass sie aus einer einfachen Strichzeichnung eine plausible Fotografie erzeugen können, ohne die zugrunde liegende Struktur zu verändern. Man kann auch gezielter vorgehen: Statt das ganze Bild neu zu gestalten, editieren die Forscher einzelne Konzepte. Sie ersetzen etwa die flache Farbe eines Kreises durch eine glänzende 3D-Oberfläche oder entfernen die Sättigung aller nicht relevanten Objekte. Diese feinen Eingriffe nennen sie „Atomic Concept Edit“.

Die Wahl der Transformation ist nicht willkürlich. Die Forscher testen mehrere Varianten und schauen, welche die besten Ergebnisse liefert. Das erinnert ein wenig an das Ausprobieren verschiedener Textprompts – nur eben im Bildraum. Und hier zeigt sich eine interessante Beobachtung: Oft reicht es nicht, das Bild einfach „schöner“ zu machen. Die Transformation muss zur Aufgabe passen. Bei einer Physik-Aufgabe, bei der ein Ball durch Rampen rollt, hilft ein fotorealistischer Industriehallen-Stil mehr als eine bunte Candy-Landschaft. Bei einem Puzzle, bei dem Punkte verbunden werden sollen, sorgt eine dicke schwarze Kontur um die Punkte für den entscheidenden Unterschied.

Sechs Aufgaben, sechs Erfolge

Die Forscher haben ihr Verfahren an sechs verschiedenen Aufgaben getestet. Da ist zuerst die Physik-Aufgabe: Ein Ball rollt über Rampen und soll in einem von drei Eimern landen. Das Originalbild, eine abstrakte Skizze, führt oft zu Fehlern. Wird dasselbe Bild in eine fotorealistische Förderanlage verwandelt, gelingt die Vorhersage deutlich besser. Ähnlich sieht es bei der Suche nach einem Objekt aus, das gleichzeitig eine bestimmte Form und Farbe haben muss. Hier hilft es, die relevanten Kreise in glänzende 3D-Kugeln zu verwandeln – so stechen sie für das Modell klar hervor.

Auch bei einfachen Denksportaufgaben wie „Verbinde gleichfarbige Punkte“ oder „Sortiere drei Zahlen“ wendet sich das Blatt. Ein minimalistisches Bild mit flachen Kreisen wird zum Stolperstein. Derselbe Bildinhalt, aber als Tafel mit Kreidepunkten oder als Retro-Arcade-Sprites, bringt das Modell auf die richtige Spur. Selbst beim Labyrinth-Lösen, einer Aufgabe, die ein hohes Maß an räumlichem Verständnis erfordert, kann eine Umwandlung in eine „klassische 2D-Arcade-Szene“ die Erfolgsquote erheblich steigern. Und beim Rush-Hour-Puzzle, bei dem ein rotes Auto aus einem Stau herausgefahren werden muss, zeigt sich ein ähnliches Muster.

Das Bemerkenswerte an diesen Ergebnissen ist nicht, dass alle Aufgaben perfekt gelöst werden. Es gibt weiterhin Fehler und Schwächen. Aber die Verbesserung ist systematisch und reproduzierbar. Die Forscher zeigen für jede Aufgabe mehrere Varianten, die alle zum Erfolg führen. Das ist ein starkes Indiz dafür, dass der Effekt kein Zufall ist, sondern eine grundlegende Eigenschaft von Video-Modellen widerspiegelt.

Warum dieser Ansatz so überraschend wirkt

Man sollte meinen, dass ein Video-Modell, das auf riesigen Datenmengen trainiert wurde, auch mit abstrakten Skizzen umgehen kann. Schließlich sehen Modelle während des Trainings Millionen von Bildern, auch Diagrammen und Zeichnungen. Doch die Realität sieht anders aus. Offenbar sind diese Modelle auf „natürliche“ visuelle Eingaben spezialisiert, also auf Fotos oder realistische Szenen. Abstrakte Darstellungen fallen aus ihrer Verteilung heraus und führen zu unsinnigen Vorhersagen. Indem man das Bild in einen vertrauten Stil übersetzt, holt man das Modell sozusagen in seine Komfortzone zurück.

Interessanterweise ist dieser Effekt stärker als die Optimierung des Textprompts. Das bedeutet: Die visuelle Eingabe trägt mehr zur Lösung einer visuellen Aufgabe bei als die sprachliche Beschreibung. Das ist eine wichtige Erkenntnis für alle, die mit Video-KI arbeiten. Es reicht nicht, eine detaillierte Textanweisung zu formulieren. Das Bild muss zur Aufgabe passen. Für die Praxis heißt das: Nutzer können ihre Ergebnisse verbessern, ohne das Modell zu verändern oder teure Rechenressourcen zu erhöhen. Ein einfacher Bild-Edit kann mehr bewirken als ein längerer Prompt oder mehr „Denkzeit“ des Modells.

Ein weiterer überraschender Punkt ist, dass die besten visuellen Transformationen nicht unbedingt die aufwendigsten sind. Ein schlichter Hintergrundwechsel von Weiß auf Schwarz oder das Hinzufügen einer dicken Kontur reicht manchmal aus, um das Modell auf die richtige Lösung zu bringen. Das spricht dafür, dass Video-Modelle stark auf visuelle Kontraste und klare Kanten reagieren. Sie scheinen Objekte besser zu „verstehen“, wenn diese deutlich abgegrenzt und mit einer satten Farbe oder einer 3D-Oberfläche versehen sind.

Eine Brücke zwischen Bild und Verständnis

Man kann sich das Ganze wie eine Übersetzung vorstellen. Das Modell spricht eine Sprache, die auf fotorealistischen Bildern beruht. Eine abstrakte Skizze ist für es wie eine Fremdsprache – es erkennt zwar einzelne Elemente, aber die Grammatik, also die physikalischen Gesetze und Beziehungen zwischen den Objekten, geht verloren. Visual Prompt Engineering übersetzt das Bild in die Muttersprache des Modells. Auf diese Weise kann die KI ihr gesamtes Wissen über Physik, Objekte und deren Interaktion nutzen, das sie aus unzähligen Videos gelernt hat.

Diese Perspektive macht auch deutlich, warum die Methode so effektiv ist. Video-Modelle sind darauf trainiert, die Welt in Bewegung zu verstehen. Sie haben gelernt, dass Bälle auf Rampen rollen, dass Autos sich durch Verkehr schlängeln und dass Zahlen sortiert werden können. Aber dieses Wissen ist eng mit dem visuellen Erscheinungsbild verknüpft. Wenn man ein Bild präsentiert, das wie ein abstraktes Diagramm aussieht, kann das Modell die Verbindung zu seiner Wissensbasis nicht herstellen. Die Transformation schafft diese Verbindung.

Natürlich hat die Methode auch Grenzen. Nicht jede Aufgabenstellung lässt sich durch eine einfache Bildtransformation verbessern. Die Forscher räumen ein, dass die Wahl der richtigen Transformation Erfahrung und Ausprobieren erfordert. Man weiß nicht immer im Voraus, welche Stiländerung dem Modell helfen wird. Und nicht jede Transformation ist neutral – man muss aufpassen, dass man nicht versehentlich wichtige Informationen im Bild verändert. Aber gerade die Kombination aus freier Stilwahl und gezielten Konzept-Editionen bietet einen flexiblen Werkzeugkasten.

Was bedeutet das für dich?

Wenn du selbst mit Video-Modellen experimentierst, also etwa mit KI-generierten Clips oder visuellen Reasoning-Aufgaben, dann nimm dir diesen Gedanken mit: Das Aussehen des Eingabebildes ist ein Teil des Prompts. Du solltest es genauso sorgfältig gestalten wie deine Textanweisung. Stelle dir Fragen: Ist das Bild klar? Heben sich die relevanten Objekte genug ab? Entspricht der Stil dem, was das Modell wahrscheinlich aus Videos kennt? Wenn dein Modell scheitert, versuche nicht nur, den Text zu ändern, sondern auch das Bild.

Diese Erkenntnis ist ein weiteres Puzzlestück im Verständnis von KI-Systemen. Sie zeigt, dass multimodale Modelle nicht einfach „alles sehen“, sondern dass sie auf bestimmte visuelle Muster angewiesen sind. Für Entwickler und Anwender ist das eine wertvolle Heuristik. Statt in Testzeit-Rechenleistung zu investieren, kann man mit einem einfachen Bild-Edit oft mehr erreichen. Das senkt die Kosten und macht KI zugänglicher.

Die Forschung von Google DeepMind trägt damit zu einer pragmatischen Sicht auf KI bei. Es geht nicht darum, Modelle unfehlbar zu machen, sondern darum, sie besser zu nutzen. Visual Prompt Engineering ist ein Werkzeug, das uns hilft, die Fähigkeiten bestehender Systeme voll auszuschöpfen. Und das ist vielleicht die wichtigste Botschaft: Die Zukunft der KI liegt nicht nur in größeren Modellen, sondern auch in klügeren Interaktionen. Das Bild, das du der KI zeigst, ist Teil der Botschaft. Gestalte es weise.

Quelle: visual-prompt-engineering.github.io

Stell dir vor, du hast eine Software entwickelt, die in der Cloud läuft. Alles schön zentral, alles einfach. Dann kommt ein Kunde und sagt: „Wir möchten eure Lösung bei uns im Rechenzentrum betreiben, komplett isoliert vom Internet.“ Plötzlich wird aus einem vertrauten Thema – Authentifizierung – ein komplexes Geflecht aus Identitätsprovidern, SCIM-Syncs und Session-Validierung. Und das alles unter den strengen Sicherheitsrichtlinien des Kunden.

Genau mit dieser Situation beschäftigt sich der Artikel, der auf dem Blog von PropelAuth erschienen ist. Er erklärt, wie man eine On-Premises-fähige Authentifizierung aufbaut, die vollständig im Netzwerk des Kunden lebt. Der Kern der Idee: Die Auth-Logik gehört direkt neben die Anwendung, nicht in eine entfernte Cloud.

Warum klassische Auth-as-a-Service-Modelle scheitern

Wer Software verkauft, die in der Umgebung des Kunden läuft, stößt schnell an Grenzen. Übliche Authentifizierungsdienste wie Auth0, Cognito oder auch Firebase senden Login-Anfragen, Session-Validierungen und Token-Aktualisierungen an externe Server. Das ist in der Cloud kein Problem. In einem abgeschotteten Rechenzentrum sieht das anders aus: Daten dürfen das Netzwerk nicht verlassen, externe API-Aufrufe sind blockiert oder stark eingeschränkt, und der Kunde hat oft einen eigenen Identity Provider (IdP) wie Okta, Microsoft Entra oder OneLogin.

Der Kunde möchte, dass sich seine Mitarbeiter mit den gewohnten Zugangsdaten anmelden. Er möchte, dass Benutzerkonten automatisch bereitgestellt und deaktiviert werden, wenn jemand das Unternehmen verlässt. Und er möchte, dass all das ohne den Umweg über eine externe Plattform funktioniert. Genau hier brechen herkömmliche Auth-Dienste zusammen, weil sie oft zwingend eine Verbindung nach außen benötigen.

Die Lösung: Auth als Sidecar neben der Anwendung

Die Idee ist bestechend einfach: Statt die Authentifizierung in die Cloud auszulagern, setzt man sie als eigenen Prozess direkt neben die eigentliche Anwendung. Dieses „Sidecar“ übernimmt Login, Session-Verwaltung und die Anbindung an den Identity Provider des Kunden. Es läuft komplett im Kundennetzwerk, speichert Daten in einer lokalen Datenbank und kommuniziert nie nach außen.

Das erinnert an einen Türsteher, der direkt vor der Tür steht, anstatt per Videoanruf von einem entfernten Standort zugeschaltet zu sein. Der Türsteher sieht, wer kommt, kann Ausweise prüfen und entscheiden – und das alles, ohne die Daten an eine Zentrale schicken zu müssen. Genau so funktioniert das Konzept, das PropelAuth mit seinem „BYO“-Angebot (Bring Your Own Auth) umsetzt.

PropelAuth BYO ist ein selbstgehosteter Authentifizierungs-Sidecar, der in Rust geschrieben wurde. Er ist bewusst schlank gehalten: nur eine Abhängigkeit (Postgres), detailliertes JSON-Logging für Audits und SDKs für alle gängigen Programmiersprachen. Das macht ihn für Kunden einfach zu betreiben und für Entwickler einfach zu integrieren.

Der Bootstrap: Wie richtet man SSO ein, bevor es Benutzer gibt?

Ein klassisches Henne-Ei-Problem: Um sich anzumelden, braucht man eine SSO-Konfiguration. Aber um eine SSO-Konfiguration zu erstellen, muss sich ein Administrator anmelden. Der Artikel schlägt dafür einen einfachen Weg vor: einen temporären Endpunkt, der mit einem geheimen Schlüssel geschützt ist. Der Admin setzt beim ersten Start ein Passwort als Umgebungsvariable und kann damit eine Setup-Seite aufrufen. Dort werden die Verbindungsdaten zum IdP des Kunden eingegeben – zum Beispiel die OIDC-URL, die Client-ID und das Client-Secret.

Erst wenn dieser Schritt abgeschlossen ist, wird der Zugang über den SSO-Flow freigeschaltet. Das klingt banal, ist aber ein entscheidender Baustein für eine reibungslose Inbetriebnahme. Ohne dieses Bootstrap-Verfahren müsste man entweder einen initialen Admin manuell anlegen oder auf einen externen Dienst zurückgreifen – beides ist in einer restriktiven On-Premises-Umgebung unpraktisch.

Der SSO-Login: Initiieren, weiterleiten, zurückkommen

Der eigentliche Login läuft in zwei Schritten ab. Zuerst leitet die Anwendung den Benutzer zum Identity Provider weiter. Dort gibt der Benutzer seine Zugangsdaten ein und wird anschließend mit einem Autorisierungscode zurückgeschickt. Die Anwendung tauscht diesen Code gegen eine Session aus – und zwar vollständig im lokalen Netzwerk.

Das Besondere an dieser On-Premises-Architektur: Man muss sich nicht um die Zuordnung zu einer Organisation kümmern. In einer Cloud-Multi-Tenant-Umgebung muss das System wissen, welcher Kunde zu welchem IdP gehört. Im Rechenzentrum des Kunden ist das eindeutig – es gibt nur eine Organisation, nur einen IdP. Der Code wird dadurch deutlich einfacher.

Sessions: Sicher eingeloggt bleiben, ohne den IdP zu belasten

Nach dem Login entsteht eine Session. Diese erlaubt es dem Benutzer, über einen längeren Zeitraum eingeloggt zu bleiben, ohne bei jeder Anfrage den Identity Provider kontaktieren zu müssen. Die Session wird lokal gespeichert und validiert. Die Anwendung schützt damit ihre Routen: Wer keine gültige Session hat, wird zum Login weitergeleitet. Wer sich abmeldet, dessen Session wird sofort ungültig.

Die Laufzeit und die Rotation solcher Sessions lassen sich je nach Kundenwunsch konfigurieren. Manche Kunden möchten kurze Sessions für Administratoren, längere für normale Benutzer. Andere legen Wert auf eine Begrenzung auf bestimmte IP-Bereiche. All das lässt sich in dieser Sidecar-Architektur abbilden, ohne dass ein externer Dienst angezapft werden muss.

SCIM: Automatische Benutzersynchronisierung

Ein weiteres Puzzlestück ist die Bereitstellung von Benutzerkonten. In Unternehmen wird heute erwartet, dass neue Mitarbeiter automatisch Zugang erhalten und ausscheidende Mitarbeiter sofort gesperrt werden. Dafür gibt es SCIM (System for Cross-domain Identity Management). Der Identity Provider des Kunden sendet dabei Ereignisse wie „Benutzer angelegt“, „Benutzer deaktiviert“ oder „Gruppe geändert“ an die Anwendung.

PropelAuth übernimmt das Parsen dieser SCIM-Requests. Der Integrator muss lediglich einen einzigen Wildcard-Endpunkt bereitstellen, der die eingehenden Daten an den Sidecar weiterreicht. Für jede Aktion wie Anlegen oder Deaktivieren muss die Anwendung den Erhalt bestätigen. Dadurch bleibt der Datenbestand konsistent – ganz ohne Webhook-Konfiguration und ohne Synchronisation über Netzwerkgrenzen hinweg.

Der Artikel weist darauf hin, dass diese Einrichtung in nur etwa 200 Zeilen Code resultiert. Das ist bemerkenswert wenig, wenn man bedenkt, was dahintersteckt: SSO-Flows, Session-Verwaltung, SCIM-Provisioning und die Integration in das eigene Produkt. Der Grund dafür ist, dass der Sidecar die komplexen Protokolle kapselt und nur eine schlanke API nach außen bietet.

Was diese Architektur für die Praxis bedeutet

Für Software-Anbieter, die ihren Kunden eine On-Premises-Option anbieten möchten, ist dieser Ansatz eine echte Alternative. Statt ein halbes Dutzend verschiedener Authentifizierungsmethoden zu pflegen, integriert man einmalig ein System, das mit jedem OIDC-kompatiblen Identity Provider funktioniert. Ob Okta, Microsoft Entra oder ein kleineres Produkt – die Codebasis bleibt gleich.

Auch unter Compliance-Gesichtspunkten hat das Konzept Vorteile. Sämtliche Authentifizierungsdaten liegen in der Postgres-Datenbank des Kunden. Die JSON-Logs erlauben lückenlose Audits. Keine externen Abhängigkeiten, keine Datenabflüsse, keine versteckten Cloud-Aufrufe. Das schafft Vertrauen – gerade bei Kunden aus regulierten Branchen wie Finanzen, Gesundheit oder öffentlicher Verwaltung.

Natürlich gibt es auch Grenzen. Der Betrieb eines solchen Sidecars erfordert auf Kundenseite eine gewisse Infrastruktur-Kompetenz. Die Verantwortung für Updates und Sicherheit verschiebt sich teilweise in die Verantwortung des Kunden. Doch genau das ist der Preis für die vollständige Kontrolle über die eigene Datenhoheit.

Ein pragmatischer Weg in eine dezentrale Auth-Zukunft

Die zunehmende Nachfrage nach On-Premises-Lösungen zeigt, dass nicht jedes Unternehmen seine Identitätsinfrastruktur in die Cloud verlagern möchte. Der Ansatz von PropelAuth BYO ist ein Beispiel dafür, wie man Authentifizierung für diese Welt baut: nicht als Ferndienst, sondern als lokalen Prozess. Die Integration ist dank klarer SDKs und einfacher Konzepte gut machbar – für Entwickler, die sich bereits mit Auth beschäftigt haben, ist der Umstieg vertraut.

Für alle, die vor ähnlichen Anforderungen stehen, lohnt sich ein Blick auf diese Architektur. Sie zeigt, dass On-Premises-Auth kein Hexenwerk sein muss. Man muss nur bereit sein, die Auth-Logik dorthin zu bringen, wo sie hingehört: direkt an den Ort, an dem die Daten leben.

Quelle: byo.propelauth.com

In seinem Artikel „Using DPoP to Prevent Session Theft“ beschäftigt sich der Autor mit einer Frage, die viele Webentwickler umtreibt: Was passiert, wenn ein Angreifer das Session-Token eines Nutzers stiehlt? Das ist kein hypothetisches Szenario – gestohlene Session-Tokens gehören zu den gängigsten Angriffsmethoden. Der Autor zeigt, wie eine OAuth-Erweiterung namens DPoP dieses Problem entschärfen kann.

Stell dir vor, du gibst jemandem eine Kopie deines Haustürschlüssels. Solange der Schlüssel funktioniert, kann der Eindringling kommen und gehen, wann er will. Du könntest das Schloss austauschen, aber das hilft erst, nachdem du den Diebstahl bemerkt hast. Ähnlich sieht es bei Session-Tokens aus: Wer den Token besitzt, kann sich als der eingeloggte Nutzer ausgeben – und zwar so lange, bis der Token abläuft oder invalidiert wird. Genau hier setzt DPoP an.

Die Grundidee: Kein Token allein, sondern ein Schlüsselbeweis

Der Kern von DPoP ist erstaunlich einfach. Statt sich nur auf den Session-Token zu verlassen, wird ein Schlüsselpaar aus öffentlichem und privatem Schlüssel erzeugt. Der öffentliche Schlüssel wird bei der Anmeldung an die Session gebunden. Bei jeder Anfrage muss der Client eine Signatur mitschicken, die mit dem privaten Schlüssel erzeugt wurde. Der Server prüft dann nicht nur den Session-Token, sondern auch, ob die Signatur zu dem hinterlegten öffentlichen Schlüssel passt.

Warum das funktioniert? Der private Schlüssel ist das entscheidende Geheimnis. Wer nur den Token stiehlt, hat noch keinen Zugriff, denn die Signatur fehlt. Ein Angreifer müsste also sowohl den Token als auch den privaten Schlüssel in die Hand bekommen. Genau das macht den Angriff deutlich schwerer.

Eine naheliegende Frage: Warum stiehlt der Angreifer nicht einfach den privaten Schlüssel mit? Der Autor verweist auf einen entscheidenden Unterschied: Private Schlüssel können in einer Umgebung gespeichert werden, die sie vor unerlaubtem Export schützt. Die WebCrypto-API in Browsern bietet zum Beispiel die Möglichkeit, Schlüssel als „nicht extrahierbar“ zu erzeugen. Das bedeutet, dass der Code im Browser zwar den Schlüssel zum Signieren nutzen kann, aber nicht an den eigentlichen Wert des Schlüssels herankommt. Eine bösartige Chrome-Erweiterung kann zwar Cookies, LocalStorage oder Speicherinhalte auslesen, aber nicht den privaten Schlüssel selbst. Sie könnte den Schlüssel höchstens benutzen, solange die Erweiterung aktiv ist. Nachdem sie entfernt wurde, sind alle von ihr signierten Daten wertlos – ein großer Unterschied zu gestohlenen Tokens, die oft noch tagelang gültig bleiben.

Was genau wird signiert?

Damit der Server die Signatur sinnvoll prüfen kann, muss klar sein, welche Daten signiert werden. Der Autor erläutert ein JWT-basiertes Format mit mehreren Feldern, die jeweils eine bestimmte Sicherheitsanforderung abdecken.

iat ist der Zeitstempel der Signatur. Er begrenzt die Gültigkeitsdauer der Signatur, weil der Server nur Anfragen akzeptiert, die innerhalb eines kurzen Zeitfensters erstellt wurden. jti ist eine zufällig generierte, eindeutige ID pro Anfrage. Der Server merkt sich alle kürzlich verwendeten jti-Werte und lehnt Wiederholungen ab – so werden Replay-Angriffe verhindert. htm und htu sind die HTTP-Methode und die URL. Damit ist die Signatur fest an eine bestimmte Anfrage gebunden. Eine abgefangene Signatur lässt sich nicht auf einen anderen Endpunkt oder eine andere Methode übertragen.

Besonders wichtig ist ath – der Hash des Session-Tokens. Der Autor weist darauf hin, dass dieses Feld in der OAuth-Welt eigentlich verpflichtend ist, sobald ein Tokens existiert. Er selbst vereinfachte das etwas: In manchen Browser-Szenarien ist es nicht trivial, an den Session-Token heranzukommen, etwa wenn ein HttpOnly-Cookie verwendet wird. Dann kann man auf das Feld verzichten, auch wenn das die Sicherheit etwas reduziert.

Und dann gibt es noch das nonce – eine zufällige Zeichenkette, die der Server vorgibt. Sie ist technisch optional, aber aus Sicht des Autors eines der mächtigsten Werkzeuge in DPoP. Stellen wir uns vor, ein Angreifer hat sich per XSS in die Seite eingeschlichen und kann mit dem privaten Schlüssel signieren. Ohne nonce kann er sich signierte Payloads für die Zukunft zurechtlegen. Mit nonce kann der Server jedoch plötzlich neue Nonces ausgeben und damit alle vorab generierten Signaturen wertlos machen. Der Server hat also eine Art Fernbedienung, um Anfragen aus der Vergangenheit zu invalidieren.

Die stillen Stärken von DPoP

Die Kombination dieser Felder ergibt eine starke Verkettung: Jede Signatur ist kurzlebig, an einen konkreten Request gebunden, gegen Wiederverwendung geschützt und an einen nicht exportierbaren Schlüssel gekoppelt. Der Autor nennt noch einen weiteren Vorteil: DPoP löst elegant das Problem mit wechselnden IP-Adressen. Viele Session-Management-Richtlinien versuchen, Sessions an die IP-Adresse zu binden. Aber wechselt die IP, weil der Nutzer ins Café zieht oder unterwegs ist, kann das zu Fehlern führen. Der Autor schlägt deshalb vor, die nonce an IP-Adressen oder andere Risikofaktoren zu koppeln.

Die Idee dahinter: Kommt eine Anfrage von einer neuen IP, schickt der Server eine Fehlermeldung mit einer neuen nonce zurück. Diese nonce ist an die neue IP gebunden. Der Client – also das JavaScript im Browser – erzeugt im Hintergrund eine neue Signatur und schickt die Anfrage erneut. Die Anfrage funktioniert, vorausgesetzt, der Client besitzt den privaten Schlüssel. Für den Nutzer ist dieser Austausch unsichtbar. So entsteht ein leichter, stiller Challenge-Mechanismus, den der Server so oft auslösen kann, wie er will – ohne den Nutzer zu stören. Das ist deutlich praktischer als eine Zwei-Faktor-Abfrage.

Wo die Methode an ihre Grenzen stößt

DPoP ist kein Allheilmittel. Der Autor benennt zwei wesentliche Einschränkungen. Erstens kann DPoP nicht vor Cross-Site-Scripting schützen. Wenn ein Angreifer Code in der Seite ausführen kann, hat er auch Zugriff auf den Signiermechanismus des privaten Schlüssels. Er kann dann selbst signierte Anfragen absetzen. Allerdings hilft DPoP nach der Beseitigung der XSS-Schwachstelle: Da neue nonces ausgegeben werden, sind alle vom Angreifer gesammelten Daten wertlos. XSS muss also trotzdem separat bekämpft werden – die OWASP-Cheat-Sheets geben dafür hilfreiche Empfehlungen.

Zweitens setzt DPoP JavaScript voraus. Bei Server-Side-Rendering werden Daten oft geladen, bevor JavaScript ausgeführt wird. Diese initialen Datenabrufe kann man nicht mit DPoP schützen. Der Autor merkt aber an, dass man nicht jede Anfrage absichern muss. Für kritische Mutationen, die im Browser per fetch laufen, funktioniert DPoP problemlos. Man muss also abwägen, welche Requests den zusätzlichen Schutz wirklich brauchen.

Fazit: Ein zusätzliches Werkzeug, kein Wundermittel

Der Autor bleibt am Ende geerdet: DPoP ist eine sinnvolle Erweiterung für alle, die ihre Sessions besser gegen Diebstahl absichern wollen. Es bindet das Session-Token an einen privaten Schlüssel, der im Browser sicher aufbewahrt wird. Damit wird ein gestohlener Token allein nutzlos. Für Angreifer wird es deutlich aufwendiger, beide Geheimnisse zu stehlen. Wer DPoP umsetzt, sollte die Details der OAuth-Spezifikation kennen – der Artikel vereinfacht bewusst einige Punkte, insbesondere im Umgang mit dem ath-Feld und beim Zugriff auf HttpOnly-Cookies. In der Praxis gilt: DPoP ersetzt keine andere Sicherheitsmaßnahme, aber es ergänzt sie gut. Und genau diese zusätzliche Schutzschicht kann im Ernstfall den Unterschied machen.

Quelle: byo.propelauth.com