Suchergebnisse für: „Modell“

„Instead of relying on a separate, often larger, teacher, we leverage their self-critiques as privileged information.“ Dieser Satz steht im Abstract von UniEvo-VL, einem Paper, das Fang Wu mit 18 Mitautoren vorgelegt hat, unter anderem von der Stanford University und der Johns Hopkins University. Dahinter steckt eine Verschiebung: Nicht das größere Modell soll den Ton angeben, sondern die Kritik, die ein System an seiner eigenen Arbeit formuliert. Der Gedanke ist einfach – wenn ein Modell Bilder erzeugen und Bilder verstehen kann, kann es auch beurteilen, ob sein eigenes Ergebnis zur Aufgabe passt.

Hier setzt die Arbeit an. Moderne multimodale Modelle bringen Generierung und Verständnis in einem einzigen System zusammen, und nur deshalb können sie aus ihrem eigenen Feedback lernen. Viele Verfahren lernen aus korrigierten Zielbildern oder aus einer einzelnen Belohnungszahl. Das Team geht einen anderen Weg und nutzt die Selbstkritik als privilegierte Information, also als etwas, das dem Modell zur Trainingszeit zur Verfügung steht, zur Laufzeit aber nicht mehr gebraucht wird.

Ein Modell in zwei Rollen: Lehrer und Schüler mit unterschiedlichem Kontext

UniEvo-VL beschreibt ein selbstverbesserndes Framework, in dem dasselbe multimodale Modell zwei Aufgaben übernimmt. Der Schüler sieht nur die schlichte Frage, die sogenannte Vanilla-Frage, ohne jeden Zusatz. Der Lehrer sieht dieselbe Frage plus die Kritik am ersten Versuch. Beide sind derselbe Bildgenerator, der Lehrer ist eine langsam nachgeführte Kopie des Schülers (ein exponentieller gleitender Mittelwert der Gewichte). Allein der Kontext unterscheidet sie. Der Kern: Es braucht kein separat trainiertes, größeres Lehrermodell. Die Kritik selbst schreibt im Experiment allerdings ein eigenes Verständnismodell aus derselben Familie, Qwen-VL; trainiert wird nur der Generator, und zwar über schlanke LoRA-Parameter.

Man kann sich das wie eine Werkstatt mit zwei Räumen vorstellen. Im ersten Raum liegt das fertige Stück auf dem Tisch, ohne Kommentar. Im zweiten Raum liegt dasselbe Stück, daneben ein Korrekturzettel mit den Stellen, die nicht stimmen. In beiden Räumen steht dieselbe Person. Die Frage ist nicht, ob sie es besser kann – mit dem Zettel kann sie es offensichtlich besser. Die Frage ist, ob sie diese Fähigkeit auch ohne Zettel abruft. Genau das ist die Aufgabe des Trainings: die Kompetenz aus dem zweiten Raum in den ersten hinüberzuziehen, ohne dass der Zettel je wieder auftaucht.

Deshalb heißt die Information privilegiert. Im Training ist sie reichlich vorhanden, im Betrieb nicht. Wer Selbstkritik als privilegierte Information nutzt, verlagert Wissen, nicht Daten. Das ist etwas anderes als eine Datenbank mit guten Beispielen, denn das Modell lernt hier aus der Differenz zwischen seinem ersten und seinem korrigierten Versuch.

On-Policy Self-Distillation: gelernt wird auf den eigenen Spuren

Der Trainingsmechanismus heißt On-Policy Self-Distillation, und beide Wörter verdienen Aufmerksamkeit. On-Policy bedeutet, dass der Schüler seine eigenen Spuren erzeugt, statt Beispiele aus einem fremden Datensatz nachzuahmen. Bei der Bildgenerierung sind diese Spuren die Denoising-Pfade: die Kette von Zwischenschritten, die vom reinen Rauschen zum fertigen Bild führt. Das Modell läuft durch seinen eigenen Entstehungsprozess, Schritt für Schritt, und genau dort wird gelernt.

Anschließend minimiert das Training die Divergenz zwischen den Denoising-Verteilungen von Lehrer und Schüler, und zwar an jedem einzelnen Zustand entlang dieser Pfade. Nicht das Endergebnis wird mit einer Note bewertet, sondern die Wahrscheinlichkeitsverteilung an jedem Zwischenschritt wird zur Deckung gebracht. Es ist der Unterschied zwischen „das Bild ist gut“ und „an dieser Stelle hättest du anders abbiegen müssen“. Der Lernreiz liegt in der dichten Rückmeldung, nicht in einer einzelnen Zahl am Ende.

Das erklärt auch, warum der Ansatz überhaupt funktionieren kann. Ein skalares Belohnungssignal sagt dem Modell, dass etwas besser war, aber nicht wo. Eine Verteilungsangleichung über den gesamten Pfad sagt ihm sehr genau, an welchen Stellen es abweicht. Die Verbesserung der Bildgenerierung durch Selbst-Distillation kommt also nicht aus mehr Rechenzeit allein, sondern aus der Auflösung des Signals.

Die Zahlen: GenEval und Soft-TIFA im Vergleich

Die Experimente bauen auf dem offenen Modell Qwen-Image-2512 auf, das mit Qwen-Image 3.0 verwandt ist. Mit dem hauseigenen Kritiker Qwen-VL steigt der Wert auf GenEval von 0,747 auf 0,808. Die zweite Zahl aus dem Abstract, ein Anstieg von 32,97 auf 35,53 bei GenEval2 Soft-TIFA, stammt dagegen aus dem Lauf mit einem externen Kritiker, GPT-5.6-Luna. Mit dem eigenen Kritiker sinkt GenEval2 im Volltext leicht, von 32,58 auf 32,37; erst wenn die überarbeiteten Prompts zusätzlich geprüft werden, steigt der Wert auf 35,07. Beide Benchmarks prüfen im Kern, wie zuverlässig ein erzeugtes Bild zur Textvorgabe passt – ob Objekte, Farben, Anzahlen und Anordnungen stimmen.

Bemerkenswert ist, dass die Verbesserung ohne korrigierte Zielbilder und ohne Belohnungssignal entsteht. Zusätzlich berichtet das Team, dass die Empfindlichkeit des Modells für zusätzliche Reflexionsinformation erhalten bleibt: Auch das trainierte Modell profitiert noch von einem weiteren Korrekturdurchgang. Es verliert also nicht die Fähigkeit, auf Kritik zu reagieren, während es lernt, ohne sie auszukommen.

Wer selbst mit Bildmodellen arbeitet, sollte die Zahlen dennoch nüchtern lesen. Die Gewinne konzentrieren sich auf Prompts, an denen das Basismodell anfangs scheitert. Bei Prompts, die es schon vorher gut löste, sinken die Werte um 1 bis 4 Punkte auf einer Skala bis 100. Teuer ist das Verfahren auch: Nur 10 bis 21 Prozent der Versuche liefern ein brauchbares Trainingspaar, also fünf bis zehn Anläufe pro Paar, trainiert wurde auf vier H200-GPUs.

Warum ein starker Kritiker die Obergrenze hebt

Ein Ergebnis des Papers verdient besondere Beachtung. Das Team hat zusätzlich mit einem leistungsfähigeren externen Kritiker trainiert, GPT-5.6-Luna. Damit erreicht das Modell auf GenEval 0,882 statt 0,808 und auf GenEval2 den Bestwert von 35,53. Die Autoren folgern, dass Modelle mit starken Beurteilungsfähigkeiten eine höhere Obergrenze der Selbstverbesserung erwarten können. Die Qualität der Kritik bestimmt also, wie weit das Verfahren trägt.

Das ist einleuchtend und ein wenig unbequem. Wenn das Modell nur so weit kommt, wie es sich selbst durchschaut, dann ist Selbstverbesserung zunächst einmal durch die eigene Urteilskraft begrenzt. Ein besseres Urteilsvermögen verschiebt diese Grenze nach oben. Damit ist der Anspruch „ohne externen Lehrer“ an dieser Stelle qualifiziert: ohne externen Lehrer im Training ja, aber nicht ohne gutes Urteilen. Die Formulierung im Abstract spricht davon, dass ein höheres Niveau zu erwarten sei – nicht, dass es bewiesen wäre.

Für die Praxis heißt das: Wer dieses Verfahren nutzen will, sollte zuerst in die Kritikfähigkeit investieren. Der Kritiker ist der eigentliche Engpass, nicht der Generator.

Text-Rendering: wo die Verbesserung nicht gleichmäßig greift

Das Team berichtet außerdem von gemischten Ergebnissen beim Rendern von Text im Bild. Nur die Variante mit geprüften Prompts verbessert sich hier, von 0,771 auf 0,790. Mit dem ungeprüften eigenen Kritiker fällt der Wert unter das Ausgangsniveau, mit GPT-5.6-Luna steigt er nur leicht. Die Selbstverbesserung ist also nicht über alle Aufgaben hinweg gleich verteilt.

Ein Modell erbt die blinden Flecken seines Kritikers. Wenn die Kritik beim Text-Rendering nicht sauber unterscheidet, ob Buchstaben korrekt gesetzt oder nur plausibel aussehen, dann kann die Verteilungsangleichung diese Unterscheidung auch nicht herstellen. Die Selbstverbesserung verstärkt, was die Kritik schon erkennt – und eben auch, was sie übersieht.

Statt eine gleichmäßige Kurve nach oben zu behaupten, benennt das Paper diese Ungleichverteilung. Wer solche Verfahren einsetzt, sollte deshalb nicht von einer pauschalen Qualitätssteigerung ausgehen, sondern von einer aufgabenspezifischen.

Was das konkret bedeutet

UniEvo-VL ist kein Durchbruch, der die Bildgenerierung neu ordnet, sondern ein Rezept mit einer klaren Idee: Selbstkritik wird zur privilegierten Information, und ein einziges Modell spielt Lehrer und Schüler in unterschiedlichen Kontexten. Der Bezug zu Test-Time Compute ist dabei der interessanteste Punkt. Die Kritik entsteht beim Erzeugen, kostet dort Rechenzeit und wird anschließend in dauerhaftes Können übersetzt. Der Aufwand fällt im Training an, danach erzeugt das Modell bessere Bilder ohne zusätzlichen Korrekturdurchgang.

Für die Praxis ergeben sich zwei Konsequenzen. Erstens: Der Engpass verschiebt sich vom Generator zum Kritiker – wer in Beurteilungsfähigkeit investiert, gewinnt mehr als jemand, der nur größere Generatoren baut. Zweitens: Erwartungen gehören aufgabenspezifisch formuliert. Prompt-Treue lässt sich so verbessern, Text-Rendering nicht automatisch mit, und leichte Aufgaben können sogar leicht schlechter werden. Und die Verbesserung ist, wie das Paper selbst schreibt, nicht zwingend gleichmäßig.

Offen bleibt, wie weit das Verfahren skaliert, ob die Selbstkritik mit steigender Modellqualität informativ bleibt oder sich selbst bestätigt, und wo genau die Obergrenze liegt, wenn kein stärkerer externer Kritiker mehr zur Verfügung steht. Wer heute multimodale Modelle einsetzt, muss darauf nicht warten. Die relevante Frage ist ohnehin nicht, ob es einen größeren Lehrer gibt, sondern ob im eigenen System ein verlässlicher Kritiker arbeitet. Die Details stehen im vollständigen Paper, nicht im Abstract.

Quelle: arxiv.org

Wer über KI-Kosten spricht, redet fast immer über das Modell: das große Frontier-Modell für die schwierigen Fälle, ein kleineres für den Rest, dazwischen ein Gateway, das verteilt. Dahinter steht die Annahme, dass Genauigkeit Geld kostet und billige Modelle billig antworten. Ein Whitepaper des Datenanbieters CData dreht das um. Nach 1.034 Testläufen mit 22 Modellen kommt es zu dem Schluss: Die Kosten bestimmt nicht das Modell, sondern die Datenebene darunter. Steht die Geschäftslogik im Data Layer statt im Prompt, liefern günstige und teure Modelle dieselbe richtige Antwort. Der einzige messbare Unterschied ist der Preis. Wer KI-Kosten senken will, sollte nicht im Modellkatalog anfangen.

Ein Benchmark, der alle Modelle absichtlich gleich behandelt

Die Zahl 178x klingt nach Marketing. Sie hält nur, wenn die Anordnung sauber ist. Die Autoren beschreiben 22 Modelle von acht Entwicklern, verteilt über drei Aufgaben und zwei bis drei Tool-Bedingungen pro Aufgabe, insgesamt 1.034 Läufe. Die Daten kamen live und föderiert: Kundenkonten aus einem CRM, Nutzungstelemetrie aus einem Cloud-Warehouse, Support-Vorfälle aus einer ITSM-Plattform, verbunden über die eigene Schicht. Nichts davon wurde vorab aufbereitet oder in eine Testdatei kopiert.

Wichtiger als die Zahl der Modelle ist die Vergleichbarkeit. Jedes Modell lief durch denselben clientseitigen Tool-Loop, es gab also keinen Heimvorteil für einen bestimmten Anbieter. Token wurden so gezählt, wie der jeweilige Anbieter sie abrechnet, zu Listenpreisen. Leseaufgaben bewertete man per Set-F1 gegen einen offline berechneten Golden Key, Schreibaufgaben am tatsächlichen Endzustand der Zieltabelle, abgelesen über einen separaten Endpunkt. Der Unterschied zwischen einem Benchmark und einer Vorführung: Die Bewertung entsteht nicht dort, wo das Modell arbeitet.

Der Fehler, der wie die richtige Antwort aussieht

Ohne die Datenschicht lieferten die Modelle vollständige, wohlgeformte Kontolisten, die falsch waren. Das ist der gefährliche Fall: Eine falsche Antwort, die richtig aussieht, fällt niemandem auf, weil nachgelagerte Systeme keine Abweichung melden. Ein offensichtlicher Fehler kostet einen Retry. Ein plausibler kostet Vertrauen.

Dahinter steckt ein Strukturproblem. Rohdatenzugriff zeigt dem Modell das Schema, aber nicht die Regeln. Es muss erraten, welche Telemetrie zu welchem Gesundheitssignal gehört, ab welchem Schwellenwert ein Konto als gefährdet gilt und wie drei getrennte Systeme überhaupt zusammenhängen. Diese Regeln stehen nirgends im Datenbestand, sie stehen im Kopf der Fachabteilung. Wer sie einmal in der Datenebene hinterlegt, vererbt dieselbe korrekte Definition an jedes Modell, das sie aufruft.

Bei Schreiboperationen wurde es unangenehm. Ohne Grenze im Werkzeug schrieben die Modelle weit über die autorisierte Menge hinaus, im schlechtesten Lauf tausende falsche Werte. Dasselbe Modell auf derselben Aufgabe schrieb in einem Durchlauf die 21 korrekten Datensätze und im nächsten hunderte falsche. Ein Verhalten, das von Lauf zu Lauf schwankt, lässt sich nicht betreiben. Die Grenze muss dort liegen, wo das Modell sie nicht umdeuten kann.

Kosten pro korrekter Antwort

Sobald die Datenschicht die Logik trägt, ändert sich das Bild. Alle Tiers waren gleich genau, übrig blieb die Rechnung pro richtigem Ergebnis. Die Baseline-Genauigkeit der untersuchten Modelle lag bei null bis 19 Prozent, optimiert bei 100 Prozent – bei identischem Ergebnis, demselben Satz von 44 Konten.

Modell	Klasse	Kosten pro korrekter Antwort (optimiert)
Mistral Small	Economy	0,0009 $
DeepSeek V4 Flash	Economy	0,0032 $
Gemini 3.7 Flash	Mid	0,0156 $
Sonnet 5	Frontier	0,0604 $
Opus 5	Frontier	0,0753 $
Fable 5	Frontier	0,1571 $

Zwischen billigstem und teuerstem Wert in dieser Tabelle liegt rechnerisch etwa der Faktor 175, über alle 22 Modelle hinweg spricht CData von 178x. Bei der Ranking-Aufgabe erreichten neun Modelle exakt dieselbe Punktzahl und spannten trotzdem einen Faktor von 279 auf. Ohne Datenschicht war selbst das beste Modell nur in 40 Prozent der Fälle korrekt – der Preisunterschied half nicht. Bei den Schreibaufgaben schrieben 20 von 22 Modellen mit der Datenschicht exakt korrekt, ohne sie produzierte der schlechteste Lauf tausende falscher Werte.

Wie aus einer Genauigkeitsfrage eine Preisfrage wird

Man kann sich das wie eine Küche vorstellen. Ein Sternekoch ohne Rezeptur improvisiert – manchmal brillant, manchmal ungenießbar. Ein günstiger Koch mit klarer Rezeptur liefert dagegen verlässlich dasselbe Gericht. Solange die Rezeptur fehlt, bezahlt man für Kochkunst, die das eigentliche Problem nicht löst: Das Gericht ist immer noch falsch, nur teurer produziert.

Die Datenebene ist diese Rezeptur. Sie hält die Geschäftslogik und die Leitplanken, aus denen ein Modell eine korrekte Handlung ableitet. Ist sie einmal kodiert, erbt jedes Modell, das sie aufruft, dieselbe Definition – und erst dann ist ein Modellkosten-Vergleich sinnvoll. Vorher vergleicht man Fehlerraten, die von Prompt zu Prompt schwanken, und hält das Ergebnis für einen Preisvergleich.

Auf der Sicherheitsseite gilt dasselbe Prinzip. Wo die Grenze im Werkzeug liegt und nicht im Prompt, kann das Modell sie nicht neu interpretieren. Der erlaubte Schreibbereich wird zu einer Eigenschaft der Umgebung statt zu einer Bitte an das Sprachmodell. Mit Data Layer entstehen Genauigkeit und Sicherheit an derselben Stelle wie die Kosten.

Was das für die eigene Modellauswahl bedeutet

Die praktische Konsequenz beginnt bei der Maßeinheit. Solange man Preise pro Million Token vergleicht, optimiert man am falschen Wert, weil die Fehlerrate die Kosten pro brauchbarem Ergebnis dominiert. Erst die Kennzahl Kosten pro korrekter Antwort macht sichtbar, dass ein 178-mal teureres Modell nicht besser, sondern nur teurer ist. Sobald beide Kandidaten dieselbe Trefferquote liefern, ist die Entscheidung eine reine Budgetfrage.

Der zweite Schritt ist eine ehrliche Bestandsaufnahme: Welche Regeln stecken heute in Prompts, Templates oder Systemnachrichten? Jede Regel dort ist eine Regel, die pro Aufruf neu erklärt und neu geraten wird. Wandert sie in die Datenebene, verschwindet sie aus dem Kontext und damit aus den Tokenkosten. Der dritte Schritt betrifft Schreibzugriffe, die man getrennt betrachten sollte. Eine Leseaufgabe mit 70 Prozent Trefferquote ist ein Ärgernis, eine Schreiboperation ohne Grenze ist ein Datenvorfall.

Wer die Zahlen nicht glauben will, muss sie nicht glauben. Der Test-Harness liegt auf GitHub, samt der wörtlichen Aufgabenstellungen, der Tool-Schemas für jede Bedingung und dem Generator für die Golden Answers. Man kann denselben Aufbau gegen die eigenen Systeme laufen lassen, und das ist der einzige Weg, aus einem Anbieter-Benchmark eine belastbare eigene Entscheidungsgrundlage zu machen.

Was die 178x konkret bedeuten – und wo die Grenzen liegen

Eine Einschränkung vorweg: Das Whitepaper stammt von CData, und CData verkauft genau die Datenschicht, um die es geht. Die Ergebnisse sind nicht unabhängig nachgeprüft, die Preise sind Listenpreise, und die Spanne gilt für einen bestimmten Aufgabentyp, der Komposition über mehrere Datenquellen verlangt. Für einen einzelnen Klassifikationslauf über einen kurzen Text sehen die Verhältnisse anders aus. Die Richtung des Befunds ist trotzdem robust und deckt sich mit dem, was viele Teams in der Praxis beobachten: Kontextqualität schlägt Modellgröße.

Für die nächste Planungsrunde heißt das: Die Frage lautet nicht, welches Modell man sich leisten kann, sondern wie viel Geschäftslogik noch im Prompt steht, weil sie nirgends sonst hinterlegt ist. Jede dieser Regeln ist ein wiederkehrender Kostenfaktor, eine Quelle für Schwankungen und ein Risiko für stille Fehler. Die Modellauswahl bleibt wichtig, aber sie wird zur zweiten Frage. Die erste lautet, woher das Modell weiß, was hier richtig bedeutet.

Quelle: cdata.com

Man stelle sich einen Massenexport von Kundendaten im Audit-Log vor, ausgeführt unter dem Konto eines Entwicklers – kein Einbruch, kein geleaktes Passwort, keine fremde IP. Ein KI-Agent hat die Zugangsdaten dieses Entwicklers benutzt und genau das getan, wozu er beauftragt war. Mit KI-Systemen, die dauerhaft mitarbeiten, rückt dieses Szenario näher. Itamar Apelblat, Mitgründer und CEO des Sicherheitsanbieters Token Security, beschreibt den Wandel in einem von seiner Firma gesponserten Beitrag auf BleepingComputer als dritte Welle der arbeitsbezogenen KI.

Seine These: Die ersten beiden Wellen ließen sich noch in bestehende Zugriffsmodelle einordnen. Die dritte nicht. Sobald KI-Systeme dauerhaft existieren, eigene Aufgaben verfolgen und über Monate hinweg Zugriff auf Daten und Infrastruktur behalten, verhalten sie sich weniger wie Werkzeuge und mehr wie Kollegen. Kollegen brauchen eine Identität. Wer verstehen will, warum die aktuellen Sicherheitsmodelle an dieser Stelle reißen, muss sich anschauen, woher sie kommen – und was sie stillschweigend vorausgesetzt haben.

Drei Wellen, ein Muster: Vom Chatfenster zum Kollegen

Die erste Welle waren sitzungsgebundene Chats. Das Risiko lag in dem, was das Modell sagt: Halluzinationen, Datenlecks in der Antwort, unbedachte Formulierungen. Die Branche antwortete mit Prompt-Filtern, Guardrails und Klassifizierung von Ausgaben – Werkzeuge, die auf Text schauen. Die zweite Welle brachte aufgabenbezogene Agenten. Hier verschob sich das Risiko von der Aussage zur Handlung. Plötzlich ging es nicht mehr darum, was ein Modell behauptet, sondern was es tatsächlich tut: welche API es aufruft, welche Datei es schreibt, welchen Datensatz es verschiebt. Die Antwort darauf waren Zugriffskontrollen und Freigabeprozesse. Ein Mensch muss vor der heiklen Aktion nicken.

Genau dort stehen die meisten Unternehmen heute. Apelblat hält das für eine Momentaufnahme. Die Torpfosten, so seine Argumentation, wurden bereits weitergeschoben, und die dritte Welle steht unmittelbar bevor: dauerhaft existierende KI-Coworker, die nicht für eine einzelne Aufgabe starten und danach verschwinden, sondern bleiben. Ein Indiz findet er in der Wortwahl der Anbieter. Microsoft spricht von Agenten als „digitalen Kollegen“, Sam Altman skizzierte die Vision virtueller Mitarbeiter bereits im Februar 2025. Vokabular ist keine technische Spezifikation, aber es verrät, wohin die Produkte führen sollen.

Für das Sicherheitsmodell bedeutet das einen Bruch. Man kann sich das mit dem Firmenausweis vorstellen: Ein heutiger Agent borgt sich den Ausweis eines Menschen, benutzt ihn eine Weile und gibt ihn danach zurück. Ein persistenter Coworker gibt ihn nie zurück. Er behält ihn, arbeitet weiter, sammelt neue Berechtigungen – und ist irgendwann mit einem Zugriffsprofil unterwegs, das niemand bewusst entworfen hat.

Warum Persistenz aus einem Werkzeug einen Mitarbeiter macht

Freigabe für Freigabe funktioniert nur, solange jemand da ist, der freigeben kann. Ein Coworker, der nachts, am Wochenende oder parallel in zwanzig Threads arbeitet, kann nicht für jede einzelne Aktion auf einen Menschen warten. Für Apelblat folgt daraus: Zugriff muss vorab bereitgestellt werden, gepaart mit der Möglichkeit, bei Bedarf zusätzliche Rechte anzufordern. Das ist ein anderes Modell als die ereignisgesteuerte Einzelfreigabe, die heute als sicherer Standard gilt.

Dazu kommt, dass Identitäten speziell für KI-Agenten bislang die Ausnahme sind. Der Normalfall sieht anders aus: OAuth-Grants, Übergaben innerhalb einer Sitzung und Service-Accounts. Bei den ersten beiden Varianten ist der Mensch die primäre Entität, auch wenn der Agent handelt. Der Service-Account wiederum wurde selten für einen Agenten geschaffen, sondern meist für eine andere Maschine und dann zweckentfremdet. In allen drei Fällen fehlt genau das, was ein dauerhafter Coworker bräuchte: eine eigene, klar umrissene Identität mit dokumentiertem Zweck.

Persistenz erzeugt zusätzlich Standing Privileges, also dauerhaft bestehende Berechtigungen, die einfach da sind, ob genutzt oder nicht. Bei Menschen ist das ein altbekanntes Problem, das niemand sauber gelöst hat. Bei Maschinen wird es ärger. Ein digitaler Kollege braucht einen Lebenszyklus, der das Deprovisioning ausdrücklich einschließt: Was passiert, wenn das Projekt endet, das Team aufgelöst wird oder die verantwortliche Person das Unternehmen verlässt? Wer diese Frage beim Anlegen nicht beantwortet, baut einen Zugang, den niemand mehr kontrolliert.

Verschärft wird das durch Access Creep. Wer lange genug im Unternehmen ist, sammelt Rechte – das ist der älteste ungelöste Fall der Identity Governance. Für Maschinen rechnet Apelblat mit einer schlimmeren Dynamik, aus zwei Gründen: Zugriff akkumuliert sich schneller, und Agenten nutzen tendenziell alles, was sie bekommen. Mehrere für sich genommen vernünftige Einzelberechtigungen können zusammen eine Reichweite ergeben, die niemand beabsichtigt hat. Der Schlüsselbund wächst nicht durch böse Absicht, sondern durch Gleichgültigkeit gegenüber dem, was schon dranhängt.

Was die großen Plattformen heute tatsächlich ausgeben

Praktisch heißt das: Die zwei am weitesten verbreiteten Agentenplattformen geben ihren Agenten derzeit keine eigenen Credentials. Nach Darstellung des Autors betreiben weder Anthropic noch OpenAI den OAuth-Client-Credentials-Grant in ihren gehosteten Chat-Produkten, und die Konnektoren von ChatGPT lehnen Service-Accounts sowie JWT-Assertions ab. Entwickler können einem Agenten über die APIs ein statisches Bearer-Token mitgeben. Das ist keine Identität, sondern ein Schlüssel ohne Namen.

Die Folge ist kein theoretisches Risiko. Wenn ein KI-System unter den Rechten eines Menschen handelt, steht im Audit-Trail in der Regel der Mensch als Akteur. Die Protokolle werden dadurch unzuverlässig. Eine Untersuchung, die auf solchen Logs baut, kann nicht sauber unterscheiden, ob ein Mitarbeiter um drei Uhr nachts gehandelt hat oder ein Agent in seinem Namen. Attribution ist keine Formalität. Ohne sie lassen sich Sicherheitsvorfälle nicht aufklären.

Zugleich belastet der Wunsch, den Menschen in der Schleife zu behalten, genau diesen Menschen. OAuth geht davon aus, dass jemand einen Zustimmungsbildschirm liest und eine feste Liste von Scopes absegnet. Agenten geben sich mit ihrer initialen Berechtigung selten zufrieden, sie entdecken Werkzeuge zur Laufzeit und wollen sie benutzen. Alle paar Minuten eine sensible Aktion zu bestätigen ist nervig und sicherheitsschädlich zugleich, denn Aufmerksamkeit ist eine endliche Ressource. Wer hundertmal klickt, klickt beim hundertundersten Mal ohne hinzusehen.

Googles Chip und der Praxistest aus dem Podcast

Die Anforderung ist real. Ein Blick auf die Menschen, die solche Produkte bauen, zeigt das. Tara Seshan, die bei OpenAI das Produkt für ChatGPT Work und Codex verantwortet, beschrieb in einem Podcast-Interview, was einen Agenten tatsächlich nützlich macht. Modellintelligenz sei nur ein Teil davon. Der Rest sei das, was sie als handfestes Alltagsgeschäft bezeichnete: Zugang zu Daten, Cloud-Infrastruktur und Verlässlichkeit. Ihr Vergleich: Man stellt jemanden ein und sperrt ihn dann in einen Raum ohne Google Docs, Slack und Unternehmensdatenbank. Dieser Kollege wird nicht wirksam sein. Ein isolierter Cloud-Agent, so ihr Argument, aus genau demselben Grund ebenso wenig.

Seshan beschrieb außerdem, dass ihr Agent Unteragenten startet, um Arbeit zu parallelisieren, und eine nahe Zukunft, in der ihre Agenten und die ihrer Kollegen gemeinsam an Aufgaben arbeiten. Beide Richtungen sind plausibel. Beide setzen ein Identitätsmodell voraus, das es noch nicht gibt. Denn wenn der Agent einer Person Arbeit an den Agenten einer anderen Person übergibt, gehört das ausführende Credential dem Menschen, der die Kette irgendwann gestartet hat. Verantwortung und Ausführung fallen auseinander.

Der Rückblick lohnt. Google hat 2024 auf der I/O einen Workspace-Agenten namens Chip vorgestellt, mit eigenem Workspace-Konto, zugewiesener Rolle, konfigurierten Berechtigungen und einem festen Zielkatalog. Chip trat Chaträumen bei und antwortete aus dem Verlauf, den er sehen durfte. Die damalige Workspace-Vizepräsidentin Aparna Pappu sagte, es sei noch viel Arbeit nötig, bevor solche virtuellen Teammitglieder produktreif seien. Chip blieb eine Demo. Ausgeliefert wurden stattdessen Agenten, die die Autorität eines Menschen erben – das Gegenteil des ursprünglichen Entwurfs.

Fünf Schritte, die der Anbieter empfiehlt

Aus dieser Analyse leitet Apelblat einen konkreten Katalog ab. Man muss ihn nicht übernehmen, aber als Prüfrahmen taugt er für jedes Unternehmen, das Agenten laufen hat oder laufen lassen will.

Erstens: Schatten-Coworker finden. Ein Register erfasst nur die Agenten, an die jemand gedacht hat. Die anderen erkennt man an ihrem Authentifizierungsverkehr – an OAuth-Grants, API-Schlüsseln und Login-Mustern, die kein Mensch erklären kann.

Zweitens: Jeder persistente Agent bekommt eine eigene Identität. Solange er sich als Mensch authentifiziert, kann keine nachgelagerte Kontrolle die beiden auseinanderhalten, und keine Untersuchung ordnet eine Aktion korrekt zu.

Drittens: Ein menschlicher Eigentümer wird festgehalten. Verwaiste Agenten mit aktiven Credentials sind laut dem Autor die häufigste Quelle agentenbezogener Standing Privileges – Zugänge ohne Ansprechpartner, die niemand mehr hinterfragt.

Viertens: Berechtigungen werden auf den Agenten zugeschnitten, nicht auf die Person, die ihn gestartet hat. Ein Agent, der Jira liest, sollte kein Token halten, das auch in den Cloud-Provider schreiben darf, nur weil der auslösende Entwickler zufällig beides durfte.

Fünftens: Vorab festlegen, wann der Agent stirbt. Digitale Coworker sind nicht projektgebunden, aber deshalb nicht unsterblich. Bedingungen wie eine aufgelöste Teamstruktur, ein ausscheidender Eigentümer oder eine definierte Leerlaufzeit gehören in die Konfiguration, nicht ins Nachdenken danach.

Was daraus folgt

Nebeneinander gelegt ergibt sich ein Muster. In Welle eins lag das Risiko in der Ausgabe, die Antwort waren Filter und Guardrails. In Welle zwei verlagerte es sich auf Handlungen, die Antwort waren Zugriffskontrolle und Freigaben. In Welle drei verschwindet der Mensch aus der Schleife, während der Zugriff bestehen bleibt. Nicht die Autonomie allein macht die Sache unangenehm, sondern die Autonomie mit dauerhaften Rechten.

Die Plattformanbieter haben begonnen zu reagieren. Microsoft liefert Entra Agent ID mit eigenständigen Agenten-Identitäten und einem benannten menschlichen Sponsor. Okta hat Agenten-Identitäten ins Universal Directory aufgenommen, mit kurzlebigen, begrenzten Tokens und einem Widerrufspfad. SailPoint und CyberArk haben vergleichbare Angebote. Der Haken ist strukturell: Jede dieser Lösungen sichert Agenten innerhalb der eigenen Umgebung. Wer plattformübergreifend arbeiten muss, findet den einzigen durchsetzbaren Kontrollpunkt bei der Identität, weil Identität den Zugriff auf jede einzelne Aktion regelt.

Transparenz gehört dazu: Der zitierte Beitrag ist gesponserter Content des Anbieters Token Security und endet mit einem Produktaufruf. Die technische Analyse ist deshalb nicht falsch, aber sie ist nicht interessefrei. Wer die Empfehlungen umsetzt, sollte sie als Prüfliste lesen und nicht als Einkaufsliste – die fünf Schritte funktionieren unabhängig davon, welches Werkzeug am Ende darunter steht.

Für dich und dein Team heißt das vor allem: Bestandsaufnahme vor Werkzeugauswahl. Wie viele Agenten authentifizieren sich in eurer Umgebung gerade mit den Zugangsdaten von Menschen? Wer ist der Eigentümer, und was passiert, wenn diese Person geht? Die Antworten darauf sind unangenehmer als jede Produktentscheidung – und genau daran zeigt sich, ob euer Sicherheitsmodell die dritte Welle übersteht. Ein Kollege bekommt einen Ausweis, bevor er eine Aufgabe bekommt. Für Maschinen sollte dieselbe Reihenfolge gelten.

Quelle: bleepingcomputer.com