Definieren Sie kleine domänenspezifische Tools mit einem präzisen Eingabe- und Ausgabeschema. Prüfen Sie Argumente auf dem Server, beurteilen Sie Berechtigungen anhand von Identität und Objekt, legen Sie schreibende oder unumkehrbare Aktionen zur Bestätigung vor und führen Sie sie idempotent aus. Protokollieren Sie Entscheidung und Ergebnis ohne Geheimnisse und testen Sie schädliche Kombinationen von Aufrufen.
Tool Calling ermöglicht es dem Modell, die Anwendung über eine definierte Funktion um das Abrufen von Daten oder das Ausführen einer Aktion zu bitten. Das Modell besitzt das Tool jedoch nicht direkt, und seine Argumente dürfen nicht als vertrauenswürdig gelten. Die Anwendungsschicht muss jeden Aufruf validieren, autorisieren und entscheiden, ob sie ihn ausführt, ablehnt oder eine Bestätigung durch einen Menschen einholt.
Das sicherste Tool hat einen eng gefassten Zweck, ein kleines Schema und ein vorhersehbares Ergebnis. Allgemeine Tools wie „Anfrage ausführen“ oder „SQL ausführen“ übertragen zu viel Verantwortung auf das Sprachmodell. Lesen und Schreiben werden getrennt, sensible Werte erscheinen nicht im Kontext, und jede ausgeführte Aktion bleibt mit dem Benutzer, dem Vorgang und einem Audit-Trail verknüpft.
Gestalten Sie Tools nach Arbeitsabsicht
Ein Tool sollte eine konkrete Fähigkeit benennen, zum Beispiel eine Bestellung anhand einer berechtigten Kennung finden oder einen Vorschlag zur Terminänderung vorbereiten. Das Modell wählt dann aus klaren Optionen. Universeller Zugriff auf die Datenbank, Dateien oder beliebige URLs vergrößert den Spielraum für Missbrauch und erschwert das Audit. Was das Modell für das jeweilige Ziel nicht benötigt, sollten Sie gar nicht erst zugänglich machen.
Trennen Sie Lesen, Vorschlag und Ausführung. Ein Tool kann zunächst eine Vorschau der Auswirkungen und ein stabiles Vorschlags-Token zurückgeben; ein separater Schritt führt die Änderung nach der Bestätigung aus. Unterstützt das System Massenoperationen, begrenzen Sie die Anzahl der Objekte und zeigen Sie diese dem Benutzer an. Namen und Beschreibungen der Tools sollten auch bei ähnlichen Prozessen eindeutig sein.
Validieren Sie das Schema und die geschäftliche Bedeutung der Argumente
Das Eingabeschema schränkt Typen, Pflichtfelder, Länge, Format und zulässige Werte ein. Der Server lehnt unbekannte Felder und unerwartete Wertebereiche ab. Das Schema allein reicht jedoch nicht: Ein Datum kann formal korrekt sein, aber außerhalb des zulässigen Zeitraums liegen, und eine Kennung kann zu einem anderen Kunden gehören. Fachliche Regeln werden bei jedem Aufruf außerhalb des Modells ausgeführt.
Das Modell darf Benutzeridentität, Tenant oder Rolle nicht als maßgebliches Argument liefern. Die Anwendung leitet sie aus der verifizierten Sitzung ab. Unterscheiden Sie bei der Arbeit mit Text zwischen Inhalten, die gespeichert werden sollen, und internen Anweisungen. Erlauben Sie URLs nur anhand einer Allowlist und von Netzwerkregeln, damit das Tool aufgrund einer eingeschleusten Anweisung keine internen Dienste oder nicht vertrauenswürdigen Adressen abruft.
- exaktes Schema ohne unerwartete Felder
- Serverseitig abgeleitete Identität, Rolle und Tenant
- fachliche Grenzwerte über die Formatprüfung hinaus
- sichere Positivliste erlaubter Ziele und Operationen
Erzwingen Sie die Berechtigungsprüfung bei jedem Objekt
Die Autorisierung wird unmittelbar vor dem Lesen oder Ändern geprüft, nicht nur beim Öffnen des Chats. Ein Nutzer kann Zugriff auf ein Projekt haben, auf ein anderes jedoch nicht, obwohl er dasselbe Tool verwendet. Filtern Sie das Ergebnis auf der Datenebene. Das Modell erhält nicht einmal den Namen eines gesperrten Objekts, da bereits dessen Existenz sensibel sein kann.
Eine Dienstidentität hat nur die minimal notwendigen Rechte und handelt nach Möglichkeit im delegierten Kontext des Nutzers. Ein langlebiger, weitreichender Schlüssel für alle Tools erschwert Widerruf und Untersuchung. Bei einem Rollenwechsel oder dem Ende einer Sitzung wirkt sich die Rechteänderung sofort aus, auch im Cache. Eine Ablehnung liefert eine sichere Information ohne Details, die das Ausprobieren fremder Kennungen erleichtern würden.
Bestätigen Sie sensible Aktionen und behandeln Sie Wiederholungen
Zeigen Sie dem Menschen vor dem Senden einer Nachricht, einem Löschvorgang, einer finanziellen Transaktion oder der Änderung eines wichtigen Status das Ziel, die Werte und die erwartete Wirkung. Die Bestätigung bezieht sich auf einen konkreten, unveränderlichen Entwurf und wird nach einer Änderung erneut eingeholt. Ein pauschales „alle weiteren Aktionen erlauben“ entspricht keiner informierten Entscheidung. Manche Operationen können vollständig außerhalb der Reichweite des Modells bleiben.
Das Tool verwendet einen Idempotenzschlüssel und gibt einen eindeutigen Status zurück, da ein Timeout zu einer Wiederholung führen kann. Das Modell darf bei einem unklaren Ergebnis nicht automatisch einen anderen Weg mit derselben Wirkung versuchen. Zuerst wird der Status der ursprünglichen Operation geprüft. Entwerfen Sie einen Kompensationsschritt für Fälle, die sich sicher rückgängig machen lassen, und eskalieren Sie bei einem Teilerfolg mit präzisem Kontext.
Testen Sie Kombinationen und prüfen Sie die tatsächliche Wirkung
Die Tests umfassen ungültige Argumente, fremde Objekte, entzogene Berechtigungen, doppelte Aufrufe, Timeouts, schädliche Inhalte aus Dokumenten und Versuche, Tools entgegen dem vorgesehenen Zweck zu verketten. Eine simulierte Umgebung ermöglicht Tests ohne Auswirkungen auf die Produktion. Bewerten Sie nicht nur, was das Modell angefordert hat, sondern auch die serverseitige Entscheidung und den endgültigen Zustand des Zielsystems.
Ein Audit-Trail verknüpft die Benutzerabsicht, die Modellanfrage, das validierte Argument, das Autorisierungsergebnis, die Bestätigung und die Kennung der ausgeführten Aktion. Schwärzen Sie Geheimnisse und vollständige sensible Inhalte. Das Monitoring warnt bei steigenden Ablehnungen, ungewöhnlichen Werkzeugen, Schleifen und unerwartetem Volumen. Ein einzelnes Werkzeug muss sich schnell abschalten lassen, ohne den gesamten Assistenten stillzulegen.
Häufige Fragen
Kann das Modell eine Funktion direkt ausführen?
Das Modell schlägt nur den Namen des Werkzeugs und die Argumente vor. Die Anwendungsschicht muss sie validieren, autorisieren und je nach Risiko eine Bestätigung einholen; erst dann führt sie die eigentliche Funktion aus.
Warum reicht ein JSON-Eingabeschema nicht aus?
Das Schema prüft das Format, nicht aber die Zugehörigkeit des Objekts, Geschäftsregeln oder die Berechtigung des Nutzers. Diese Prüfungen muss der Server bei jedem Aufruf durchführen.
Welche KI-Tools erfordern eine Bestätigung?
Vor allem solche, die senden, ändern, veröffentlichen, bezahlen oder löschen und eine erhebliche oder schwer umkehrbare Auswirkung haben. Die genaue Grenze ergibt sich aus dem Risiko der Organisation.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
