Ein Modell kann einen perfekt formulierten Werkzeugaufruf generieren, zu dessen Ausführung der aktuelle Benutzer jedoch nicht berechtigt ist. Eine strukturierte Ausgabe hilft der Anwendung, die Anfrage zu verstehen; sie erteilt jedoch keine Berechtigung zu deren Ausführung.
Ich entwerfe einen werkzeugnutzenden Agenten als Planer, der innerhalb einer anwendungsgesteuerten Ausführungsgrenze arbeitet. Das Modell schlägt die nächste Aktion vor. Der Servercode entscheidet, ob die Aktion zulässig ist und wie ihr Ergebnis zurückgegeben werden kann.
Stellen Sie sicher, dass der Tool-Vertrag die Risiken und den Umfang beschreibt
Eine Tool-Definition erfordert mehr als nur einen Namen und ein JSON-Schema. Ich möchte wissen, ob das Tool Daten liest oder ändert, welche Berechtigungen es benötigt, wie der Mandantenbereich festgelegt wird und ob der Vorgang genehmigt werden muss.
Die Validierung von Argumenten sollte sowohl die Struktur als auch die Bedeutung umfassen. Eine gültige Zeichenfolge kann dennoch den Datensatz eines anderen Mandanten identifizieren. Eine wohlgeformte URL kann dennoch auf eine interne Netzwerkressource verweisen. Eine numerische Größe kann außerhalb des zulässigen Geschäftsbereichs liegen.
Zunächst würde ich eine kleine Auswahl nützlicher, schreibgeschützter Werkzeuge bereitstellen. Dadurch lässt sich die Anzahl der Ausführungsverhalten reduzieren, die vor der Einführung von Schreiboperationen nachgewiesen werden müssen.
Bei Ausführung der Aktion erneut autorisieren
Die Anwendung sollte zum Zeitpunkt der Ausführung die aktuellen Berechtigungen des Benutzers und den Eigentümer der Zielressource ermitteln. Eine vom Modell bereitgestellte Mandanten-ID oder Rolle sollte niemals als Berechtigungsgrundlage akzeptiert werden.
Dies ist bei mehrstufigen Abläufen von Bedeutung. Die Mitgliedschaft kann sich ändern, eine Ressource kann verschoben werden oder eine in der Warteschlange stehende Aktion kann ausgeführt werden, nachdem ihr ursprünglicher Kontext abgelaufen ist. Die Autorisierung sollte keine einmalige Eigenschaft der ersten Nachricht der Konversation sein.
Das gleiche Prinzip gilt für die Genehmigung. Eine Genehmigung sollte an eine bestimmte Handlung und die dafür relevanten Argumente geknüpft sein. Wenn der Akteur das Ziel oder den Betrag nachträglich ändert, entspricht die frühere Genehmigung nicht mehr dem, was tatsächlich geschehen wird.
Externe Inhalte sollten in einer eigenen Vertrauenskategorie verbleiben
Eine abgerufene Seite, eine Kundenmitteilung oder ein Tool-Ergebnis kann Anweisungen enthalten, die an das Modell gerichtet sind. Diese Anweisungen erhalten nicht allein dadurch Gültigkeit, dass sie im Kontextfenster erscheinen.
In den OWASP-Leitlinien zur Prompt-Injektion wird das Risiko erörtert, dass nicht vertrauenswürdige Inhalte das Verhalten des Modells beeinflussen. Meine Ausführungsgrenze geht davon aus, dass der Planer in die Irre geführt werden kann, verhindert jedoch dennoch, dass er die vom Servercode durchgesetzten Berechtigungsgrenzen überschreitet.
Auch die von Tools ausgegebenen Daten sollten auf ein Minimum beschränkt werden. Wenn für die Aufgabe ein Bestellstatus benötigt wird, führt die Rückgabe aller Kundenfelder zu einer unnötigen Offenlegung. Sensible Felder können weggelassen oder unkenntlich gemacht werden, bevor das Ergebnis das Modell erreicht.
Die Schleife abgrenzen, nicht nur jeden einzelnen Aufruf
Ein nützlicher Agent benötigt Obergrenzen für die Anzahl der Werkzeugiterationen, die verstrichene Zeit, die Gesamtkosten und wiederholte Fehlschläge. Obergrenzen pro Aufruf reichen nicht aus, wenn der Planer unbegrenzt weitere Aufrufe starten kann.
Ich unterscheide zwischen produktivem Fortschritt und wiederholten Versuchen mit denselben Argumenten. Wenn eine Suche zweimal kein Ergebnis liefert, ist der nächste sinnvolle Schritt möglicherweise eher eine klärende Frage als eine dritte Variante derselben Suche.
Ein Vorgang sollte in einem klar erkennbaren Status enden: beantwortet, klärungsbedürftig, zur Genehmigung ausstehend, an eine Person weitergeleitet oder mit einem behebbaren Grund fehlgeschlagen. Das sorgt sowohl für mehr Klarheit bei der Benutzeroberfläche als auch bei der Arbeit des Bedieners.
Eine Aktionsspur aufzeichnen, die ein Mensch überprüfen kann
Das Prüfprotokoll sollte das vorgeschlagene Tool, die validierten Argumente, die Genehmigungsentscheidung, die entsprechende Genehmigung, den Status des Ergebnisses und den zeitlichen Ablauf enthalten. Es ist nicht erforderlich, private Modellüberlegungen offenzulegen, um die Entscheidungen der Anwendung zu erläutern.
Bei externen Schreibvorgängen füge ich eine stabile Vorgangs-ID und eine Idempotenzstrategie hinzu. Bei einer Wiederholung des Planungsschritts darf eine bereits abgeschlossene Geschäftsaktion nicht erneut ausgeführt werden.
Bei den ersten Adversarial-Tests, die ich durchführe, wird ein gewöhnlicher Benutzer aufgefordert, die Daten eines anderen Mandanten abzurufen, Anweisungen in das Ergebnis eines Tools einzufügen, Argumente nach der Genehmigung zu ändern und eine bereits abgeschlossene Aktion zu wiederholen. Der Agent erhält nur dann mehr Autonomie, wenn diese Grenzen verständlich und durchsetzbar bleiben.
Aktualisiert am 25. September 2026.