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

Ein Support-Agent, der Tickets nicht nur kategorisiert, sondern auch im CRM aktualisiert. 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 – und genau dieser Schritt vom Text zur Aktion ist es, der KI-Agenten für Unternehmen interessant und gleichzeitig riskant macht.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die einen Agenten mit echtem Systemzugriff planen oder bereits im Einsatz haben. Er beantwortet konkret: Was Tool Use technisch bedeutet, wie man APIs so beschreibt, dass ein Agent sie sinnvoll nutzen kann, welche Eingaben geprüft werden müssen, wie man Aktionen begrenzt und wie man den Betrieb protokolliert – mit einer eigenen Risikomatrix für die Einordnung deiner eigenen 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 – etwa eine API, eine Datenbankabfrage oder einen E-Mail-Versand – statt nur Text auszugeben. Das Sprachmodell erhält eine Beschreibung jedes Tools inklusive Parametern, wählt bei Bedarf das passende aus, füllt die Parameter und liest das Ergebnis, bevor es weiterplant. Genau dieser Systemzugriff macht Agenten nützlich – und zugleich zu einem Sicherheitsthema, sobald ein Tool tatsächlich etwas verändern kann.

Begriffe kurz geklärt

Ein paar Begriffe werden in diesem Umfeld häufig unscharf verwendet:

• Tool ist in diesem Kontext keine Software im umgangssprachlichen Sinn, sondern eine einzelne, dokumentierte Funktion, die der Agent aufrufen kann – ein API-Aufruf, eine Datenbankabfrage, eine Berechnung. n8n unterscheidet dafür etwa zwischen der HTTP Request Node im normalen Modus und ihrem Tool-Modus, in dem sie eine eigene Beschreibung für das Sprachmodell mitbekommt.
• Tool-Schema ist die strukturierte Beschreibung eines Tools: Name, Zweck, erwartete Parameter mit Typ und Bedeutung, manchmal auch Beispielaufrufe. Das Sprachmodell liest dieses Schema, nicht den zugrunde liegenden Code.
• Function Calling / Tool Calling ist der technische Mechanismus, mit dem ein Sprachmodell anhand der verfügbaren Schemata entscheidet, ob und welches Tool es aufruft, und die passenden Parameter formuliert. n8n implementiert dies in seiner Tools Agent Node über die entsprechende Schnittstelle der angebundenen Sprachmodelle.
• Human-in-the-Loop meint einen eingebauten Haltepunkt, an dem ein Mensch eine geplante Aktion bestätigen oder ablehnen muss, bevor sie ausgeführt wird – kein nachträgliches Kontrollieren, sondern eine Freigabe vor der Wirkung.

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 Wirkung nach außen auslösen kann, verändert sich die Risikolage grundlegend.

Wie definiert man APIs als Tools?

Damit ein Agent eine API sinnvoll nutzt, braucht er mehr als den nackten Endpunkt. Nötig ist eine Beschreibung, die dem Sprachmodell erklärt, wann und wie das Tool einzusetzen ist. In n8n geschieht das, indem eine HTTP-Request-Node an eine Agenten-Node angehängt und in den Tool-Modus versetzt wird; 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.

Drei Punkte entscheiden in der Praxis über die Qualität dieser Definition:

Präzise Beschreibung statt technischer Kurzform. „Sucht Kunden” ist zu vage; „Sucht einen Kunden anhand der Kundennummer und gibt Name, Adresse und offene Rechnungen zurück – nicht geeignet für Namenssuche” gibt dem Modell genug Kontext, um das Tool korrekt und nicht für artfremde Zwecke einzusetzen.

Enger Parameter-Zuschnitt. Je weniger ein einzelnes Tool gleichzeitig kann, desto vorhersehbarer sein Einsatz. Ein Tool, das ausschließlich eine Bestellung anlegt, ist leichter zu prüfen und zu begrenzen als ein generisches Tool, das beliebige Datenbank-Schreibzugriffe erlaubt.

Antwort-Optimierung. Die HTTP Request Node bietet im Tool-Modus eine eigene Option, um Antworten vor der Übergabe an das Modell zu filtern – etwa nur relevante JSON-Felder durchzureichen statt der vollständigen Rohantwort. Das senkt nicht nur Kosten, sondern reduziert auch, welche Daten überhaupt im Kontext des Modells landen und potenziell fehlinterpretiert werden können.

Wer Tools zu breit oder zu vage definiert, bekommt keine kontrollierbaren Agenten, sondern ein System, dessen Verhalten man erst im Nachhinein versteht – meist an der Stelle, an der etwas schiefgelaufen ist.

Welche Eingaben müssen validiert werden?

Bei Tool Use gibt es zwei Richtungen, in die Eingaben validiert werden müssen, und beide werden in der Praxis regelmäßig übersehen.

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

Zweitens, und häufig unterschätzt: was der Agent aus externen Quellen liest. 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 auf einer Webseite, in einer E-Mail oder in einem Dokument, das es eigentlich nur zusammenfassen soll, als Anweisung interpretieren – mit der Folge, dass eine daran angebundene Anwendung unautorisierte Aktionen ausführt, etwa ungewollte Käufe auslöst oder E-Mails löscht, wenn die Anwendung entsprechende Aktions- und Zugriffsmöglichkeiten hat. Dieses Muster wird als Indirect Prompt Injection bezeichnet.

Aus dieser Beobachtung leiten sich in der BSI-Publikation konkrete Gegenmaßnahmen ab: Eingaben mit manipulativer oder böswilliger Absicht sollen nach Möglichkeit erkannt und gefiltert werden, etwa durch Klassifikatoren, die verdächtige Muster im Klartext prüfen – nicht erst auf Embedding-Ebene, wo semantische Information verloren geht. Ergänzend kann es helfen, Nutzereingaben technisch von Fremdinhalten abzugrenzen, damit das Modell zwischen der eigentlichen Anweisung der Nutzerin und eingeschleusten Anweisungen aus einer verarbeiteten Quelle unterscheiden kann.

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

Wie beschränkt man Aktionen?

Die wirksamste Einzelmaßnahme gegen Fehlverhalten von Tool-nutzenden Agenten ist nicht bessere Erkennung im Nachhinein, sondern enge Rechte von vornherein. Das BSI formuliert es so: Zugriffs- und Ausführungsrechte von LLM-basierten Anwendungen sollten auf das notwendige Minimum beschränkt werden, mit klaren Vertrauensgrenzen zwischen dem Modell, der darauf aufbauenden Anwendung, externen Ressourcen und erweiterten Funktionalitäten. Zusätzlich kann das Ausführen potenziell kritischer Aktionen von einer expliziten Zustimmung der Nutzenden abhängig gemacht werden, etwa über einen Bestätigungs-Button.

Genau diesen Mechanismus hat n8n im Januar 2026 als eigenes Feature eingeführt: Agenten können seit Version 2.6.0 so konfiguriert werden, dass sie vor der Ausführung bestimmter Tools eine explizite menschliche Freigabe einholen müssen – für „high-impact”-Operationen wie das Löschen von Datensätzen, Schreibzugriffe auf Produktivsysteme oder das Versenden wirkungsvoller E-Mails. Damit lässt sich deterministische Kontrolle über genau die Aktionen erreichen, 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 sowohl Über- als auch Untersicherung:

Tool-Typ	Beispiel	Rückgängig zu machen?	Empfohlene Kontrolle
Lesend, intern	Kundendaten abrufen, Dokument suchen	– (kein Schreibzugriff)	Zugriff auf notwendige Datenfelder beschränken, Logging
Schreibend, intern, geringe Tragweite	Ticket kategorisieren, Notiz anlegen	Ja, leicht	Logging, stichprobenartige Prüfung
Schreibend, intern, hohe Tragweite	Auftrag im ERP anlegen, Preis ändern	Teilweise, mit Aufwand	Enger Parameter-Zuschnitt, Freigabe ab Schwellenwert
Schreibend, extern sichtbar	E-Mail an Kunden senden, Social-Media-Post	Nein oder nur mit Reputationsschaden	Freigabe vor jeder Ausführung, Vorlage statt Freitext wo möglich
Finanziell wirksam	Bestellung auslösen, Zahlung anstoßen	Nein oder nur mit Aufwand	Freigabe vor jeder Ausführung, Betragsobergrenze, 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 Wirkung nach außen, desto näher muss die menschliche Kontrolle an den Ausführungszeitpunkt heranrücken. 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 vor die Ausführung, nicht danach.

Wie protokolliert man?

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 ausgehend von der ursprünglichen Nutzereingabe nachvollziehbar macht – wobei rechtliche Anforderungen zu beachten sind, insbesondere wenn personenbezogene Daten Teil der Aufrufe oder Ergebnisse sind. Ein automatisiertes Monitoring kann helfen, unerwünschtes Verhalten frühzeitig zu erkennen, unabhängig davon, ob es aus normaler Nutzung oder aus einem Angriff resultiert.

Für ein KMU-Setup halte ich fünf Angaben pro Tool-Aufruf für das praktikable Minimum:

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

Reine Protokollierung reicht dabei nicht aus, wenn niemand hinschaut. Für kritische Tools lohnt sich ergänzend eine einfache Regel-Auswertung – etwa 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, deckt in der Praxis aber die meisten offensichtlichen Fehlfunktionen ab.

Umsetzung: So gehe ich vor

In Projekten, in denen ich Agenten mit echtem Systemzugriff aufsetze, hat sich eine feste Reihenfolge bewährt:

1. Tool-Inventar erstellen. Welche Systeme soll der Agent überhaupt anfassen? Erst die vollständige Liste, dann die Einordnung nach der Risikomatrix oben.
2. Pro Tool: Schema schreiben, nicht nur Endpunkt verdrahten. Name, präzise Beschreibung, Parameter mit Typ und Grenzen, erwartetes Rückgabeformat.
3. Antworten filtern. Nur die Felder an das Modell durchreichen, die für die Aufgabe relevant sind – das reduziert sowohl Kosten als auch die Angriffsfläche für fehlinterpretierte Fremddaten.
4. Freigabepunkte festlegen, bevor der Agent produktiv geht – nicht erst, nachdem etwas passiert ist. Für jedes Tool mit hoher oder externer Wirkung: Wer gibt frei, worauf, mit welcher Frist?
5. Logging von Anfang an aktivieren, nicht nachrüsten. Ein System ohne Protokoll aus der Testphase liefert im Ernstfall keine Antworten.
6. Mit engem Tool-Set starten, kontrolliert erweitern. Ein Agent mit drei sauber definierten, gut geprüften Tools ist einem Agenten mit fünfzehn halbherzig beschriebenen vorzuziehen.

Wer eine erste eigene Einordnung sucht, bevor ein konkretes Vorhaben ansteht: Die Grundlagen zu Agenten insgesamt – Aufbau, Feedback-Schleife, Abgrenzung zum Chatbot – behandelt der Einstiegsartikel unseres Themen-Clusters KI-Agenten.

Risiken & Grenzen

Ein paar Grenzen gehören zur ehrlichen Einordnung dazu:

• Detektion ist nie vollständig. Auch gute Eingabeprüfung erkennt nicht jeden Manipulationsversuch. Das BSI weist explizit darauf hin, dass es aufgrund der Vielfalt möglicher Ein- und Ausgaben schwierig ist, einen erschöpfenden Filter zu implementieren – Filter können umgangen werden, etwa durch kodierte oder ungewöhnlich formulierte Eingaben. Rechtebeschränkung und Freigabepunkte sind deshalb kein Ersatz für Eingabevalidierung, sondern eine zweite, unabhängige Sicherheitsebene.
• Zu viele Freigabepunkte töten den Nutzen. Wenn jede kleine Aktion eine manuelle Bestätigung braucht, verliert der Agent seinen Automatisierungsvorteil und die Freigabe wird zur Formsache, die niemand mehr wirklich prüft. Die Kunst liegt in der Abstufung aus der Risikomatrix, nicht in pauschaler Vorsicht.
• Tool-Definitionen veralten. Ändert sich eine API oder ein internes System, muss auch das Tool-Schema aktualisiert werden – sonst ruft der Agent mit falschen Annahmen auf oder scheitert unbemerkt an geänderten Feldern.
• Kein Ersatz für Prozessklärung. Ein Agent mit Tool-Zugriff auf ein chaotisches System übernimmt dessen Unordnung nur schneller. Saubere Systeme und klare Prozesse sind Voraussetzung, nicht Nebeneffekt der Automatisierung.

Garantierte Fehlerfreiheit, garantierte Zeitersparnis oder garantierte Rechtskonformität durch Tool Use verspricht dir seriös niemand. Was sich seriös versprechen lässt, ist ein kontrolliertes, nachvollziehbares Vorgehen, das Fehler klein hält, wenn sie passieren – und sie passieren, wie bei jeder Automatisierung, irgendwann.

Kosten: grobe Einordnung

Konkrete Zahlen zu Umsetzungskosten für Tool-Use-Projekte liegen in den ausgewerteten Quellen nicht vor; die folgenden Bandbreiten stammen aus meiner Projekterfahrung und gelten unter der Annahme eines KMU-Setups auf Basis bestehender Automatisierungsplattformen (etwa n8n) statt Eigenentwicklung, mit zwei bis fünf angebundenen Tools zum Start.

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

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 zunächst intern die nötige Kompetenz aufbauen wollen, bevor ein Agent produktiv geht, bieten sich zudem strukturierte Schulungen an – gerade zum Thema Prompt Injection und sicherer Umgang mit Tool-Ausgaben ist Grundwissen im Team oft der schnellere Hebel als noch eine weitere technische Kontrollschicht.

Checkliste: Tool Use sicher umsetzen

1. Für jedes angebundene Tool gibt es eine präzise Beschreibung inklusive Parametern und Rückgabeformat – kein pauschaler Vollzugriff auf ein System.
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 (Dokumente, Webseiten, eingehende E-Mails), die der Agent verarbeitet, werden als potenzieller Angriffsweg für Indirect Prompt Injection behandelt.
5. Jedes Tool ist nach Wirkung eingeordnet (lesend, intern schreibend, extern sichtbar, finanziell wirksam) – mit der Risikomatrix oben oder einer eigenen.
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 (Häufung, ungewöhnliche Zeiten) – 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 – Erweiterung erfolgt 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.