Kategorie: Erklärer

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

Stell dir vor, du bekommst einen neuen Kollegen in deinem Team. Du übergibst ihm ein Handbuch, das aus früheren Jahren stammt: lang, voller überflüssiger Regeln, und ein paar Anweisungen widersprechen sich sogar. Was wird passieren? Er orientiert sich an den veralteten Details, statt sich auf die eigentliche Arbeit zu konzentrieren. Genauso geht es KI-Agenten, wenn ihr „Einarbeitungshandbuch“ – also der System-Prompt und die Tool-Beschreibungen – nicht zur aktuellen Modellgeneration passt. Das LangChain-Team hat daraus die Konsequenz gezogen und Deep Agents in Version 0.7 veröffentlicht. Die zentrale Botschaft: weniger Basis-Input-Tokens, gleiche Leistung, mehr Konfigurierbarkeit.

Doch was bedeutet das konkret? Wer mit KI-Agenten arbeitet, weiß: Ein Modell ist nur so gut wie der Kontext, den es bekommt. Und dieser Kontext entsteht fast vollständig durch den Prompt, den der Harness – also das Rahmenwerk, das den Agenten steuert – zusammenbaut. Der Harness entscheidet, welche Anweisungen, Tool-Beschreibungen und Middleware-Komponenten am Ende im Kontext landen. Lange Zeit galt: Je mehr geschickte Prompt-Formulierungen, desto besser. OpenAI, Anthropic und Google veröffentlichen regelmäßig ihre eigenen Prompting-Guides und haben sie mehrfach überarbeitet, weil die Modelle immer leistungsfähiger wurden. Ein Harness, der nicht mitzieht, schleppt dann Formulierungen mit sich herum, die das Modell längst überholt hat. Genau das hat das LangChain-Team beobachtet.

Die Lösung heißt Kontext-Engineering. Anthropic hat vor Kurzem einen aktualisierten Leitfaden dazu veröffentlicht. Dabei zeigte sich ein bemerkenswerter Effekt: Bei Modellen wie Opus 5 und Fable 5 konnte der System-Prompt von Claude Code um über 80 Prozent gekürzt werden, ohne dass die Ergebnisse bei den Coding-Evals nachließen. Zwei zentrale Erkenntnisse daraus sind auch in Deep Agents v0.7 eingeflossen. Erstens: Gut formulierte Tool-Schemas lehren die Bedienung besser als früher beliebte Few-Shot-Beispiele. Solche Beispiele schränken die Erkundung des Modells eher ein, als dass sie helfen. Zweitens: Wiederholungen bringen nichts. Wenn eine Anweisung sowohl im System-Prompt als auch in der Tool-Beschreibung steht, verstärkt sie das nicht – es verschwendet nur Tokens. Diese Einsichten mag man für banal halten, aber sie führen zu einer der größten strukturellen Änderungen in Deep Agents seit Langem: Der Basis-Harness ist um 65 Prozent schlanker geworden.

So wurde der Harness abgespeckt

Das Team hat eine klare Hypothese aufgestellt: Wenn man unnötige Tokens aus dem Basis-Input-Prompt entfernt, steigt die Token- und Kosteneffizienz, während die Leistung stabil bleibt. Um das zu testen, haben sie drei Änderungen vorgenommen. Zuerst wurde der System-Prompt entfernt, der bisher im Hintergrund von Deep Agents verwendet wurde. Er enthielt allgemeine Richtlinien und ausführliche Tool-Erklärungen. Zweitens wurden die Beschreibungen der eingebauten Tools um 43 Prozent gekürzt. Drittens ist die TodoList-Middleware jetzt optional: Der Befehl create_deep_agent aktiviert sie nicht mehr standardmäßig. Die Evals zeigten, dass der Planungs-Prompt und das Tool write_todos keine signifikante Leistungsverbesserung brachten. Zusammengenommen reduzieren diese Änderungen die Basis-Input-Tokens bei einem Standard-Agenten von etwa 6.000 auf rund 2.000 Tokens – also um 65 Prozent. Unter Basis-Input-Tokens versteht man die Tokens, die durch den eingebauten Prompt, die Tools und die Middleware entstehen, bevor irgendeine echte Aufgabe überhaupt beginnt.

Man kann sich das so vorstellen wie den Motor eines Autos. Wenn du einen V8-Motor einbaust, der aber ständig falsches Öl bekommt, verbraucht er unnötig Sprit. Entfernst du das falsche Öl und stellst die Zündung richtig ein, leistet der Motor dasselbe – mit weniger Verbrauch. Genau das ist hier passiert. Die Modelle sind inzwischen so gut, dass sie keine ausführlichen, redundanten Anweisungen mehr brauchen, um zu verstehen, wie ein Agent arbeiten soll. Sie brauchen klare und knappe Werkzeuge, keine predigenden Texte.

Wie die Änderungen validiert wurden

Natürlich reicht es nicht, einfach etwas zu streichen. Das LangChain-Team hat eine neue Eval-Suite aufgebaut, die sich auf drei Kategorien von Benchmarks stützt. Autonome Aufgaben umfassen End-to-End-Arbeiten wie Code-Erstellung oder Datenanalyse. Konversationsaufgaben testen mehrstufige Dialoge mit einem simulierten Benutzer. Und Langzeitkontext-Aufgaben verlangen das Auffinden und Verarbeiten von Informationen aus langen Kontexten. Diese drei Kategorien bilden ab, wofür Deep Agents in der Praxis eingesetzt wird: als automatischer Code-Assistent, als Chat-Bot mit Werkzeugen und als Recherche-Werkzeug für große Dokumente.

Dabei haben sie den neuen v0.7-Harness gegen den alten v0.6.12 über eine Matrix aus allen drei Eval-Kategorien und vier verschiedenen Modellen laufen lassen: gpt-5.6-luna, gemini-3.6-flash, claude-sonnet-4-6 und claude-opus-4-8. Das Ergebnis: Die Rewards, also die Bewertungsmetriken für die Qualität der Agentenleistung, blieben insgesamt stabil. Gleichzeitig sanken die Token-Kosten meist. Besonders deutlich war der Rückgang bei gpt-5.6-luna: 34 Prozent weniger Tokens und 15 Prozent weniger Kosten, bei sogar 4 Prozent höherem Reward. Eine Ausnahme gab es: claude-sonnet-4-6 verzeichnete eine höhere Kostenbelastung, was die Analyse von LangSmith-Traces auf zwei besonders schwierige autonome Aufgaben zurückführte. Solche Ausreißer sind typisch, wenn man mit kleinen Benchmark-Sets arbeitet.

Wichtig ist die statistische Einordnung: Die Konfidenzintervalle der Rewards überlappen bei allen Modellen die Null, das heißt, die Leistungsänderung ist nicht signifikant. Bei den Tokens hingegen sehen die Forscher bei Luna und Opus einen statistisch klaren Rückgang, und Luna zeigt auch einen klaren Kostenvorteil. Womit wir beim Kern der Sache wären: Die Effizienzsteigerung ist messbar, das Risiko von Leistungseinbußen ist statistisch nicht nachweisbar. Das ist genau das, was man sich von einem Refactoring wünscht.

Der Status der Todo-Listen

Eine der auffälligsten Änderungen ist, dass die Todo-Listen nicht mehr automatisch aktiv sind. TodoListMiddleware ist jetzt opt-in. Die Evals über drei Kategorien und drei Modelle zeigten leicht bessere Rewards und niedrigere Kosten, wenn die Todo-Listen deaktiviert sind. Also haben die Entwickler das write_todos-Werkzeug aus dem Basis-Harness entfernt. Das klingt radikal, ist aber nachvollziehbar: Kleinere Modelle profitieren vielleicht davon, wenn sie einen expliziten Plan führen müssen, um nichts zu vergessen. Leistungsfähige Modelle erzeugen durch diese zusätzlichen Schritte aber eher unnötige Tokens und lenken sich selbst von der eigentlichen Aufgabe ab.

Dennoch gibt es drei Szenarien, in denen die Todo-Listen weiterhin sinnvoll sind. Erstens bei langen, mehrstufigen Aufgaben, in denen ein Agent über viele Runden hinweg einen klaren Plan braucht, um nicht den Faden zu verlieren. Zweitens bei weniger leistungsfähigen Modellen, die mehr Gerüst benötigen, um ein Problem sauber zu Ende zu arbeiten. Und drittens bei Benutzeroberflächen, wo ein sichtbarer Plan und Fortschritt fast genauso wichtig sind wie die eigentliche Ausführung. Für alle, die in einem dieser Szenarien stecken, ist das Aktivieren eine Zeile Code: middleware=[TodoListMiddleware()]. Die Entwickler appellieren damit an die Vernunft, nicht an die Mode: Wer die Funktion braucht, stellt sie ein; wer sie nicht braucht, spart Tokens.

Mehr Konfigurierbarkeit als oberstes Gebot

Die größte Bitte der Deep-Agents-Nutzer in den letzten sechs Monaten war nicht eine neue Funktion, sondern mehr Kontrolle. Sie wollten die FilesystemMiddleware übersteuern, die Schwellenwerte der SummarizationMiddleware anpassen und den Basis-Prompt global verändern. Bisher scheiterten alle Versuche an einer fehlenden Schnittstelle: Es gab keinen unterstützten Weg, den Standard-Harness anzupassen. In v0.7 ändert sich das gleich auf zwei Arten.

Erstens haben Nutzer die volle Kontrolle über ihre eigenen Prompts. Das Entfernen der versteckten Standard-Prompts hat einen angenehmen Nebeneffekt: Eigene Prompts werden wirkungsvoller, weil kein unsichtbarer Basis-Prompt mehr darunterliegt, der aufbläht oder im schlimmsten Fall sogar widerspricht. Zweitens ist das Übersteuern der Middleware jetzt erstklassig unterstützt. Wenn man eine Middleware-Instanz mit dem gleichen Namen wie eine Standard-Middleware übergibt, ersetzt sie diese – zusätzliche Fehlermeldung gibt es nicht mehr. Ein Power-User beschrieb es treffend: „Früher mussten wir ein paar Tricks anwenden, um Standard-Middleware zu entfernen. Dass wir sie jetzt einfach übersteuern können, ist eine sehr willkommene Ergänzung.“

Ein gutes Beispiel ist die SummarizationMiddleware. In der Voreinstellung greift sie, sobald ein Gespräch 85 Prozent des Kontextfensters erreicht, mit einem generischen Zusammenfassungs-Prompt. Für viele Anwendungen ist das zu starr. Manche Applikationen brauchen eine spezifischere Zusammenfassung, andere wollen früher eingreifen, um dem sogenannten „Dumb-Zone-Effekt“ vorzubeugen – der Zone, in der das Modell trotz noch offenem Kontextfenster schlechter wird, weil die relevanten Informationen in der Masse untergehen. Jetzt können Entwickler eine eigene Summarization-Middleware einbauen. Das gleiche Muster funktioniert für jede Standard-Komponente, etwa für die TTL-Werte des Prompt-Cachings. So entsteht ein Baukasten, den sich viele gewünscht haben.

Dateisystem-Optimierungen

Das Dateisystem ist das zentrale Kontext-Management von Deep Agents. Es ist die Umgebung, über die der Agent Zustand liest, schreibt und navigiert. Die Optimierungen in v0.7 stammen aus derselben Eval-Suite sowie aus Trajektorien-Analysen echter dcode-Nutzung – mit offenen und geschlossenen Modellen. Die Neuerungen sind praxisnah: write_file überschreibt jetzt eine bestehende Datei statt einen Fehler zu werfen. read_file gibt bei paginiertem Lesen die Gesamtzahl der Zeilen, die noch verbleibenden Zeilen und den nächsten Offset zurück. grep und glob liefern Teilergebnisse mit einem truncated-Flag, statt auf großen Verzeichnisbäumen hängen zu bleiben. Das grep-Tool hat außerdem eine Obergrenze von 1.000 Treffern, gestreamte Ausgabe und optionale Kontextzeilen. Diese Änderungen klingen unspektakulär, sind aber für reale Arbeit entscheidend: Agenten müssen robust auf großen Codebasen arbeiten, nicht nur in Spielzeug-Projekten.

Was sich konkret ändert – Breaking Changes

Mit der neuen Version kommen auch ein paar bewusste Bruchstellen. Die TodoListMiddleware ist nicht mehr standardmäßig aktiv – das ist die wichtigste. Wer sie braucht, aktiviert sie einfach. Zweitens wurde der Support für Backend-Factories entfernt, der bereits in v0.5 abgekündigt war; stattBackendProtocol-Instanzen sind jetzt die Norm. Andere Dateiformat- und Backend-Protokoll-Deprecations aus v0.5 sind ebenfalls entfernt. Drittens wurde das delete-Tool zur Standard-Liste der Dateisystem-Tools hinzugefügt. Das FilesystemMiddleware akzeptiert eine Tool-Auswahlliste, sodass man das Löschen deaktivieren kann, wenn man das Sicherheitsrisiko vermeiden will. Wer eine Migration plant, findet alle Details im Changelog – inklusive Notizen und einem Upgrade-Prompt für Coding-Agenten. Viele Projekte pflegen ein solches Prompt, um Agenten bei Versionswechseln zu helfen.

Was bedeutet das alles für dich? Wenn du Deep Agents einsetzt, wird dein nächster Upgrade-Schritt wahrscheinlich wehtun – aber nur kurz. Die entfernteren Kompatibilitätsschichten sind kein Verlust, sondern eine Einladung, den eigenen Stack zu modernisieren. Und wenn du ohnehin mit vielen Agenten arbeitest, sind 65 Prozent weniger Basis-Tokens ein Unterschied, der sich in der Kostenrechnung bemerkbar macht. Stell dir vor, du betreibst eine Plattform mit Millionen von Agent-Aufrufen pro Tag. Die Einsparungen sind enorm.

Die Botschaft der Release ist klar: Kontext-Engineering ist die neue Königsdisziplin. Ein Modell wird nicht durch möglichst viele Prompt-Tokens besser, sondern durch die richtigen – und durch die Fähigkeit, die Struktur an das jeweilige Modell anzupassen. Deep Agents v0.7 zeigt, wie ein schlanker, konfigurierbarer Harness aussieht. Kein Wunder, dass die Entwickler bei der Validierung weniger auf neue Features als auf vergleichbare Leistung und geringere Kosten geachtet haben. In einer Zeit, in der jeder Token zählt, ist das die richtige Priorität.

Klar ist aber auch: Es gibt keine Universallösung. Die Entscheidung, Todos abzuschalten, mag für moderne Hochleistungsmodelle richtig sein. Für ältere oder kleinere Modelle kann es dennoch weiterhin helfen, einen expliziten Plan zu führen. Das Schöne an Deep Agents v0.7 ist, dass diese Entscheidung jetzt beim Entwickler liegt, nicht im Rahmenwerk. Mehr Konfigurierbarkeit bedeutet mehr Verantwortung – und genau das zeichnet eine reife Software aus. Wenn du dir also die Frage stellst, wie viel Prompt ein Agent wirklich braucht, lautet die Antwort aus dieser Version: Weniger, als du denkst – aber mit der Freiheit, genau das nachzujustieren. Das ist geerdete, ehrliche Ingenieursarbeit.

Quelle: langchain.com

Ein IT-Administrator betreibt eine Flotte von Windows-Geräten. BitLocker, Secure Boot und Code Integrity sind aktiv, Intune zeigt grün. Dann kommt ein Dienstag im Juli. Eine neue Build wird ausgerollt. Intune meldet für zahlreiche Geräte: „Noncompliant“. Drei rote Fehler, alle mit dem Code 2016345708. Was ist passiert? Die Geräte wurden nicht gehackt, sie haben keine Sicherheitslücke. Sie sind immer noch genauso geschützt wie vor dem Update. Aber Intune sieht das anders. Das liegt an einem unsichtbaren Mechanismus im Hintergrund: Wenn der Ausweis nicht mehr passt, kommt keiner rein.

Ein Beitrag auf PatchMyPC hat das Problem beschrieben. Auslöser war ein Reddit-Post, der vielen IT-Administratoren bekannt vorkam: BitLocker aktiviert, Secure Boot aktiviert, Code Integrity aktiviert – und trotzdem meldete Intune für alle drei Checks einen Fehler mit dem gleichen Code 2016345708. Das sah nach einem Problem mit den Geräteeinstellungen aus, war es aber nicht. Die Ursache lag eine Ebene tiefer, im Zusammenspiel zwischen Windows, dem Trusted Platform Module (TPM) und dem Microsoft Device Health Attestation Service.

Wenn Intune prüft, ob ein Gerät compliant ist, vertraut es nicht einfach auf eine lokale Ja/Nein-Antwort. Stattdessen fragt es den Health Attestation Service: der sammelt beim Hochfahren des Geräts gemessene Boot-Protokolle und TPM-Nachweise, schickt sie an Microsofts Cloud-Dienst und erhält ein signiertes Gesundheitszertifikat zurück. Dieses Zertifikat fungiert als „Reisepass“ des Geräts für Intune. Fehlt der Reisepass, weil die Ausstellung nicht geklappt hat, kann Intune nicht bestätigen, dass BitLocker eingeschaltet ist. Das Gerät erscheint noncompliant, obwohl lokal alles korrekt ist.

Bei den Juli-Builds war der Fehler genau dieser: Das Gesundheitszertifikat kam nie an. Der Tpm-HASCertRetr-Task blieb hängen – der Health-Attestation-Status verharrte auf 0xFFFF, dem Code für einen aus unbekanntem Grund fehlgeschlagenen Zertifikatsabruf. Weil dieser eine Nachweis fehlte, gingen auch alle abhängigen Compliance-Prüfungen (BitLocker, Secure Boot, Code Integrity) ins Leere. Das war kein Einzelfall. Bereits 2023 gab es ähnliche Berichte. Diesmal war die Ursache eine neue Windows-Funktion, die mit dem Juli-Update aktiviert wurde.

Die Analyse zeigte ein verstecktes Windows-Feature: die Funktions-ID 62861611, intern „PCPKspEKPubEnumeration“ genannt. Diese Funktion ändert, wie Windows die TPM-Identität vorbereitet, bevor der Attestierungsprozess beginnt. Normalerweise verwendet Windows einen etablierten RSA-basierten Pfad, um den Endorsement Key (EK) und den Attestation Identity Key (AIK) auszulesen. Mit Feature 62861611 erweitert Windows diesen Pfad: es sammelt zusätzliche öffentliche Schlüssel aus dem TPM – sowohl RSA als auch ECC – und bereitet einen neuen AIK-Typ (v2) vor. Das ist eine Modernisierung für mehr Krypto-Agilität und verschiedene Algorithmen.

Doch diese Erweiterung führte zu Kompatibilitätsproblemen. Bei physischen TPMs von Herstellern wie Nuvoton oder STMicroelectronics konnte Windows zwar die vorhandenen Zertifikate finden, aber die neu angelegten Identitäten ließen sich nicht vollständig mit dem Microsoft-AIK-Dienst abgleichen. Die Zertifikatskette wurde als ungültig zurückgewiesen. Bei virtuellen TPMs – etwa in Parallels Desktop – war das Problem noch schwerwiegender: Der neue Code erwartete bestimmte Schlüsselformate, die die virtuelle TPM-Umgebung nicht lieferte. Get-Tpm gab den Fehler „Structure is wrong size“ zurück, und Hello, BitLocker sowie alle Attestierungsfunktionen brachen zusammen.

Microsoft hat das Problem mit Advisory IT1431577 anerkannt. Die Ursache wurde als „Windows-Code-Regression“ beschrieben, die Device Health Attestation und die Intune-Compliance-Auswertung beeinträchtigt. Das Advisory geht nicht auf die Details des Features 62861611 ein, bestätigt aber: Es war kein Konfigurationsfehler in Intune, sondern ein Windows-Update, das die Attestierung während der Enrollment-Phase veränderte. Die offizielle Lösung war KB5101684, ein Preview-Update, das die Regression behob. Davor hatte Microsoft bereits serverseitige Anpassungen vorgenommen, um die Auswirkungen abzumildern.

Was bedeutet das konkret für Administratoren? Wenn nach einem Windows-Update plötzlich hunderte Geräte als noncompliant wegen BitLocker, Secure Boot und Code Integrity auftauchen, sollten sie nicht jede Einstellung einzeln debuggen. Der gemeinsame Nenner ist das Device Health Attestation-Zertifikat. Ein einfacher A/B-Test, den der PatchMyPC-Autor durchgeführt hat, zeigt, wie man das Problem isolieren kann: Deaktiviert man das Feature 62861611 mit einem Tool wie ViVeTool und startet neu, funktioniert die Attestierung wieder. Das belegt, dass die Ursache in der neuen TPM-Identitätslogik liegt und nicht im TPM selbst.

Für die Zukunft bleibt die Erkenntnis: Microsoft treibt die Krypto-Agilität von Windows voran, auch wenn das bei bestehenden Infrastrukturen zu kurzzeitigen Aussetzern führen kann. Die Einführung von AIK v2 und die breitere Nutzung von ECC-Schlüsseln erhöht die Sicherheit, erfordert aber, dass sowohl physische als auch virtuelle TPMs die neuen Anforderungen erfüllen. Die betroffene Feature-ID ist nur der Anfang. IT-Teams sollten ihre TPM-Umgebungen auf Kompatibilität prüfen, insbesondere bei Geräten mit unterschiedlichen TPM-Herstellern oder virtualisierten TPMs.

Diese Geschichte zeigt, wie tief die Abhängigkeiten in modernen Windows-Umgebungen reichen. Ein kleiner Schalter in der Windows-Binary kann Compliance-Ergebnisse auf der ganzen Flotte kippen lassen, ohne dass sich an den Sicherheitseinstellungen selbst etwas ändert. Die Lösung kommt in Form eines kumulativen Updates, aber das Verständnis der Ursache hilft, ähnliche Störungen schneller zu erkennen. Der schlimmste Fehler wäre, jetzt an den BitLocker-Richtlinien zu drehen – das würde das Problem nur verschleiern, nicht beheben.

Quelle: patchmypc.com

Der Prototyp läuft. Die Produktion nicht.

Du hast eine Idee für eine KI-gestützte Anwendung. Ein paar Wochen später läuft der Prototyp gut – schnell, beeindruckend. Der Kunde ist zufrieden, das Team feiert. Doch dann schickst du das System in die echte Welt. Und plötzlich treten Probleme auf, die du nicht erwartet hast. Requests timeouten. Workflows verlieren ihren Zustand. Drittanbieter-APIs antworten nicht oder senden Müll. Im Prototyp war alles kontrolliert. In der Produktion wird es schwierig. Entwickler, die KI-Systeme in großem Maßstab betreiben, bestätigen: Die größte Hürde ist nicht die KI selbst. Es ist die Umgebung.

Die Illusion der einfachen KI

Liest du die Schlagzeilen, entsteht der Eindruck, KI sei ein Prompt, den man an ein Sprachmodell schickt, und dann läuft es. In der Praxis zählt Infrastruktur, Orchestrierung, Fehlermanagement und Zustandspersistenz über asynchrone Aufrufe hinweg. Ein Team baute ein Go-to-Market-Tool: eine Plattform, die Firmen bewertet, Leads anreichert und E-Mails verfasst. Klingt harmlos. In Wirklichkeit orchestriert das System Dutzende von Drittanbieter-APIs – CRM, Datenanbieter, E-Mail-Dienste. Jede hat eigene Limits, Fehlermodi, Timeouts. Fällt eine aus, darf der ganze Workflow nicht sterben. Der schlimmste Fehler: Den Zustand eines Workflows nur im Arbeitsspeicher zu halten – ein Serverneustart und alles ist weg.

Wie Orchestrierung zum Rettungsanker wird

Ohne Orchestrierung scheitern komplexe Workflows. Entwickler, die KI-basierte Prozesse ohne zuverlässige Orchestrierung bauen, brauchen ein System, das den Fortschritt dauerhaft speichert, automatische Wiederholungsversuche durchführt und Zustände über Stunden oder Tage nachhält. Lösungen wie Temporal – eine Workflow-Engine für langlaufende, fehlertolerante Prozesse – helfen dabei. Das beruht auf Erfahrungen mehrerer Teams, die ihre KI-Systeme damit in den Griff bekommen haben.

Fall 1: Cargo – das API-Orchester

Das erste Team, Cargo, hatte genau dieses Problem. Ihre Plattform orchestriert Anfragen an externe Dienste – Firmenbewertung, Lead-Anreicherung, E-Mail-Generierung. Jeder Dienst hat eigene Ratenlimits, Failover-Strategien und Antwortformate. Anfangs lösten sie das mit klassischen Job Queues: ein Job in die Warteschlange, ein Worker holt ihn ab. Das funktioniert nicht, sobald ein Job mehrere Schritte nacheinander umfasst. Wenn der zweite Schritt fehlschlägt, muss der ganze Job von vorne beginnen. Oder der Zustand geht verloren. Die Lösung war der Wechsel zu Temporal: Jeder Workflow wird als Code geschrieben, mit expliziten Schritten, Bedingungen und Fehlerbehandlungen. Aurelien Aubert, CEO von Cargo, beschreibt es so: „Unsere gesamte Orchestrierung basiert heute auf Temporal.“

Fall 2: Grepsr – Daten im Tsunami-Modus

Das zweite Team, Grepsr, baute ein Web-Scraping-System, das täglich über 600 Millionen Datensätze aus mehr als 10.000 Quellen verarbeitet. Millionen parallele Jobs. Traditionelle Job Queues wie RabbitMQ oder Celery sind dafür nicht ausgelegt. Sie verlieren Jobs bei Worker-Ausfällen, können keine langlaufenden Workflows mit Zwischenzuständen abbilden, das Monitoring wird aufwendig. Mit Temporal modellierten sie jeden Scraping-Job als Workflow – mit eigener ID, persistentem Zustand und definierten Fehlerstrategien. Subrat Basnet, Co-Founder von Grepsr, sagt: „Unsere Entwickler müssen sich nicht mehr um das Orchestrieren von Wiederholungsversuchen oder das Nachhalten des Job-Zustands kümmern. Sie konzentrieren sich auf das Wesentliche – bessere Datenerlebnisse für unsere Kunden zu bauen.“

Fall 3: Dust – KI-Teammitglieder, die funktionieren

Dust, ein Unternehmen für KI-gestützte „Teammitglieder“, hatte eine komplexere Aufgabe. Ihre KI-Agenten führen über 10 Millionen Workflow-Schritte pro Tag aus. Diese Schritte umfassen Entscheidungslogik, Kontextwechsel und Interaktionen mit verschiedenen KI-Modellen. Ohne robuste Orchestrierung – so der CTO – wäre ein Agent nicht mehr als ein Chatbot, der nach dem ersten Fehler aufgibt. Sie setzen auf Temporal und lernten: Zuverlässigkeit steckt nicht im KI-Modell, sondern in der Fähigkeit, einen Workflow nach Ausfällen kontrolliert fortzusetzen. Wenn ein KI-Aufruf fehlschlägt, muss der Workflow nicht von vorne beginnen. Er kann an der Stelle weitermachen, an der er unterbrochen wurde. Das erfordert eine Orchestrierungsplattform, die genau das leistet.

Warum der Kampf um die Zustandserhaltung entscheidend ist

Warum reicht es nicht, jeden Schritt in einer Datenbank zu protokollieren und bei Bedarf neu zu starten? KI-Workflows sind oft nicht linear. Sie verzweigen sich, rufen asynchrone Dienste auf, warten auf menschliche Rückmeldungen oder auf Ergebnisse anderer Workflows. Wenn ein Worker während eines solchen Prozesses abstürzt, muss der Zustand wiederherstellbar sein, ohne dass Logik verloren geht. In vielen Systemen wird der Zustand implizit durch den Call-Stack gehalten. Sobald der Prozess stirbt, ist dieser Zustand weg. Temporal löst das, indem es den Zustand jedes Workflows in einen dauerhaften Speicher schreibt – ähnlich wie ein Flugschreiber. Fällt ein Worker aus, übernimmt ein anderer exakt an der Stelle, an der der Workflow unterbrochen wurde. Das ist der Unterschied zwischen einem Prototyp unter Laborbedingungen und einem zuverlässigen Produktivsystem.

Was Entwickler daraus lernen können

Die drei Fallstudien zeigen ein Muster: KI in der Produktion ist kein Problem der KI, sondern der Orchestrierung, Zustandsverwaltung und Fehlertoleranz. Gute Modelle nützen nichts, wenn die Infrastruktur versagt. Abkürzungen gibt es nicht. Von Anfang an muss man Fehlerstrategien einplanen. Zustandspersistenz ist Kernanforderung, kein nachträglicher Einfall. Werkzeuge müssen für diese Herausforderungen entwickelt sein. Erfolgreiche Teams haben den Prototypen verworfen und eine robuste Architektur aufgebaut. Das ist Ingenieursarbeit.

Der Weg nach vorne – ohne Illusionen

KI wird bleiben und wachsen. Entwickler, die langfristig bestehen, verstehen: Ein KI-System ist mehr als ein Modell – es ist ein verteiltes System mit all seinen Tücken. Wenn du deine nächste KI-Anwendung baust, frag dich nicht nur, welches Modell du verwendest. Frag dich, wie dein System mit Timeouts umgeht, wie es verlorenen Zustand wiederherstellt, wie es tausende parallele Workflows orchestriert. Die Antworten entscheiden, ob dein System ein weiterer Prototyp bleibt, der unter realen Bedingungen zerbricht, oder ob es in der Produktion lebt. Diese Lektion ist wichtiger als jeder neue KI-Trend.

Quelle: temporal.io