Agenten mit Tools: Berechtigungen, Speicher und Fehlerbehebung gestalten, ohne die Kontrolle abzugeben

Vom Chatbot zum Agenten: kontextgebundene Autonomie statt blindem Vertrauen

Ein Agent ist nicht einfach ein Assistent, der in einer Unterhaltung antwortet. Für die Gestaltung ist eine operative Definition hilfreich: Er kombiniert ein Modell, das eine Aufgabe interpretiert, mit Ausführungszustand, Zugriff auf Tools, einer Richtlinie, welche die zulässigen Entscheidungen begrenzt, und einer Schleife, die Ergebnisse beobachtet und den nächsten Schritt auswählt. Er kann eine Datenbank abfragen, ein Ticket eröffnen, Informationen suchen, einen Datensatz aktualisieren oder eine API aufrufen. Der entscheidende Unterschied liegt nicht darin, dass das Modell „schlussfolgert“, sondern darin, dass das System andere Systeme außerhalb des Chatfensters beeinflussen kann.

Diese Unterscheidung verschiebt die Ausgangsfrage. Nicht „Welches Modell erzielt die besten Ergebnisse?“ sollte am Anfang stehen, sondern: „Was darf dieses System mit welcher Identität auf welchen Ressourcen und unter welchen Bedingungen tun?“ Die Leistungsfähigkeit eines Modells kann helfen, eine Aufgabe zu erledigen, ersetzt aber weder Autorisierungsgrenzen noch Ergebnisvalidierung oder Aufsicht. Das gilt auch bei Analysen zu GPT‑6 Astra, Claude Opus 5 oder Gemini 3.8 Flash: Höhere behauptete oder gemessene Fähigkeiten beseitigen nicht die Notwendigkeit operativer Kontrollen.

Nicht jede Aufgabe verlangt einen autonomen Agenten. Ein fester Ablauf mit vorhersehbaren Schritten und wenigen Ausnahmen lässt sich möglicherweise besser mit konventioneller Automatisierung oder einem Workflow lösen, in dem das Modell nur klassifiziert oder einen Vorschlag formuliert. Zusätzliche Autonomie muss durch die Variabilität der Aufgabe und die Fähigkeit, ihre Folgen einzugrenzen, gerechtfertigt sein. Als Ausgangsregel gilt: Eine externe Aktion sollte stärker beschränkt werden als eine Abfrage; eine schwer rückgängig zu machende Änderung braucht mehr Nachweise und Aufsicht als eine reversible Aktion.

Die empfohlene Einstiegskarte für die Übersichtsseite lautet „Agenten: Gestaltung, Bewertung und Aufsicht“. Von dort sollte dieser Leitfaden als Architektur- und Entscheidungsrahmen präsentiert werden, nicht als universelles Rezept oder als Anbieter vergleich.

Vor dem Anschluss eines Tools: die Auswirkungen jeder Aktion klassifizieren

Ein Tool sollte nicht aktiviert werden, nur weil es in einer Demonstration nützlich wirkt. Es braucht einen Aktionssteckbrief: Zweck, betroffene Systeme, empfangene Daten, verwendete Identität, zulässige Operationen, Mengenlimits, reversible oder irreversible Wirkung, externe Abhängigkeit und menschliche Verantwortung. Dieser Steckbrief macht einen häufig verdeckten Unterschied sichtbar: „Bestellungen abfragen“ und „Bestellungen stornieren“ können dieselbe API verwenden, bergen aber nicht dasselbe Risiko.

Die Klassifikation kann vier Achsen verbinden. Die Auswirkung schätzt den Schaden bei einer fehlerhaften Aktion; die Reversibilität bestimmt, ob sie sicher rückgängig gemacht werden kann; der Umfang misst, wie viele Konten, Datensätze oder Systeme betroffen sein können; und die Sensitivität bewertet offengelegte Daten oder Geheimnisse. Eine fünfte praktische Achse ist die Mehrdeutigkeit: Lässt eine Anfrage mehrere plausible Auslegungen zu, sollte die Aktion nicht autonom ausgeführt werden, selbst wenn dies technisch möglich wäre.

Externe Kommunikation verdient eine eigene Kategorie. Eine E-Mail an einen Kunden zu senden, eine Antwort zu veröffentlichen oder einen Vorgang anzulegen, kann technisch rückgängig zu machen sein, aber nicht unbedingt hinsichtlich Reputation, Vertrag oder Datenschutz. Dasselbe gilt für Änderungen in Produktion: Das Vorhandensein einer Rücksetzoperation macht eine fehlerhafte Bereitstellung nicht harmlos. Für diese Fälle sollte das Design eine Prüfung von Inhalt, Empfänger, Umfang und Ausführungszeitpunkt vorsehen.

Im ersten Drittel der Implementierung empfiehlt es sich, diese Klassifikation mit dem Leitfaden zu „irreversiblen Aktionen und Freigaben“ zu verbinden, sobald dieser veröffentlicht ist. Eine Freigabe soll keine allgemeine Bestätigungsgeste sein, sondern eine informierte Entscheidung über eine konkrete Aktion, ihre Parameter und mögliche Folgen.

Minimalprinzip bei Berechtigungen: Kontrollen, die nicht vom Modelltext abhängen

Minimal Privilege bedeutet, nur die Berechtigungen zu gewähren, die für eine klar abgegrenzte Aufgabe, für die erforderliche Dauer und für die notwendigen Ressourcen gebraucht werden. Bei Agenten erfordert dies mehr als ein allgemeines Token mit weitreichendem Zugriff. Eine Berechtigung zum Lesen, Bearbeiten und Löschen aller Ressourcen macht aus einer fehlerhaften Ausgabe, einer manipulierten Anweisung oder einem Integrationsfehler einen Vorfall mit großer Reichweite.

Eine belastbare Praxis besteht darin, Identitäten nach Tool, Umgebung und Zweck zu trennen. Der Support-Agent sollte nicht dieselbe Identität verwenden wie ein Bereitstellungsprozess, und eine Testidentität sollte keinen Zugriff auf Produktion haben. Kurzlebige Zugangsdaten verkleinern das Zeitfenster einer Exposition, beheben aber für sich genommen keine übermäßige Autorisierung: Erforderlich sind außerdem spezifische Zugriffsbereiche, Quoten, Netzwerkeinschränkungen und serverseitige Validierung.

Das Tool muss die Autorisierung deterministisch prüfen. Besser ist eine Schnittstelle mit konkreten Operationen – etwa einen Antwortentwurf für einen zugewiesenen Fall erstellen – als eine generische Schnittstelle, die beliebige Abfragen oder Befehle ausführen kann. Bei erlaubten Ressourcenlisten, Höchstbeträgen oder Rollen müssen diese Grenzen außerhalb des vom Modell veränderbaren Kontexts durchgesetzt werden. Prompt-Anweisungen können leiten, sind aber keine ausreichende Sicherheitsgrenze.

Konnektoren sollten sämtliche Inhalte aus Webseiten, Dokumenten, E-Mails, Tickets und Tool-Antworten als potenziell nicht vertrauenswürdige Daten behandeln. Dass ein Text einen Befehl enthält, verleiht ihm keine Autorität. Aktionsrichtlinie, Dienstidentität und Parameterprüfer müssen gegenüber jeder während der Aufgabe gefundenen Anweisung Vorrang haben.

Diese Sektion sollte, sobald verfügbar, auf „sensible Daten und Zugangsdaten“ verweisen. Für Teams, die personenbezogene Daten verarbeiten, bedeutet Datenminimierung auch, dem Tool nicht mehr Attribute zu übergeben als zur Ausführung nötig sind und festzulegen, wer auf die entstehenden Protokolle zugreifen darf.

Wann ein Mensch in den Entscheidungsprozess einbezogen werden muss

Menschliche Prüfung ist am nützlichsten, wenn sie in einen klar definierten Entscheidungspunkt eingebaut wird. Eine Bestätigung für jede risikoarme Abfrage verlangsamt die Arbeit und begünstigt mechanische Freigaben; auf sie bei relevanten Aktionen zu verzichten, verlagert die Last der Fehlererkennung auf diejenigen, die deren Folgen tragen. Das Design sollte explizite Schwellenwerte festlegen und der prüfenden Person die nötigen Informationen zur Entscheidung zeigen.

Eine Freigabe sollte die geplante Aktion, die endgültigen Parameter, die betroffenen Systeme, die ausführende Identität, die vom Agenten erzeugte Begründung sowie die Wirkung von Zustimmung oder Ablehnung anzeigen. Hängt die Aktion von unsicheren Tatsachen ab, sollte die Oberfläche auch diese Unsicherheit darstellen, statt eine Empfehlung als gesicherte Prüfung auszugeben. Eine abstrakte Absicht wie „den Fall lösen“ zu genehmigen, ist weniger sicher als eine abgegrenzte Operation wie „diesen Entwurf an diesen Empfänger senden“.

Als Ausgangspunkt sollten Löschungen, Zahlungen oder finanzielle Verpflichtungen, Produktionsänderungen, externe Kommunikation, Berechtigungsänderungen, die Verarbeitung besonders sensibler Kategorien und Vorgänge mit mehrdeutiger Anfrage menschlich geprüft werden. Die Organisation kann Schwellenwerte für Beträge, Anzahl der Datensätze oder operative Schwere ergänzen. Solche Schwellenwerte sind interne Richtlinienentscheidungen: Es gibt keinen universellen Wert, der eine Aktion sicher macht.

Menschliche Aufsicht darf auch nicht als Vorwand verstanden werden, das System sich selbst zu überlassen. Die prüfende Person braucht echte Befugnis, abzulehnen, zu korrigieren und zu eskalieren, Schulung zum Prozess und eine Arbeitslast, die sorgfältige Prüfung ermöglicht. Erhält sie Hunderte nahezu identischer Anfragen, kann die Kontrolle zu einer Formalität werden.

Nützlicher Speicher ohne unbegrenzte Aufbewahrung

Speicher kann die Kontinuität einer Aufgabe verbessern, vergrößert aber auch die Datenschutzfläche, das Risiko veralteter Informationen und die Schwierigkeit, Fehler zu korrigieren. Unterschieden werden sollten mindestens Sitzungs kontext, operativer Aufgabenstatus, autorisierte dauerhafte Präferenzen, aus Dokumentquellen abgerufenes Wissen und Auditprotokolle. Diese Kategorien erfüllen unterschiedliche Zwecke und sollten nicht automatisch dieselbe Aufbewahrung oder dieselben Berechtigungen teilen.

Der Sitzungskontext dient der Kohärenz während einer Interaktion und läuft in der Regel mit ihrem Ende oder nach kurzer Frist ab. Der operative Zustand bewahrt Angaben, die für die Fortsetzung einer Arbeit notwendig sind, etwa eine Fallreferenz oder einen Kontrollpunkt. Dauerhafte Präferenzen benötigen einen klaren Zweck, bekannte Herkunft und einen Mechanismus für Einsicht und Korrektur. Abgerufenes Wissen sollte Ursprung, Version und Datum enthalten, damit das System erkennen kann, ob die Quelle ersetzt oder ungültig wurde.

Die Herkunft ist ebenso wichtig wie der Inhalt. Stammt eine Erinnerung von einem Nutzer, einem Geschäftssystem oder einer Schlussfolgerung des Agenten selbst, sollte das System dies unterscheiden. Eine unbestätigte Schlussfolgerung – etwa eine abgeleitete Priorität oder Präferenz – darf nicht wie eine bestätigte Angabe behandelt werden. Außerdem darf dauerhafter Speicher nicht zu einem Weg werden, Geheimnisse, irrelevante Daten oder durch externe Inhalte eingeschleuste Anweisungen aufzubewahren.

Vor dem Speichern sind vier Fragen zu beantworten: Welchen konkreten Zweck erfüllt die Information, wer darf sie lesen, wann läuft sie ab und wie wird sie ungültig? Der künftige Leitfaden zu „Speicher, Aufbewahrung und Ablauf“ kann diese Richtlinien vertiefen. Enthält der Speicher im europäischen Kontext personenbezogene Daten, muss seine Gestaltung im Rahmen der geltenden Datenschutzpflichten bewertet werden; dieser Leitfaden ersetzt keine Rechtsprüfung und bestimmt nicht selbst die Rechtsgrundlage einer Verarbeitung.

Für Fehler gestalten: anhalten, prüfen und wiederherstellen

Fehler von Tools, Netzwerken und externen Abhängigkeiten sind normal. Das gilt ebenso für unvollständige Antworten, Zeitüberschreitungen und mehrdeutige Zustände: Ein Aufruf kann das Empfängersystem erreicht haben, obwohl der Agent keine Bestätigung erhielt. Ein robustes Design unterstellt nicht, dass ein „erneuter Versuch“ immer sicher ist. Zunächst muss es wissen, welche Operation versucht wurde, welches Ergebnis bestätigt ist und welche Operationen wiederholt werden können, ohne die Endwirkung zu ändern.

Die HTTP-Semantik unterscheidet idempotente Operationen, deren beabsichtigte Wirkung nach einer oder mehreren identischen Anfragen gleich bleibt, von nicht idempotenten. Das hilft bei der Gestaltung von Wiederholungen, ersetzt aber nicht die Prüfung des Geschäftszustands. Eine technisch idempotente Anfrage kann weiterhin unvorhergesehene Folgen haben, wenn ihre Parameter falsch sind. Für Erstellungs-, Zahlungs- oder Sendevorgänge sind ein Idempotenzschlüssel und eine Statusabfrage vor dem Wiederholungsversuch meist besser geeignet als ein blindes Wiederholen des Aufrufs.

Der Agent benötigt Abbruchbedingungen. Es sollten eine begrenzte Zahl von Versuchen, Zeitlimits, ein Aufrufbudget und Eskalationskriterien festgelegt werden. Nach Überschreiten eines Schwellenwerts muss der Fall mit dem minimal nötigen Kontext in eine Prüfwarteschlange gelangen: beabsichtigte Aktion, Korrelationskennung, erhaltene Antworten und bereits ausgeführte Schritte. Unbegrenzte Wiederholungen können einen externen Vorfall verstärken oder doppelte Aktionen erzeugen.

Jede relevante Aktion sollte vor ihrer irreversiblen Wirkung einen Kontrollpunkt und, soweit machbar, einen Kompensationsplan haben. Kompensation ist nicht immer eine perfekte Umkehrung: Eine Rückerstattung löscht keine bereits gesendete Nachricht, und die Wiederherstellung eines Datensatzes beseitigt keine mögliche Offenlegung. Die Wiederherstellungsdokumentation muss diese Grenzen ausdrücklich benennen.

Beobachtbarkeit und Auditierung ohne unnötige Datensammlung

Beobachtbarkeit ermöglicht die Rekonstruktion eines Vorgangs; sie verlangt nicht, alle ausgetauschten Daten unbegrenzt zu speichern. Für eine relevante Aktion sollte das Protokoll die Ausgangsanfrage, die angewandte Richtlinie, die gewählten Tools, autorisierte Parameter oder eine geschützte Darstellung davon, die Ausführungsidentität, das Ergebnis, Wiederholungen und menschliche Eingriffe verknüpfen. Korrelationskennungen erlauben es, einen Fall komponentenübergreifend zu verfolgen, ohne den vollständigen Inhalt in jedes Protokoll zu kopieren.

Protokolle müssen als sensible Werte geschützt werden. Enthalten sie Prompts, Antworten, Dokumente oder Parameter, können sie personenbezogene Daten, Geheimnisse oder nicht vertrauenswürdige Anweisungen umfassen. Sie benötigen daher Zugriffskontrollen, festgelegte Aufbewahrung, getrennte Umgebungen und Mechanismen gegen stille Änderungen. Hilfreich ist auch die Unterscheidung zwischen einem operativen Protokoll zur Fehlererkennung und einem Auditprotokoll zur Untersuchung einer Entscheidung; beide können unterschiedliche Detail- und Zugriffsstufen erfordern.

Eine gute Rekonstruktion trennt Fakten von Interpretation. Es muss erkennbar sein, welche Daten ein Tool geliefert hat, welche Regel eine Operation blockiert oder zugelassen hat und welche Empfehlung das Modell formulierte. Eine vollständige Erklärung jedes Modellverhaltens zu versprechen, wäre nicht angemessen; sehr wohl lassen sich jedoch die Kette programmatischer Entscheidungen und die operativen Artefakte aufzeichnen, die darüber bestimmen, ob eine Aktion ausgeführt wurde.

Datenminimierung ist nicht nur eine Datenschutzpflicht; sie verbessert auch Sicherheit und Nutzwert der Protokolle. Ein übermäßiges Log erschwert es, relevante Signale zu finden, und vergrößert die Menge der Daten, die bei unbefugtem Zugriff offengelegt werden könnten.

Vor dem Einsatz bewerten: Aufgabe, Berechtigungen und Wiederherstellung

Die Bewertung muss die Entscheidungsumgebung nachbilden und darf nicht nur die Qualität einer Textantwort messen. Ein Mindestplan verbindet repräsentative Aufgaben, Grenzfälle, Tool-Fehler, mehrdeutige Anfragen, Versuche, Anweisungen über externe Inhalte einzuschleusen, und Autorisierungsprüfungen. Das Erfolgskriterium muss sowohl die korrekte Ausführung einer erlaubten Aufgabe als auch die Ablehnung einer verbotenen Aktion, das Anhalten bei Unsicherheit und die Eskalation zum richtigen Zeitpunkt umfassen.

Benchmarks sind nützlich, um bestimmte Fähigkeiten unter definierten Bedingungen zu vergleichen. Terminal-Bench bewertet die Lösung von Aufgaben in isolierten Terminalumgebungen, während OSWorld Aufgaben in Web- und Desktop-Anwendungen in realen Bewertungsumgebungen bündelt. Solche Messungen können Hinweise auf die Leistung eines Agenten bei diesen Aufgaben geben, bescheinigen aber nicht, dass seine Identität über korrekte Berechtigungen verfügt, dass er Organisationsdaten schützt oder dass er sich in einer konkreten Integration sicher wiederherstellt.

Daher sollten, sobald verfügbar, Verweise auf Terminal-Bench und OSWorld aufgenommen werden, deren Ankertext klarstellt, dass Benchmarks Tests in der eigenen Umgebung nicht ersetzen. Interne Tests benötigen Testkonten, synthetische oder angemessen kontrollierte Daten, die Simulation von Abhängigkeiten und Wiederherstellungsszenarien. Sie müssen zudem prüfen, dass eine Autorisierungsablehnung keine alternativen, großzügigeren Pfade auslöst.

Ein Risikomanagementrahmen kann helfen, Verantwortlichkeiten zuzuweisen, Entscheidungen zu dokumentieren und Kontrollen über den gesamten Lebenszyklus zu überprüfen. Er ersetzt nicht die technische Spezifikation jeder Berechtigung. Testergebnisse, Vorfälle und Änderungen an Tools sollten regelmäßige Überprüfungen der Autonomiematrix speisen.

Abschließende Vorlage: das Autonomieniveau entscheiden

Die Autonomieentscheidung muss als Richtlinie überprüfbar sein und darf nicht implizit in einem Prompt bleiben. Dokumentieren Sie für jedes Tool und jede Aktion die Risikokategorie, beteiligte Daten, die konkrete Berechtigung, Identität, Grenzen, Freigabepflicht, Wiederherstellungsstrategie, Protokolle und verantwortliche Stelle. Ist eines dieser Elemente nicht definiert, ist die zugewiesene Autonomie wahrscheinlich verfrüht.

Ein sinnvoller Ausgangspunkt sind vier Stufen. Die Stufe Nur Lesen erlaubt das Abfragen autorisierter Ressourcen. Die Stufe Vorschlag mit Freigabe erlaubt Recherche und Vorbereitung einer Aktion, reserviert ihre Ausführung aber einer Person. Die Stufe Eingeschränkte Ausführung ermöglicht reversible und begrenzte Operationen unter deterministischen Regeln. Die autonome Ausführung bleibt Aktionen mit geringer Auswirkung, geringem Umfang, bekannter Umkehrung oder Kompensation, verfügbarer Aufsicht und ausreichenden Testnachweisen vorbehalten.

Die Matrix darf nicht dauerhaft sein. Ein Vorfall, ein Anbieterwechsel, ein neues Tool, eine Erweiterung zugänglicher Daten oder eine Änderung der Geschäftsrichtlinie rechtfertigen ihre Überprüfung. Ebenso kann ein Agent im Vorschlagsmodus beginnen und erst Autonomie gewinnen, nachdem er verlässliches Verhalten innerhalb eines messbaren Umfangs gezeigt hat. Nach einer Anomalie Autonomie zu verringern, ist eine Kontrollmaßnahme und kein Scheitern des Projekts.

Als nächster redaktioneller Schritt kann der Abschluss auf „entscheiden, ob ein Ablauf automatisiert werden soll“ verweisen. Die entscheidende Frage lautet nicht, ob ein Agent eine Aufgabe ausführen kann, sondern ob die Organisation seine Auswirkungen bei akzeptablem Risiko abgrenzen, beobachten und wiederherstellen kann.

Geltungsbereich und Unsicherheiten

Dieser Leitfaden stellt einen technischen und operativen Rahmen auf Grundlage der bereitgestellten institutionellen Quellen, technischen Dokumentation und Leitfäden zur Entwicklung von Agenten dar. Seine Architektur empfehlungen garantieren nicht für sich allein die Sicherheit eines Anwendungsfalls und ersetzen weder Tests, Bedrohungsanalysen, Datenschutzprüfungen, sektorspezifische Kontrollen noch Rechtsberatung.

Die Anwendung der Datenschutz-Grundverordnung hängt von den Umständen der Verarbeitung, den Rollen der Beteiligten und weiteren geltenden Anforderungen ab. Insbesondere entscheidet dieser Leitfaden nicht, ob ein konkreter Fall unter die Regeln für ausschließlich automatisierte Einzelfallentscheidungen fällt oder welche zusätzlichen Schutzmaßnahmen erforderlich sind. Er behandelt auch keine nationalen, arbeitsrechtlichen, finanziellen, gesundheitlichen oder vertraglichen Pflichten, die relevant sein können.

Eigenschaften von Tools, Modellen, APIs und Benchmarks ändern sich rasch. Vor dem Einsatz muss das Team die bewertete Version, das Verhalten der Integrationen, die wirksamen Berechtigungen und die Ausführungsbedingungen bestätigen. Nachweise aus einer Testumgebung dürfen nicht automatisch auf Produktion übertragen werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.