Tool Use bei KI-Agenten: APIs sicher und kontrolliert ausführen

Das Wichtigste in Kürze:

• Tool Use heißt: Ein Agent ruft selbstständig APIs, Datenbanken oder Systemfunktionen auf.
• Jedes Tool braucht ein präzises Schema mit Name, Beschreibung und Parametern.
• Eingaben in beide Richtungen prüfen, Rechte minimal halten, kritische Aktionen freigeben lassen.
• Jeder Tool-Aufruf wird mit 5 Angaben protokolliert, vom Zeitpunkt bis zum Kontext.

Ein Support-Agent, der Tickets nicht nur kategorisiert, sondern auch im CRM aktualisiert, oder ein Einkaufs-Assistent, der nicht nur einen Bestellvorschlag formuliert, sondern die Bestellung direkt auslöst. Ein Recherche-Agent, der nicht nur zusammenfasst, sondern selbst in einer Datenbank sucht. Der Unterschied zwischen einem KI-System, das nur redet, und einem, das handelt, ist Tool Use. Genau dieser Schritt vom Text zur Aktion macht KI-Agenten für Unternehmen interessant und zugleich riskant.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU. Gemeint sind Teams, die einen Agenten mit echtem Systemzugriff planen oder bereits im Einsatz haben. Er beantwortet konkret, was Tool Use technisch bedeutet. Er zeigt, wie man APIs als Tools beschreibt und welche Eingaben geprüft werden müssen. Dazu kommt, wie man Aktionen begrenzt und den Betrieb protokolliert. Eine eigene Risikomatrix hilft bei der Einordnung deiner Tools.

Direkt beantwortet: Was bedeutet Tool Use?

Tool Use bezeichnet die Fähigkeit eines KI-Agenten, während seiner Arbeit selbstständig externe Werkzeuge aufzurufen. Gemeint sind etwa eine API, eine Datenbankabfrage oder ein E-Mail-Versand statt reiner Textausgabe. So beschreibt es auch die Tools-Agent-Dokumentation von n8n (2026).

Das Sprachmodell erhält eine Beschreibung jedes Tools inklusive Parametern. Es wählt bei Bedarf das passende aus und füllt die Parameter. Dann liest es das Ergebnis, bevor es weiterplant. Genau dieser Systemzugriff macht Agenten nützlich. Er wird zum Sicherheitsthema, sobald ein Tool tatsächlich etwas verändern kann.

Begriffe kurz geklärt

Diese 4 Begriffe werden häufig unscharf verwendet.

• Tool: eine einzelne, dokumentierte Funktion, die der Agent aufrufen kann, etwa ein API-Aufruf, eine Datenbankabfrage oder eine Berechnung.
• Tool-Schema: die strukturierte Beschreibung eines Tools mit Name, Zweck, erwarteten Parametern samt Typ und Bedeutung, manchmal auch Beispielaufrufen.
• Function Calling / Tool Calling: der Mechanismus, mit dem das Sprachmodell anhand der Schemata entscheidet, ob und welches Tool es aufruft, und die Parameter formuliert.
• Human-in-the-Loop: ein eingebauter Haltepunkt, an dem ein Mensch eine geplante Aktion bestätigen oder ablehnen muss, bevor sie wirkt.

Das Sprachmodell liest dabei das Schema, nicht den zugrunde liegenden Code. n8n unterscheidet etwa zwischen der HTTP Request Node im normalen Modus und ihrem Tool-Modus mit eigener Beschreibung für das Sprachmodell. Die Tools Agent Node implementiert den Aufruf über die Schnittstelle der angebundenen Sprachmodelle.

Wichtig ist die Abgrenzung nach unten. Ein Chatbot, der nur Text generiert und keine Systeme aufruft, betreibt kein Tool Use, seine Risiken liegen woanders. Sobald ein System eigenständig Aktionen mit Außenwirkung auslösen kann, verändert sich die Risikolage grundlegend. Dann braucht es Kontrolle.

Wie definiert man APIs als Tools?

Ein Agent braucht mehr als den nackten Endpunkt. Nötig ist eine Beschreibung, die dem Sprachmodell erklärt, wann und wie das Tool einzusetzen ist. In n8n hängst du dafür eine HTTP-Request-Node an eine Agenten-Node und versetzt sie in den Tool-Modus. Das Modell bekommt dann Name, Beschreibung und die erwarteten Parameter des Aufrufs zur Auswahl vorgelegt. Bei direkter API-Anbindung an ein Sprachmodell übernimmt ein vergleichbares Tool-Schema dieselbe Rolle.

Diese 3 Punkte entscheiden in der Praxis über die Qualität der Definition.

• Präzise Beschreibung statt technischer Kurzform: „Sucht Kunden“ ist zu vage. Besser: „Sucht einen Kunden anhand der Kundennummer und gibt Name, Adresse und offene Rechnungen zurück, nicht geeignet für Namenssuche“.
• Enger Parameter-Zuschnitt: Je weniger ein Tool gleichzeitig kann, desto vorhersehbarer sein Einsatz. Ein Tool, das nur eine Bestellung anlegt, ist leichter zu prüfen als ein generisches Tool für beliebige Datenbank-Schreibzugriffe.
• Antwort-Optimierung: Die HTTP Request Node filtert im Tool-Modus Antworten vor der Übergabe an das Modell, etwa auf relevante JSON-Felder statt der vollständigen Rohantwort.

Das senkt Kosten. Und es reduziert, welche Daten überhaupt im Kontext des Modells landen. Wer Tools zu breit oder zu vage definiert, bekommt keine kontrollierbaren Agenten. Er bekommt ein System, dessen Verhalten man erst versteht, wenn etwas schiefgelaufen ist.

Welche Eingaben müssen validiert werden?

Bei Tool Use gibt es 2 Richtungen der Validierung. Beide werden in der Praxis regelmäßig übersehen.

Erstens: was der Agent an ein Tool schickt. Parameter, die das Modell selbst formuliert, sollten vor der Ausführung geprüft werden. Das gilt für eine Kundennummer genauso wie für einen Betrag oder einen Freitext. Typprüfung, Wertebereiche und Plausibilitätschecks gehören dazu, ebenso das Verhindern offensichtlich unsinniger Kombinationen. Eingaben reicht man auch bei jeder anderen Softwareschnittstelle nicht ungeprüft durch.

Zweitens: was der Agent aus externen Quellen liest. Dieser Punkt wird häufig unterschätzt. Sprachmodelle unterscheiden Anweisungen und normalen Inhalt nicht zuverlässig auf strukturelle Weise. Das BSI beschreibt dieses Risiko unter „fehlerhafter Reaktion auf Eingaben“. Ein LLM kann einen Satz in einer Webseite, E-Mail oder einem Dokument als Anweisung interpretieren, obwohl es den Inhalt nur zusammenfassen soll.

Die Folge: Eine angebundene Anwendung führt unautorisierte Aktionen aus. Sie löst etwa ungewollte Käufe aus oder löscht E-Mails, wenn sie entsprechende Aktions- und Zugriffsmöglichkeiten hat. Dieses Muster heißt Indirect Prompt Injection.

Aus dieser Beobachtung leitet die BSI-Publikation konkrete Gegenmaßnahmen ab. Eingaben mit manipulativer oder böswilliger Absicht sollen möglichst erkannt und gefiltert werden. Dafür eignen sich Klassifikatoren, die verdächtige Muster im Klartext prüfen, nicht erst auf Embedding-Ebene, wo semantische Information verloren geht. Ergänzend hilft es, Nutzereingaben technisch von Fremdinhalten abzugrenzen. So kann das Modell zwischen der eigentlichen Anweisung der Nutzerin und eingeschleusten Anweisungen aus einer verarbeiteten Quelle unterscheiden.

Für die Praxis heißt das: Jedes Tool, das externe Inhalte in den Kontext des Agenten einspeist, ist ein potenzieller Angriffsweg. Ein durchsuchtes Dokument, eine abgerufene Webseite oder eine eingehende E-Mail braucht dieselbe Vorsicht wie direkter Nutzerinput. Ohne Ausnahme.

Wie beschränkt man Aktionen?

Die wirksamste Einzelmaßnahme ist nicht bessere Erkennung im Nachhinein, sondern enge Rechte von vornherein. Weniger Rechte, weniger Schaden. Das BSI formuliert es so: Zugriffs- und Ausführungsrechte LLM-basierter Anwendungen sollten auf das notwendige Minimum beschränkt werden. Dazu gehören klare Vertrauensgrenzen zwischen Modell, Anwendung, externen Ressourcen und erweiterten Funktionalitäten. Zusätzlich kann das Ausführen potenziell kritischer Aktionen von einer expliziten Zustimmung der Nutzenden abhängen, etwa über einen Bestätigungs-Button.

Genau diesen Mechanismus hat n8n im Januar 2026 als eigenes Feature eingeführt. Agenten lassen sich seit Version 2.6.0 so konfigurieren, dass sie vor der Ausführung bestimmter Tools eine explizite menschliche Freigabe einholen. Gedacht ist das für „high-impact“-Operationen wie das Löschen von Datensätzen, Schreibzugriffe auf Produktivsysteme oder das Versenden wirkungsvoller E-Mails. Damit erreichst du deterministische Kontrolle über genau die Aktionen, bei denen ein Fehler am teuersten wäre.

Eigene Risikomatrix: Tool-Typen und passende Kontrolle

Nicht jedes Tool braucht dieselbe Kontrolltiefe. In meiner Arbeit ordne ich Tools vor der Umsetzung nach Wirkung ein. Das verhindert Über- wie Untersicherung.

• Lesend, intern (Kundendaten abrufen, Dokument suchen): kein Schreibzugriff, es reichen Zugriff nur auf notwendige Datenfelder und Logging.
• Schreibend, intern, geringe Tragweite (Ticket kategorisieren, Notiz anlegen): leicht rückgängig zu machen, Logging und stichprobenartige Prüfung genügen.
• Schreibend, intern, hohe Tragweite (Auftrag im ERP anlegen, Preis ändern): nur teilweise und mit Aufwand umkehrbar, braucht engen Parameter-Zuschnitt und Freigabe ab Schwellenwert.
• Schreibend, extern sichtbar (E-Mail an Kunden senden, Social-Media-Post): kaum umkehrbar ohne Reputationsschaden, braucht Freigabe vor jeder Ausführung und Vorlagen statt Freitext, wo möglich.
• Finanziell wirksam (Bestellung auslösen, Zahlung anstoßen): nicht oder nur mit Aufwand umkehrbar, braucht Freigabe vor jeder Ausführung, Betragsobergrenze und Vier-Augen-Prinzip.

Eigene Einordnung Philogic Labs, abgeleitet aus Umsetzungsprojekten und den Empfehlungen des BSI zur Rechtebeschränkung (M17) und Ausführung mit Zustimmung.

Die Grundregel dahinter: Je schwerer eine Aktion rückgängig zu machen ist und je größer ihre Außenwirkung, desto näher rückt die menschliche Kontrolle an den Ausführungszeitpunkt. Für lesende Tools reicht in der Regel ein enger Datenzugriff plus Protokollierung, für Tools mit finanzieller oder externer Wirkung gehört die Freigabe dagegen vor die Ausführung, nicht danach.

Wie protokolliert man?

Ohne Log kein Nachweis. Ohne Protokollierung lässt sich weder ein Fehler nachvollziehen noch ein Angriff erkennen. Das BSI empfiehlt für LLM-basierte Anwendungen ein Logging, das interne Aufrufe, die Nutzung von Erweiterungen und Informationsflüsse ab der ursprünglichen Nutzereingabe nachvollziehbar macht. Rechtliche Anforderungen sind dabei zu beachten, besonders bei personenbezogenen Daten in Aufrufen oder Ergebnissen. Ein automatisiertes Monitoring hilft, unerwünschtes Verhalten früh zu erkennen, egal ob es aus normaler Nutzung oder einem Angriff stammt.

Für ein KMU-Setup halte ich 5 Angaben pro Tool-Aufruf für das praktikable Minimum. Mehr braucht es selten.

1. Zeitpunkt des Aufrufs.
2. Aufgerufenes Tool mit Version oder Konfigurationsstand.
3. Verwendete Parameter, vollständig, außer bei besonders sensiblen Werten, die maskiert protokolliert werden.
4. Ergebnis des Aufrufs, inklusive Fehlermeldungen.
5. Auslösende Nutzereingabe oder auslösender Kontext, damit sich der gesamte Entscheidungspfad nachvollziehen lässt.

Reine Protokollierung reicht nicht, wenn niemand hinschaut. Für kritische Tools lohnt sich ergänzend eine einfache Regel-Auswertung. Ein Beispiel: eine Benachrichtigung bei ungewöhnlich vielen Aufrufen desselben Tools in kurzer Zeit oder bei Aufrufen außerhalb der üblichen Betriebszeiten. Das ersetzt kein dediziertes Security-Monitoring. In der Praxis deckt es aber die meisten offensichtlichen Fehlfunktionen ab.

Umsetzung: So gehe ich vor

Diese 6 Schritte haben sich in meinen Projekten bewährt.

1. Tool-Inventar erstellen: erst die vollständige Liste der Systeme, die der Agent anfassen soll, dann die Einordnung nach der Risikomatrix oben.

2. Pro Tool ein Schema schreiben: Name, präzise Beschreibung, Parameter mit Typ und Grenzen, erwartetes Rückgabeformat, nicht nur den Endpunkt verdrahten.

3. Antworten filtern: nur die für die Aufgabe relevanten Felder an das Modell durchreichen, das senkt Kosten und Angriffsfläche.

4. Freigabepunkte vor dem Produktivstart festlegen: für jedes Tool mit hoher oder externer Wirkung ist geklärt, wer worauf mit welcher Frist freigibt.

5. Logging von Anfang an aktivieren: ein System ohne Protokoll aus der Testphase liefert im Ernstfall keine Antworten.

6. Mit engem Tool-Set starten: drei sauber definierte, gut geprüfte Tools sind fünfzehn halbherzig beschriebenen vorzuziehen.

Wer erst eine grundsätzliche Einordnung sucht, findet die Grundlagen im Einstiegsartikel unseres Themen-Clusters KI-Agenten. Dort geht es um Aufbau, Feedback-Schleife und die Abgrenzung zum Chatbot. Ein guter Startpunkt.

Risiken & Grenzen

Diese 4 Grenzen gehören zur ehrlichen Einordnung dazu.

• Detektion ist nie vollständig: Erschöpfende Filter sind laut BSI wegen der Vielfalt möglicher Ein- und Ausgaben schwierig und lassen sich etwa durch kodierte Eingaben umgehen. Rechtebeschränkung und Freigabepunkte bilden deshalb eine zweite, unabhängige Sicherheitsebene.
• Zu viele Freigabepunkte töten den Nutzen: Braucht jede kleine Aktion eine manuelle Bestätigung, wird die Freigabe zur Formsache, die niemand mehr wirklich prüft.
• Tool-Definitionen veralten: Ändert sich eine API, muss auch das Schema nachgezogen werden, sonst ruft der Agent mit falschen Annahmen auf oder scheitert unbemerkt.
• Kein Ersatz für Prozessklärung: Ein Agent mit Tool-Zugriff auf ein chaotisches System übernimmt dessen Unordnung nur schneller.

Die Kunst liegt in der Abstufung aus der Risikomatrix, nicht in pauschaler Vorsicht. Garantierte Fehlerfreiheit, garantierte Zeitersparnis oder garantierte Rechtskonformität verspricht dir seriös niemand. Seriös versprechen lässt sich ein kontrolliertes, nachvollziehbares Vorgehen, das Fehler klein hält, wenn sie passieren. Und sie passieren, wie bei jeder Automatisierung, irgendwann. So ehrlich muss man sein.

Kosten: grobe Einordnung

Vorweg ein ehrlicher Hinweis. Konkrete Zahlen liegen in den ausgewerteten Quellen nicht vor. Die folgenden Bandbreiten stammen aus meiner Projekterfahrung. Sie gelten für ein KMU-Setup auf Basis bestehender Automatisierungsplattformen wie n8n statt Eigenentwicklung, mit 2 bis 5 angebundenen Tools zum Start.

• Konzeption und Tool-Inventar (Risikoeinordnung, Schema-Entwürfe, Freigabepunkte): typischerweise wenige Tage bis knapp zwei Wochen, abhängig von der Anzahl der Systeme.
• Technische Umsetzung pro Tool: stark abhängig von der API-Qualität, ein sauber dokumentierter REST-Endpunkt ist in Stunden angebunden, ein gewachsenes System ohne API braucht Tage bis Wochen.
• Laufender Aufwand: Logging-Auswertung und Schema-Pflege bei Systemänderungen sind wiederkehrende, aber meist überschaubare Posten.

Wer diese Bandbreiten für den eigenen Fall konkretisieren will: Ein kostenloses Erstgespräch klärt in der Regel schnell, wie viele Tools realistisch sind und wo die Freigabepunkte hingehören. Für Teams, die zuerst intern Kompetenz aufbauen wollen, bieten sich strukturierte Schulungen an. Gerade zu Prompt Injection und sicherem Umgang mit Tool-Ausgaben ist Grundwissen im Team oft der schnellere Hebel als eine weitere technische Kontrollschicht.

Checkliste: Tool Use sicher umsetzen

Diese 10 Punkte fassen es zusammen.

1. Für jedes angebundene Tool gibt es eine präzise Beschreibung inklusive Parametern und Rückgabeformat, keinen pauschalen Vollzugriff.

2. Antworten von Tools werden gefiltert, bevor sie in den Kontext des Agenten gelangen, nur relevante Felder werden durchgereicht.

3. Eingaben, die der Agent an Tools schickt, werden vor der Ausführung geprüft (Typ, Wertebereich, Plausibilität).

4. Inhalte aus externen Quellen wie Dokumenten, Webseiten oder E-Mails gelten als potenzieller Angriffsweg für Indirect Prompt Injection.

5. Jedes Tool ist nach Wirkung eingeordnet: lesend, intern schreibend, extern sichtbar oder finanziell wirksam.

6. Für Tools mit hoher oder externer Wirkung existiert ein Freigabepunkt vor der Ausführung, nicht erst danach.

7. Jeder Tool-Aufruf wird protokolliert: Zeitpunkt, Tool, Parameter, Ergebnis, auslösender Kontext.

8. Es gibt eine einfache Auswertung auffälliger Muster, nicht nur ein Log, das niemand ansieht.

9. Tool-Schemata werden bei Änderungen an den zugrunde liegenden Systemen aktiv nachgepflegt.

10. Der Start erfolgt mit einem engen, gut geprüften Tool-Set, erweitert wird kontrolliert, nicht auf Zuruf.

Wie ein Agent grundsätzlich aufgebaut ist und wo die Grenze zur klassischen Workflow-Automatisierung verläuft, vertiefen die weiteren Artikel im Cluster KI-Agenten.