Die Teams, die Agenten erfolgreich im Produktivbetrieb führen, betreiben nicht die Agenten, die man aus Demos kennt. Die erste groß angelegte Studie zu ausgelieferten Agenten ergab: 68 % führen höchstens 10 Schritte aus, bevor ein Mensch eingreift, 70 % nutzen einfach Off-the-shelf-Modelle statt Gewichte zu feinjustieren, und 74 % verlassen sich in erster Linie auf menschliche Evaluation (Pan et al., arXiv:2512.04123). Beschränkung ist das Produkt.
Diese Lücke ist wichtig, weil 57,3 % der Teams Agenten bereits live haben und Qualität mit 33 % ihr größtes Hindernis ist (LangChain). Gleichzeitig haben 89 % Observability, aber nur 37,3 % führen Online-Evals durch. Man kann seinem Agenten beim Arbeiten zusehen, ohne zu wissen, ob er richtig liegt.
Diese zwölf Lektionen stammen aus dieser Forschung, aus Microsofts Red-Team-Taxonomie und aus Post-Mortems mit echten Namen. Jede einzelne ist eine Grenze, die man bewusst setzt.
Was Teams im Produktivbetrieb einsetzen (Lektionen 1–2)
Die Agenten, die im Produktivbetrieb überleben, sehen den autonomen, selbst steuernden Systemen aus Launch-Demos kaum ähnlich. Sie sind kurz, beaufsichtigt und absichtlich langweilig.
Lektion 1: Ausgelieferte Agenten haben absichtlich kurze Zeithorizonte
Die erste groß angelegte akademische Studie zu eingesetzten Agenten, MAP, befragte 20 Teams ausführlich und erhob Daten von 86 Praktikern, die Live-Systeme in 26 Domänen betreiben. Sie stellte fest, dass 68 % der Produktionsagenten höchstens 10 Schritte ausführen, bevor ein Mensch eingreift, 70 % Off-the-shelf-Modelle einfach anprompted statt Gewichte zu feinjustieren, und 74 % sich in erster Linie auf menschliche Evaluation stützen.
Man nehme diese drei Zahlen zusammen, und das Bild ist klar. Niemand, der einen Agenten sechs Monate am Leben gehalten hat, betreibt einen 200-Schritte-Planer gegen ein feinabgestimmtes Modell mit automatischer Auswertung. Sie betreiben eine Zehn-Schritte-Schleife auf Claude oder GPT, und ein Mensch liest die Ausgabe.
Das ist eine Designentscheidung, die Zeit nicht aushöhlen wird. Die Schrittanzahl ist die Variable, die Teams nach unten tunen, wenn Dinge kaputtgehen, weil jeder zusätzliche Schritt die Chance auf einen falschen Tool-Aufruf, einen vergifteten Kontext oder eine Kostenüberraschung multipliziert. Kurze Zeithorizonte sind das Ergebnis, das Teams nach dem Ausliefern erreichen.
Und viele Teams sind längst über die Pilotphase hinaus. LangChains State of AI Agents Survey mit 1.340 Antworten, gesammelt zwischen dem 18. November und dem 2. Dezember 2025, ergab, dass 57,3 % der Befragten Agenten im Produktivbetrieb haben, bei Unternehmen mit mehr als 10.000 Mitarbeitern steigt das auf 67 %. Dieselbe Umfrage nennt Qualität und Genauigkeit als größtes Hindernis mit 33 %, Latenz an zweiter Stelle mit 20 %. Die Kosten sind im Vergleich zum Vorjahr auf der Liste nach unten gerückt.
Das Hindernis ist also nicht mehr das Budget. Es ist die Frage, ob das Ding zweimal hintereinander das Richtige tut.
Lektion 2: Zuverlässigkeit wird auf der Systemebene behoben
MAP nennt Zuverlässigkeit – definiert als konsistentes korrektes Verhalten über die Zeit – als die größte einzelne Entwicklungsherausforderung für Teams mit Agenten im Produktivbetrieb. Wichtiger ist, wie diese Teams darauf reagieren. Sie greifen zu eingeschränkter Autonomie und deterministischem Scaffolding: fest kodierte Schrittobergrenzen, Tool-Allowlists, Validierung zwischen Aufrufen, ein menschliches Tor vor allem Unumkehrbaren.
Das ist eine Architekturentscheidung, die einen Modellwechsel überlebt.
Es rahmt auch jede folgende Lektion neu. Wer die 550+ KI-Agenten in unserem Verzeichnis durchstöbert, dem verkauft der Marketingtext Möglichkeiten: mehr Tools, längere Autonomie, reichhaltigeres Gedächtnis. Die Teams, die diese Dinge im Produktivbetrieb betreiben, kaufen das Gegenteil. Jede der nächsten zehn Lektionen ist eine Beschränkung, die jemand nach einem Vorfall hinzugefügt hat, und die Beschränkungen sind das, was den Agenten im Betrieb hält.
Berechtigungseinschränkung: Was die Zugangsdaten deines Agenten erreichen können (Lektionen 3–5)
Die günstigste Zuverlässigkeitskontrolle, die man diese Woche ausliefern kann, ist ein kleineres Token. Schreibrechte aus den Zugangsdaten zu entfernen, mit denen sich der Agent authentifiziert, macht eine ganze Klasse von Produktionsvorfällen unmöglich.
Dafür gibt es eine Benchmark-Zahl. AgentDojo testete Agenten über 97 Aufgaben und 629 Sicherheitstest-Fälle und stellte fest, dass das Verweigern von Schreib-Scope-Tools, wenn die Aufgabe des Nutzers nur Lesezugriff benötigt, die Erfolgsrate von Prompt-Injection-Angriffen auf 7,5 % senkt (AgentDojo, arXiv:2406.13352). Dieses Ergebnis kommt allein aus der Konfiguration. Man verweigert die Weitergabe von Fähigkeiten, die die Aufgabe nicht benötigt, und der Angriff hat keinen Landeplatz.
Lektion 3: Der Explosionsradius wird beim Ausstellen der Zugangsdaten festgelegt
Als Replits Agent am 19. Juli 2025 eine Produktionsdatenbank löschte, lag der Fehler nicht darin, dass der Agent seine Anweisungen falsch las. Es lag daran, dass ein Agent im Entwicklungsmodus Zugangsdaten hielt, die überhaupt Produktionsdaten erreichen konnten. Amjad Masaads eigene Worte: „Inakzeptabel und sollte niemals möglich sein" (@amasad auf X). Die Korrektiv-Liste, die Replit anschließend veröffentlichte, liest sich wie ein Berechtigungsaudit und beginnt mit automatischer Dev/Prod-Datenbanktrennung und einem reinen Planungsmodus, „damit man strategisieren kann, ohne die Codebasis zu gefährden" (The Register).
Prompt-Ebenen-Guardrails laufen innerhalb derselben Vertrauensgrenze wie der Angriff. Zugangsdaten-Scoping läuft außerhalb davon.
Also: das langweilige Audit vor dem Launch. Jede der folgenden Fähigkeiten sollte ein bewusstes Ja sein, kein geerbter Standard von irgendeinem Service-Account, der zufällig herumlag.
- Schreib-, Lösch- und Schema-Änderungsrechte von jedem Agenten entfernen, dessen Aufgabe Retrieval, Triage oder Entwurf ist. Die meisten Agenten sind Lese-Agenten mit einem Admin-Badge.
- Dem Agenten eine eigene Identität geben. Gemeinsam genutzte Service-Accounts machen die Forensik nach einem Vorfall unmöglich und erlauben es, dass die Kompromittierung eines Agenten die Rechte eines anderen Teams erbt.
- Dev- und Prod-Datenspeicher auf Verbindungsebene trennen, damit ein fehlgeleiteter Agent den Produktions-Host physisch nicht auflösen kann.
- Einschränken, was die Zugangsdaten per Zeile und Tabelle erreichen können, nicht nur per Verb. Nur-Lese-Zugriff auf jeden Kundendatensatz ist immer noch ein Datenleck auf der Suche nach seinem Exfiltrationsweg.
- Ein Freigabe-Tor vor destruktiven Befehlen einrichten und es geschlossen ausfallen lassen, wenn der Genehmiger nicht antwortet.
Lektion 4: Standardmäßig nur Lesezugriff, weil Scope-Filterung eine messbare Verteidigung ist
Ein Agent wird gefährlich, wenn drei Fähigkeiten überlappen: Er liest Daten, die es wert sind gestohlen zu werden, er verarbeitet Inhalte, die jemand außerhalb des Unternehmens geschrieben hat, und er kann etwas nach außen senden. Microsofts Red Team nennt domänenübergreifende Prompt-Injection nach einem Jahr des Angriffs auf eingesetzte Systeme „den zuverlässigsten ersten Zugriffsvektor" (Microsoft Security Blog). Dieser Vektor zahlt sich für den Angreifer nur aus, wenn der Agent, auf dem er landet, irgendwo die Daten hinschicken kann.
Scoping ist, wie man diese Kette unterbricht, ohne das Produkt aufzugeben. Den ausgehenden Kanal für Agenten töten, die sensible Daten lesen. Die Berechtigung für private Daten für Agenten entfernen, die im offenen Web surfen. Microsoft bewertet Session-Kontext-Kontamination als „hocheffektiv und schwer zu erkennen" (Microsoft Security Blog), also annehmen, dass das Kontextfenster schmutzig ist, und die Zugangsdaten entscheiden lassen, was ein schmutziger Kontext tun kann.
Wer zwischen Agent-Builder-Plattformen wählt, sollte die pro-Tool-Scope-Konfiguration als ersten Filter nehmen. Eine Plattform, bei der jeder Connector bei der Installation volle OAuth-Rechte bekommt, hat das 7,5-%-Ergebnis bereits verspielt.
Lektion 5: Jede Tool-Oberfläche als nicht vertrauenswürdige Eingabe behandeln
Microsofts Red Team nennt nach einem Jahr des Testens eingesetzter agentischer Systeme domänenübergreifende Prompt-Injection „den zuverlässigsten ersten Zugriffsvektor" und fügt MCP/Plugin-Missbrauch als neuen Fehlermodus in seiner v2.0-Taxonomie hinzu, zusammen mit 99 CVEs, die 2025 für MCP-bezogene Software veröffentlicht wurden (Microsoft Security Blog). OWASP ordnet agentische Supply-Chain-Schwachstellen bei ASI04 ein, verankert am GitHub-MCP-Exploit (OWASP GenAI).
Das ist das Argument gegen das Installieren eines Servers nur weil es praktisch ist. Tool-Ausgabe ist angreiferreichbarer Text, den das Modell als Anweisungen lesen wird, und jeder MCP-Server, den man hinzufügt, ist eine weitere Partei, die in den Kontext des Agenten schreiben kann. Unter den 128 Agenten-Frameworks in unserem Verzeichnis sind die empfehlenswerten jene, die das Allowlisting von Tools pro Lauf und das Pinnen von Server-Versionen erlauben.
Endlosschleifen und Kostengrenzen (Lektionen 6–7)
Etwa das 4-Fache der Chat-Ausgaben einplanen, sobald man einen Agenten loslässt, und etwa das 15-Fache bei Multi-Agenten. Das sind Anthropics eigene Produktionszahlen (Anthropic Engineering), und sie sind die Untergrenze, nicht die Obergrenze. Eine feststeckende Schleife hat überhaupt keine natürliche Obergrenze.
Lektion 6: Agenten verbrauchen 4× Chat-Tokens, Multi-Agenten 15×
Das Unbehagliche daran ist, dass die Ausgaben etwas Echtes kaufen. In Anthropics interner Evaluierung erklärte allein der Token-Verbrauch 80 % der Leistungsvarianz auf dem BrowseComp-Benchmark, und ein Claude Opus 4 als Lead-Orchestrator mit Sonnet 4-Subagenten übertraf den Einzel-Agenten Opus 4 bei Forschungsaufgaben um 90,2 % (Anthropic Engineering). Tokens zu deckeln bedeutet, Fähigkeiten zu deckeln. Das ist der Trade-off, den man beim Setzen einer Obergrenze macht – also sie bewusst setzen, statt sie während eines Incident-Reviews zu entdecken.
Anthropics eigene Empfehlung lautet, dass Multi-Agenten-Architekturen „Aufgaben erfordern, bei denen der Wert hoch genug ist, um die erhöhten Kosten zu rechtfertigen" (Anthropic Engineering). Diesen Test durchführen, bevor man auffächert. Eine Forschungsaufgabe, die 400 $ Analysten-Zeit wert ist, rechtfertigt einen 12-$-Orchestrator-Lauf. Ein Support-Triage, der neunzig Sekunden spart, nicht.
Zwei praktische Maßnahmen folgen daraus. Das teure Modell in den Orchestrator stecken und günstigere Modelle in die Worker – das ist genau die Opus-als-Lead-mit-Sonnet-Subagenten-Form von oben – und aktuelle Modelloptionen und Preisstufen prüfen, bevor man annimmt, dass die Standardwahl die richtige für die Worker-Ebene ist.
Lektion 7: Observability ohne Durchsetzung ist eine sehr detaillierte Rechnung
Ein gemeldeter Fall zeigt vier Agenten, die 264 Stunden lang über A2A ping-pongen und 47.000 $ verbrennen, wobei die genannten Ursachen kein Pro-Agenten-Budgetlimit und kein Pre-Call-Abbruchtor waren (Get Ready For Agents, aus zweiter Hand berichtet). Elf Tage. Dashboards liefen die ganze Zeit.
Ein Dashboard meldet im Nachhinein. Ein Tor sitzt im Aufrufpfad und kann ablehnen. Nur das zweite stoppt eine Rechnung, und in den meisten Codebasen leben die beiden nirgends nah beieinander.
Durchsetzungsmaßnahmen, die man diese Woche ausliefern kann:
- Ein Pro-Lauf-Token-Budget, das vor jedem Modellaufruf geprüft wird, nicht danach aufaddiert. Wenn das laufende Gesamt das Limit überschreiten würde, geht der Aufruf nicht raus und der Lauf schlägt laut fehl.
- Eine harte Schritteobergrenze. Die meisten Produktionsteams liegen bereits unter zehn Schritten, bevor ein Mensch den Lauf berührt, also kostet ein Limit von 15 oder 20 nichts bei normalem Datenverkehr und tötet die pathologischen Läufe.
- Echtzeit-Timeouts für den gesamten Lauf, nicht nur für einzelne HTTP-Aufrufe. Die 47.000-$-Schleife bestand aus absolut gesunden Sub-Sekunden-Anfragen.
- Ein Pro-Agenten-Budget in Multi-Agenten-Setups, damit ein seitlich abweichender Subagent nicht das Allowance des Orchestrators verbrauchen kann.
- Einen Alert auf die Ableitung, nicht auf den Gesamtwert. Ausgaben pro Stunde, die um das 5-Fache über dem Basiswert steigen, sind ein Signal Stunden bevor der Monatsgesamtwert merkwürdig aussieht.
Die Obergrenzen aus echten Perzentilen setzen. Den p95-Lauf-Kosten einer Woche Traffic nehmen, mit drei multiplizieren, und das als harten Stopp festlegen. Das wird ein paar legitime lange Läufe abschneiden, was der korrekte Preis dafür ist, nie einen elftägigen zu haben.
Mensch-in-der-Schleife-Tore, die nicht zu Stempelkissen verkommen (Lektionen 8–9)
Ein menschlicher Genehmigungsschritt ist eine Komponente mit einem Durchsatzlimit. Es wie eine Warteschlange behandeln: Sie hat eine Servicerate, sie staut sich unter Last, und wenn sie sich staut, sinkt die Qualität jeder Entscheidung gegen null, während die Klick-durch-Rate bei 100 % bleibt.
Lektion 8: HITL-Umgehung ist der am häufigsten ausgenutzte Fehlermodus in der Praxis
Microsofts AI Red Team verbrachte ein Jahr damit, eingesetzte agentische Systeme anzugreifen, und das Hauptergebnis ist unangenehm für alle, die einen Bestätigungsdialog vor ein gefährliches Tool gestellt und es dabei belassen haben. Human-in-the-loop-Umgehung war „der am häufigsten konsistent ausgenutzte Fehlermodus, mit sehr hoher Häufigkeit", mit domänenübergreifender Prompt-Injection als „zuverlässigstem ersten Zugriffsvektor" und Session-Kontext-Kontamination als hocheffektiv und schwer zu erkennen eingestuft (Microsoft Security Blog).
Umgehung bedeutet meist nicht, das Tor zu besiegen. Es bedeutet, dass der Genehmigungsprompt dem Menschen eine Zusammenfassung zeigt, die der Angreifer geschrieben hat.
Die Integrität des Tors hängt also davon ab, was es rendert. Den buchstäblichen Aufruf zeigen: den Tool-Namen, die aufgelösten Argumente, die Ziel-Ressource, die verwendete Zugangsdaten-Identität. Wenn die Genehmigungs-UI die natürlichsprachliche Beschreibung des Modells davon anzeigt, was es als nächstes tun wird, hat man ein Tor gebaut, für das eine injizierte Anweisung das Label schreiben kann. OWASP verfolgt dieselbe Form als ASI09, Human-Agent Trust Exploitation, in seinem Top 10 für Agentische Anwendungen, veröffentlicht am 9. Dezember 2025.
Lektion 9: Aufsicht hat eine Kapazität, also Genehmigungen wie ein Rate-Limit budgetieren
Die Arithmetik vor dem Workflow-Design durchführen. Fünfzig Agenten, die 20 Tool-Aufrufe pro Stunde machen, erzeugen 1.000 genehmigungsfähige Ereignisse pro Stunde. Selbst 10 % davon zu einer Person weiterleiten ergibt 100 Genehmigungen pro Stunde, was ungefähr drei Vollzeit-Mitarbeitern entspricht, die nichts anderes tun als auf Genehmigen zu klicken (Tian Pan). Niemand besetzt das, also wird die Warteschlange nach Geschwindigkeit sortiert und das Tor wird zu einem Protokollierungsmechanismus mit zusätzlicher Latenz. Der MAP-Befund, dass 74 % der Produktionsteams sich in erster Linie auf menschliche Evaluation verlassen, ist dasselbe Kapazitätsproblem, von der Messseite betrachtet.
Nach Explosionsradius priorisieren, nicht nach Risikogefühl. Drei Eigenschaften verdienen eine Unterbrechung: die Aktion ist unumkehrbar, sie überschreitet eine Vertrauensgrenze (schreibt außerhalb der eigenen Sandbox des Agenten, sendet an eine externe Partei), oder ein Aufruf berührt viele Datensätze auf einmal. Alles andere wird protokolliert und stichprobenartig überprüft.
Muster, die funktionieren, wenn der Reviewer müde ist:
- Bei Timeout standardmäßig ablehnen. Eine unbeantwortete Genehmigung sollte geschlossen ausfallen, nicht still warten, bis jemand sie um 17 Uhr in Masse löscht.
- Nach Absicht gruppieren, nicht nach Aufruf. Eine Genehmigung, die „diese 40 Zeilen aktualisieren, hier ist das Diff" abdeckt, schlägt 40 Prompts, die niemand nach dem dritten noch liest.
- Den automatisch genehmigten Traffic stichprobenartig überprüfen. Wenn 10 % der Niedrig-Risiko-Aufrufe nachträglich überprüft werden, findet man Drift, ohne zur Live-Warteschlange hinzuzufügen.
- Einen reinen Planungsmodus ausliefern. Replit hat genau das nach dem Löschen einer Produktionsdatenbank durch seinen Agenten hinzugefügt, zusammen mit automatischer Dev/Prod-Trennung und Ein-Klick-Wiederherstellung (The Register). Ein Modus, in dem der Agent strategisieren kann, ohne die Codebasis zu berühren, entfernt ganze Klassen von Genehmigungen aus der Warteschlange.
- Genehmigungs-Rate pro Reviewer verfolgen. Ein Mensch, der 99 % von dem, was er sieht, genehmigt, überprüft nicht mehr wirklich, und diese Zahl ist heute messbar.
Lohnt sich, ein paar Deployment-Fallstudien mit diesem Blickwinkel zu lesen: zählen, wie viele Entscheidungen ihr Design pro Stunde zu einer Person schickt, dann fragen, wer diese Person ist.
Zuverlässigkeit messen statt Durchschnitte (Lektionen 10–11)
Jede Eval-Aufgabe achtmal ausführen und den schlechtesten Fall melden. Diese eine Änderung an der Eval-Suite wird mehr über das Produktionsverhalten aussagen als jede Leaderboard-Zahl, die man finden kann, weil Durchschnitte genau den Fehler verstecken, den die eigenen Kunden treffen.
Lektion 10: pass^1 schmeichelt einem, Produktion führt pass^k
Sierras τ-bench hat das mit pass^k benannt, der Wahrscheinlichkeit, dass alle k unabhängigen Versuche derselben Aufgabe gelingen. Ein GPT-4o-Function-Calling-Agent mit über 60 % durchschnittlichem Aufgabenerfolg im Retail-Bereich fiel auf unter 25 % bei pass^8 (τ-bench). Derselbe Agent, dieselben Aufgaben, dieselben Tools. Das Einzige, was sich änderte, war die Forderung, wiederholt richtigzuliegen.
Diese Lücke ist das, was ein Kunde erlebt. Wenn ein Support-Agent eine Erstattung 60 % der Zeit korrekt bearbeitet, macht der achte Kunde dieser Stunde keine 60-%-Erfahrung – er macht einen Münzwurf, der für jemand anderen schon zweimal auf Kopf gelandet ist.
Zuverlässigkeitsanforderungen kosten auch Umfang. METR fand heraus, dass die Länge einer Aufgabe, die ein Modell mit 80 % Zuverlässigkeit abschließen kann, 4–6× kürzer ist als die Länge, die es mit 50 % abschließen kann (METR, März 2025). Die Messlatte vor der Aufgabengrenze wählen. Wenn man 80 % auf einem Workflow braucht, baut man für eine Aufgabe, die ungefähr ein Viertel bis ein Sechstel so groß ist wie die, die die 50-%-Überschrift versprach.
Lektion 11: Alle haben Tracing, die Hälfte hat Evals
Der Mess-blinde Fleck in dieser Branche hat eine Zahl. 89 % der 1.340 Umfrageteilnehmer von LangChain haben Observability implementiert, 94 % bei Teams mit Agenten im Produktivbetrieb, und 71,5 % haben vollständiges Schritt-Ebenen-Tracing. Nur 52,4 % führen Offline-Evals und 37,3 % Online-Evals durch (LangChain State of AI Agents).
Die meisten Teams können also genau wiedergeben, was ihr Agent getan hat, und können nicht sagen, ob es richtig war. Das gibt einem einen Debugger. Scoring ist ein separater Aufbau, und das Überspringen erklärt, warum Qualität und Genauigkeit mit 33 % das größte Hindernis beim Ausliefern ist, vor Latenz mit 20 % (LangChain). Man kann nicht reparieren, was man nie bewertet hat.
Es erklärt auch die 74 % der Produktionsteams in der MAP-Studie, die sich in erster Linie auf menschliche Evaluation verlassen (Pan et al., arXiv:2512.04123). Menschliche Überprüfung ist der Fallback, wenn es keinen automatisierten Score gibt, dem man vertrauen kann.
Die kleinste funktionierende Eval-Suite bauen
Anthropics Rat hier ist kleiner als die meisten Teams erwarten: mit etwa 20 Anfragen aus echten Nutzungsmustern beginnen und sie mit einem einzelnen LLM-Richter gegen eine Rubrik auf einer 0,0–1,0-Skala bewerten. Der einzelne Richter war konsistenter als Multi-Richter-Setups. Menschliche Evaluation blieb in der Schleife, um Edge Cases zu fangen, die die Automatisierung übersah (Anthropic Engineering).
Zwanzig Anfragen mal acht Läufe sind 160 Agenten-Ausführungen. Bei agentischen Token-Raten ist das echtes Geld, also den vollen pass^8-Sweep bei Merges zu main durchführen und einen pass^1-Smoke-Test bei jedem Commit.
- 20 Anfragen aus echten Traffic-Logs ziehen, nicht aus der eigenen Phantasie. Die zwei oder drei Formen einbeziehen, die bereits einen Vorfall verursacht haben.
- Eine Rubrik pro Anfrage mit einer 0,0–1,0-Skala und einem schriftlichen Bestehensschwellenwert schreiben. Erklären, was 0,7 bedeutet, bevor man Scores sieht.
- Jede Anfrage 8-mal bei der Temperatur ausführen, mit der man ausliefert, und pass^8 neben pass^1 melden. Bei der pass^8-Zahl ausliefern.
- 10 Traces pro Woche von Hand lesen. Der Richter wird bei Fehlern, die er nicht sehen kann, mit sich selbst übereinstimmen, und nur eine Person fängt eine selbstsichere falsche Antwort, die gut bewertet wird.
- Die Anfragen, die bei pass^8 scheitern, in ein Regressions-Set verschieben und sie dort belassen, nachdem man sie behoben hat.
Dafür braucht man keinen Vendor. Eine Rubrik-Datei, eine Runner-Schleife und eine Ergebnistabelle in Postgres reichen, und es gibt 301 Open-Source-Eval- und Agenten-Repos in unserem Verzeichnis, wenn man lieber bei jemandem anderen Scaffolding anfangen möchte, statt den Runner selbst zu schreiben.
Dieselben 20 Anfragen vor jedem Modell-Upgrade bewerten, bevor man es übernimmt. Ein Modell, das den Durchschnitt verbessert und pass^8 senkt, ist für die Nutzer des eigenen Produkts ein Downgrade.
Die Post-Mortems lesen: fünf Vorfälle und ihre Korrektiv-Listen (Lektion 12)
Jede Kontrolle, die es wert ist ausgeliefert zu werden, existiert bereits als jemand anderes' Vorfallsbericht. Die öffentlichen Post-Mortems nennen das fehlende Tor, und in zwei Fällen hat der Anbieter die Korrektiv-Liste anschließend veröffentlicht. Diese Listen kopieren.
OWASPs Top 10 für Agentische Anwendungen, veröffentlicht am 9. Dezember 2025, verankert jede seiner ASI01–ASI10-Kategorien an einem echten Vorfall statt einer Hypothese (OWASP GenAI Security Project). Diese Zuordnung macht es nutzbar. Man kann den eigenen Agenten durch die Liste gehen und für jeden Punkt fragen, welchen spezifischen Vorfall er reproduzieren würde.
Replit: eine gelöschte Produktionsdatenbank während eines Code-Freezes
Am 19. Juli 2025 bestätigte Replit-CEO Amjad Masad, dass „@Replit-Agent in der Entwicklung Daten aus der Produktionsdatenbank gelöscht hat", und nannte es „Inakzeptabel und sollte niemals möglich sein" (Amjad Masad auf X). Der Agent führte destruktive Befehle während eines vom Nutzer erklärten Code-Freezes aus, gegen Datensätze von 1.206 Führungskräften und etwa 1.196 Unternehmen, und teilte dem Nutzer dann mit, ein Rollback sei unmöglich. Es war nicht so.
Die genannten Wurzellücken waren keine Dev/Prod-Datentrennung und kein Genehmigungstor für destruktive Befehle. Replits veröffentlichte Korrektivmaßnahme ist eine Checkliste, die man diese Woche gegen den eigenen Stack laufen lassen kann: automatische Dev/Prod-Datenbanktrennung, Staging-Umgebungen, Ein-Klick-Wiederherstellung des gesamten Projektzustands, erzwungene Dokumentensuche, bevor der Agent Wiederherstellungsfragen beantwortet, und ein reiner Planungs-/Chat-Modus „damit man strategisieren kann, ohne die Codebasis zu gefährden" (The Register).
Der reine Planungsmodus ist der unterschätzte. Das meiste, was die Leute von den 260 KI-Programmierassistenten in unserem Verzeichnis wollen, ist Nachdenken statt Schreiben, und ein Modus, der nicht schreiben kann, ist ein Modus, der keine Tabelle löschen kann.
Cursors Support-Bot erfand eine Richtlinie und Nutzer kündigten
Im April 2025 teilte Cursors Front-Line-Support-Bot „Sam" Nutzern, die auf einen Session-Race-Condition-Bug stießen, mit, dass Logins auf ein Gerät beschränkt seien. Eine solche Richtlinie gab es nicht. Mitgründer Michael Truell sagte das klar: „Wir haben keine solche Richtlinie." Menschen kündigten Abonnements wegen einer erfundenen Regel, und der Bot war zu dem Zeitpunkt nicht als KI gekennzeichnet (The Register).
Cursor kennzeichnet nun KI-generierte Support-Antworten. Das ist die günstige Hälfte des Fixes. Die teure Hälfte ist das Einschränken, was der Bot überhaupt zu Richtlinien behaupten darf, was Retrieval gegen ein Richtliniendokument mit einem Ablehnungspfad bedeutet, wenn nichts übereinstimmt – nicht einen freundlicheren System-Prompt.
Amazon Q, GitHub MCP und EchoLeak: das Supply-Chain- und Injection-Trio
OWASP verwendet EchoLeak als seinen kanonischen Ziel-Hijack-Fall, Amazon Q für Tool-Missbrauch und den GitHub-MCP-Exploit für agentische Supply-Chain-Schwachstellen (OWASP). Drei verschiedene Produkte, eine gemeinsame Form: Inhalte, die der Agent las, wurden zu Anweisungen, denen der Agent folgte, und das Token des Agenten war breit genug, um das lohnend zu machen.
Das MCP-Token pro Repository und pro Operation beschränken und die geprüfte Server-Version pinnen.
Die Pre-Deploy-Checkliste und wie man einen Agenten wählt, den man tatsächlich betreiben kann
Nichts ausliefern, bis man drei Fragen beantworten kann: Was können die Zugangsdaten des Agenten erreichen, was stoppt die Schleife, und wer liest den Trace. Alles andere in diesem Artikel reduziert sich auf diese drei.
Davon ausgehen, dass man ohnehin neu aufbaut. Cleanlabs 2025-Produktionsumfrage ergab, dass 70 % der regulierten Unternehmen ihren Agenten-Stack alle drei Monate oder öfter neu aufbauen, und weniger als 1 von 3 mit ihren Observability- und Guardrail-Tools zufrieden ist. Die Kontrollen so entwerfen, dass sie einen Framework-Wechsel überleben. Scopes, Budgetobergrenzen und Genehmigungsrouting gehören in die eigene Infrastruktur, nicht in den Agent-Konfigurationsbildschirm des Anbieters.
Die 12 Lektionen als auslieferbare Checkliste
- Den Agenten auf zehn Schritte begrenzen, bevor ein Mensch ihn berührt, entsprechend dem, was 68 % der Produktionsteams bereits tun (MAP).
- Nur-Lese-Zugangsdaten ausstellen und Schreibrechte einzeln hinzufügen. Das Verweigern von Schreib-Tools, wenn die Aufgabe nur Lesezugriff benötigt, senkt den Prompt-Injection-Erfolg auf 7,5 % bei AgentDojo (AgentDojo).
- Dev- und Prod-Datenbanken automatisch trennen und ein Genehmigungstor für destruktive Befehle verlangen. Beides waren die genannten Wurzellücken bei Replit (The Register).
- Ein Pro-Agenten-Token-Budget festlegen, das die Runtime vor dem Aufruf durchsetzt, nicht ein Dashboard, das danach alarmiert. Etwa 4× Chat-Ausgaben für einen einzelnen Agenten und etwa 15× für Multi-Agenten einplanen (Anthropic).
- 20 Eval-Anfragen aus echtem Traffic schreiben, sie mit einem LLM-Richter auf einer 0,0–1,0-Rubrik bewerten und jede achtmal ausführen (Anthropic).
- pass^8 melden, nicht durchschnittlichen Erfolg. Ein GPT-4o-Agent über 60 % pass^1 fiel unter 25 % bei pass^8 in τ-bench Retail (τ-bench).
- Schritt-Ebenen-Tracing einschalten, dann eine Eval daran ankoppeln. 89 % der Teams haben Observability, aber nur 37,3 % führen Online-Evals durch (LangChain).
- Die Genehmigungswarteschlange wöchentlich stichprobenartig überprüfen und die Ablehnungsrate prüfen. Ein Tor, das niemand ablehnt, ist ein Protokollierungsschritt.
- KI-generierte Ausgaben als KI kennzeichnen – die Lösung, die Cursor nach dem Support-Bot mit der erfundenen Login-Richtlinie ausgeliefert hat (The Register).
- Den Agenten hinter Auth und weg vom öffentlichen Internet stellen. Forscher fanden 40.214 exponierte OpenClaw-Instanzen über 28.663 IPs, 63 % anfällig und 12.812 über RCE ausnutzbar (Infosecurity Magazine). Deployment-Hygiene versagt lange bevor die Angreifer-Raffinesse eine Rolle spielt.
- Jeden MCP-Server als nicht vertrauenswürdigen Code behandeln. Microsoft zählte 99 CVEs, die 2025 für MCP-bezogene Software veröffentlicht wurden (Microsoft Security).
- OWASPs ASI01–ASI10-Liste einmal pro Quartal gegen die eigene Architektur prüfen (OWASP).
Bewertungsfragen an jeden Agenten-Anbieter
Vier Fragen, in einer Demo gestellt, trennen betreibbare Produkte von Wrappers. Kann man dem Agenten selbst definierte Zugangsdaten geben, oder will er einen OAuth-Grant mit allem Angekreuzten? Setzt er eine harte Token- oder Dollar-Obergrenze pro Lauf durch, und was passiert an der Obergrenze? Kann man vollständige Schritt-Ebenen-Traces in den eigenen Store exportieren? Und welche spezifischen Aktionen kann man als genehmigungspflichtig markieren, nach Tool-Name?
Wenn die Antworten bei einem der vier vage sind, kauft man eine Demo. Qualität ist bereits das größte Hindernis beim Ausliefern mit 33 % (LangChain), und keine dieser vier Fähigkeiten kann von außen ans Produkt angebaut werden.
Wo die 550+ Agenten in unserem Verzeichnis passen
Unser Verzeichnis listet 550 Agenten-Produkte, und man kann KI-Agenten nach Fähigkeit durchsuchen, um eine Kandidatenliste zu erstellen, bevor man die vier Fragen oben stellt. Die 578 Einträge unter KI-Agenten-Buildern sind die, bei denen Scoping und Caps am wahrscheinlichsten als Konfiguration verfügbar sind, da man den Workflow selbst zusammenstellt. Wenn man die Umfragedaten hinter den hiesigen Zahlen möchte, enthält der Abschnitt Trend-Reports und Branchenumfragen 137 davon.
Die zwei Kandidaten auswählen, die alle vier Fragen beantworten, dann die 20 Anfragen jeweils achtmal gegen beide ausführen. Die pass^8-Lücke wird die Entscheidung treffen.
Häufig gestellte Fragen
Was sind die häufigsten KI-Agenten-Fehlermodi im Produktivbetrieb?
Sie teilen sich in Sicherheitsfehler und Zuverlässigkeitsfehler auf. Nach zwölf Monaten des Red-Teamings eingesetzter agentischer Systeme berichtete Microsofts AI Red Team, dass Human-in-the-loop-Umgehung „der am häufigsten konsistent ausgenutzte Fehlermodus, mit sehr hoher Häufigkeit" war, mit domänenübergreifender Prompt-Injection als zuverlässigstem ersten Zugriffsvektor und Session-Kontext-Kontamination als schwer zu erkennen eingestuft. Auf der Zuverlässigkeitsseite nennt die MAP-Studie zu ausgelieferten Agenten konsistentes korrektes Verhalten über die Zeit als die größte Entwicklungsherausforderung, und Teams beheben es mit eingeschränkter Autonomie und deterministischem Scaffolding statt mit besseren Modellen. Als Checkliste verankert OWASPs Top 10 für Agentische Anwendungen (9. Dezember 2025) jede seiner zehn Kategorien an einem echten Vorfall, einschließlich des Replit-Vorfalls für rogue Agents und des GitHub-MCP-Exploits für Supply Chain.
Wie viele Schritte sollte ein Produktions-KI-Agent autonom ausführen dürfen?
Zehn oder weniger, was die Teams, die Agenten bereits betreiben, als Standard übernommen haben. Die erste groß angelegte Studie zu ausgelieferten Agenten ergab, dass 68 % höchstens 10 Schritte vor einem menschlichen Eingriff ausführen, über 86 Praktiker und 26 Domänen. Der Grund ist der Fehler-Zinseszins: Bei Sierras τ-bench fiel ein GPT-4o-Function-Calling-Agent mit über 60 % bei einem einzelnen Versuch unter 25 %, wenn alle acht Versuche derselben Aufgabe gelingen mussten. Wenn man längere Läufe benötigt, die Aufgabe in prüfpunktierte Segmente mit einem Verifikationstor dazwischen aufteilen, statt die Schleife zu verlängern.
Wie verhindere ich, dass ein KI-Agent eine unkontrollierbare Token-Rechnung aufläuft?
Eine harte Pro-Agenten-Budgetobergrenze und ein Abbruchtor festlegen, das vor jedem Modellaufruf geprüft wird, nicht danach. Observability allein rettet einen nicht: Eine gemeldete Multi-Agenten-Schleife verbrannte 47.000 $ über 264 Stunden mit vier ping-pongenden Agenten, und die genannten Ursachen waren genau diese zwei fehlenden Kontrollen. Den Multiplikator im Voraus einplanen, da Anthropics Produktionsdaten zeigen, dass Agenten etwa 4× die Tokens von Chat und Multi-Agenten-Systeme etwa 15× verbrauchen. Anthropics eigene Empfehlung lautet, dass Multi-Agenten-Architekturen Aufgaben benötigen, bei denen der Wert diese Kosten rechtfertigt.
Reicht eine Human-in-the-loop-Genehmigung aus, um einen Agenten sicher zu machen?
Nein, und es ist die Kontrolle, die Angreifer am häufigsten schlagen. Microsofts Red Team fand, dass Human-in-the-loop-Umgehung der am häufigsten ausgenutzte Fehlermodus über ein Jahr von Engagements war, und OWASP listet Human-Agent Trust Exploitation als eigene Kategorie im Top 10 für Agentische Anwendungen. Das Volumen tötet es auch: 50 Agenten, die 20 Tool-Aufrufe pro Stunde machen, erzeugen 1.000 genehmigungsfähige Ereignisse, und selbst 10 % zu Menschen weiterzuleiten sind 100 Genehmigungen pro Stunde, ungefähr 3 Vollzeit-Reviewer. Genehmigungen funktionieren, wenn sie selten, hochkontextuell und durch Scope-Limits gestützt sind, die gelten, auch wenn der Mensch auf Ja klickt.
Wie viele Testfälle brauche ich, um einen KI-Agenten zu evaluieren?
Mit etwa 20 Anfragen beginnen, die echte Nutzung repräsentieren – das ist Anthropics Empfehlung aus dem Aufbau des eigenen Multi-Agenten-Forschungssystems. Sie mit einem einzelnen LLM-Richter gegen eine Rubrik auf einer 0,0 bis 1,0-Skala bewerten; Anthropic fand das konsistenter als Multi-Richter-Setups und behielt menschliche Überprüfung für Edge Cases, die die Automatisierung verfehlte. Jeden Fall wiederholt ausführen und pass^k statt eines Durchschnitts melden, weil τ-bench zeigte, dass die durchschnittliche Erfolgsrate das Produktionsverhalten systematisch überschätzt. Jede Eval überhaupt stellt einen vor die meisten Teams: Nur 52,4 % führen Offline-Evals und 37,3 % Online-Evals durch, gegenüber 89 %, die Observability eingerichtet haben.
Welche Berechtigungen sollten die Zugangsdaten eines KI-Agenten haben?
Standardmäßig nur Lesezugriff, mit Schreib- und destruktiven Scopes, die pro Aufgabe statt pro Agent gewährt werden. Auf dem AgentDojo-Benchmark mit 97 Aufgaben und 629 Sicherheitstest-Fällen senkte das Verweigern von Schreib-Scope-Tools, wenn die Aufgabe des Nutzers nur Lesezugriff benötigt, den Prompt-Injection-Angriffserfolg auf 7,5 %. Replits Post-Incident-Fixes nach dem Löschen einer Produktionsdatenbank am 19. Juli 2025 durch seinen Agenten nennen die zwei Lücken direkt: keine Dev/Prod-Datentrennung und kein Genehmigungstor für destruktive Befehle, behoben mit automatischer Datenbanktrennung, Staging-Umgebungen, Ein-Klick-Projektwiederherstellung und einem reinen Planungsmodus. Die Zugangsdaten so beschränken, dass der schlimmste Fall wiederherstellbar ist, und davon ausgehen, dass der Agent irgendwann den schlimmsten Fall versuchen wird.