# Tools & Agenten — vom Antworten zum Handeln > Werkzeugaufrufe, Ausführungsverantwortung, Tool-Ergebnisse, Schleifen und Berechtigungsgrenzen für handelnde KI-Systeme verstehen. Track: [AI-Grundlagen für den IT-Betrieb](https://physar.tech/learn/ai-foundations) Kanonische Fassung: https://physar.tech/learn/ai-foundations/tools-and-agents-primer Stand: 2026-09-04 Interaktiver Teil: 8 Checks (nur im Browser) ## Tools & Agenten — vom Antworten zum Handeln ### Vom Antworten zum Handeln Bis hierher hat das Modell Text erzeugt. Mit **Werkzeugen** kommt eine neue Qualität hinzu: Das System kann etwas nachschlagen, berechnen — und im Zweifel etwas verändern. Damit wechselt die Risikoklasse. Eine falsche Antwort ist ärgerlich, eine falsche Aktion ist ein Vorfall. _[Abbildung: Die Grundschleife: beobachten, entscheiden, handeln, Ergebnis zurückführen — und irgendwo eine Abbruchbedingung.]_ **Tool-Aufruf:** Eine strukturierte Anforderung des Modells an die Host-Anwendung, eine benannte Funktion mit Argumenten aufzurufen. Der Modelloutput ist noch nicht die reale Aktion. Ein Agent ist keine neue Art von Modell, sondern ein Steuerungsmuster: Das System lässt ein Modell zwischen Beobachtung, Auswahl eines Werkzeugs, Ergebnis und nächstem Schritt iterieren. ReAct beschreibt die Kopplung von Schlussfolgern und Handeln; Protokolle wie MCP standardisieren Teile der Schnittstelle. Die Anwendung bleibt für Ausführung, Berechtigung, Zeitlimits, Wiederholung und Protokollierung verantwortlich. Diese Trennung ist die Grundlage jedes sicheren Designs. Ein statischer Workflow kann ebenfalls ein Modell aufrufen, ohne agentisch zu sein: Schritt A extrahiert, Schritt B prüft, Schritt C schreibt ein Ticket. Ein Agent wählt Pfad oder Wiederholung dynamisch. **Vorteil:** Er kann offene Aufgaben bearbeiten. **Preis:** Zahl und Reihenfolge der Aktionen sind weniger vorhersehbar, Tests werden zustandsbehaftet und Kosten brauchen harte Budgets. Agentische Systeme erweitern den Fehlerraum um **Sequenzen**. Ein an sich zulässiger Leseaufruf kann Informationen sammeln, die in Kombination sensibel sind; mehrere harmlose Schritte können eine schädliche Wirkung vorbereiten. Policy betrachtet deshalb nicht nur einzelne Toolnamen, sondern Nutzerzweck, Ressource, bisherigen Zustand und kumulatives Budget. **Nachteil:** Zustandsabhängige Policy ist komplexer als eine statische Allowlist. Für einfache Prozesse bleibt die statische, enge Fähigkeit vorzuziehen. ### Wer führt eigentlich aus? Das wichtigste Missverständnis zuerst: **Das Modell führt nichts aus.** Es erzeugt einen strukturierten Vorschlag — Werkzeugname und Parameter — als Text. Ob dieser Vorschlag ausgeführt wird, entscheidet **deine Anwendung**. Modell schlägt Aufruf vor → **Anwendung prüft und autorisiert** → Anwendung führt aus → Ergebnis zurück in den Kontext → Modell formuliert weiter Daraus folgt die zentrale Betriebsregel: **Berechtigungen liegen bei der Anwendung, nicht im Prompt.** Was der ausführende Dienst technisch nicht darf, kann kein noch so überredeter Modellvorschlag auslösen. Was er darf, wird früher oder später auch vorgeschlagen. > **Merksatz:** Der Prompt ist eine Bitte, das Rechtekonzept ist eine Grenze. Nur eines davon hält. Das Modell erzeugt Toolname und Argumente. Der Host validiert sie gegen ein Schema, ermittelt die Identität des Nutzers, prüft Policy und ruft erst dann das Zielsystem auf. Ein Text wie `delete_ticket(id=42)` löscht nichts, solange kein Ausführer ihn akzeptiert. Umgekehrt ist der Host verantwortlich, wenn er beliebigen Modelltext als Shellbefehl ausführt. Autorisierung darf deshalb nicht an das Modell delegiert werden. Modell schlägt Tool und Argumente vor → Host validiert Schema → **Policy prüft Nutzer und Ressource** → Executor ruft Zielsystem auf → Ergebnis wird als untrusted Beobachtung zurückgegeben Auch Bestätigung ist eine Host-Funktion. Die UI zeigt konkrete Wirkung, Ziel und Parameter, nicht nur „Tool ausführen?“. **Nachteil:** Bestätigungen unterbrechen den Fluss und können zur Gewohnheitsklick-Falle werden. Sie werden deshalb nach Risiko eingesetzt und ersetzen nie Least Privilege oder serverseitige Autorisierung. Die Nutzeridentität darf auf dem Weg zum Ziel nicht durch eine globale Agentenidentität ersetzt werden, wenn fachliche Rechte nutzerbezogen sind. On-behalf-of- oder delegierte Tokens begrenzen Zugriff auf die Rechte des aktuellen Nutzers; eine Serviceidentität passt nur für klar dienstbezogene Aktionen. Der Executor protokolliert beide: auslösenden Menschen und technische Identität. **Preis:** Delegation und Token-Lebenszyklen erhöhen Integrationsaufwand, verhindern aber mandantenübergreifende Wirkung durch ein gemeinsames Hochprivilegkonto. ### Was Werkzeuge zurückgeben — und was das bedeutet Werkzeuge holen Determinismus zurück: Eine Summe wird gerechnet statt geschätzt, ein Ticketstatus abgerufen statt erinnert. Genau dafür sind sie da — sie schließen die Lücken, die in den Modulen zu Reasoning-Grenzen und Grounding benannt wurden. Aber: Das **Ergebnis** eines Werkzeugs landet im Kontext und wirkt dort wie jede andere Eingabe. Enthält ein abgerufenes Dokument oder ein Ticketkommentar eine Anweisung, kann diese das weitere Verhalten beeinflussen. Werkzeugausgaben sind Daten aus fremder Feder — nicht vertrauenswürdiger Input. | | | | --- | --- | | Lesende Werkzeuge (Suche, Status, Berechnung) | geringes Risiko — Fehler kosten eine falsche Antwort | | Schreibende Werkzeuge (anlegen, ändern, senden, löschen) | hohes Risiko — Fehler haben Außenwirkung und sind oft unumkehrbar | | Werkzeuge, die fremde Inhalte zurückliefern | die Ausgabe ist untrusted, unabhängig davon, wie vertrauenswürdig das Werkzeug ist | **Beobachtung:** Das Ergebnis eines Tool-Aufrufs, das der Steuerungsloop als neuen Kontext erhält. Es kann Daten, Fehler oder vom Zielsystem stammenden untrusted Text enthalten. Ein erfolgreiches Protokollergebnis bedeutet nur, dass der Aufruf technisch beantwortet wurde. Der Inhalt kann veraltet, unvollständig oder absichtlich manipuliert sein. Besonders Webseiten, E-Mails und Dokumente können Anweisungen enthalten, die ein Modell als Handlungsimpuls interpretiert. Markiere Tool-Daten als Daten, begrenze die nächste Aktion durch Policy und validiere strukturierte Ergebnisse gegen ein Output-Schema. Fehler gehören ebenfalls in den Loop, aber mit Grenzen. Ein `429` kann einen Retry rechtfertigen, ein Validierungsfehler nicht. Ohne Fehlerklassen probiert ein Agent möglicherweise dieselbe schreibende Aktion wiederholt. **Preis:** Eine saubere Fehler-Taxonomie und Retry-Policy kostet Implementierungsarbeit; sie verhindert unbeschränkte Schleifen und doppelte Seiteneffekte. Toolbeschreibungen selbst sind Teil des Steuerungskontexts. Ein kompromittierter oder falsch konfigurierter Server kann irreführende Namen, Schemas oder Annotationen liefern. MCP weist ausdrücklich darauf hin, Tool-Annotationen aus untrusted Servern nicht als verlässlich zu behandeln. Vertrauenswürdige Konfiguration pinnt erlaubte Server und Fähigkeiten; dynamische Discovery darf nicht automatisch neue Rechte aktivieren. **Nachteil:** Pinning reduziert Plug-and-play-Flexibilität, liefert aber eine reviewbare Angriffsfläche. ### Schreibende Werkzeuge brauchen andere Regeln - **Bestätigung** vor Wirkung, wo die Handlung nach außen wirkt oder nicht umkehrbar ist. - **Idempotenz**: Ein wiederholter Aufruf darf nicht doppelt wirken — Wiederholungen sind in Schleifen der Normalfall, nicht die Ausnahme. - **Enger Wirkungsbereich**: lieber ein Werkzeug „Ticket kommentieren“ als ein Werkzeug „beliebiges SQL ausführen“. - **Protokollierung** von Vorschlag, Freigabe und Ergebnis — sonst ist im Nachhinein nicht rekonstruierbar, wer was ausgelöst hat. > **Merksatz:** Ein weit geschnittenes Werkzeug ist bequem beim Bauen und unbeherrschbar im Betrieb. Der Zuschnitt der Werkzeuge ist die eigentliche Sicherheitsentscheidung. Schreibende Tools brauchen einen engeren Contract als lesende. Bevorzuge kleine Operationen wie `set_ticket_label` gegenüber offenen Werkzeugen wie `run_shell`. Begrenze erlaubte Felder und Werte im Schema, verwende die Identität des handelnden Nutzers und prüfe Ressourcenzugriff im Zielsystem. OWASP nennt übermäßige Funktionalität, Berechtigung und Autonomie als Ursachen von Excessive Agency. Eine Operation sollte, wo fachlich möglich, **idempotent** sein: Wiederholung mit demselben Schlüssel erzeugt keinen zusätzlichen Effekt. Für nicht idempotente Vorgänge nutzt du Idempotency-Key, Zustandsprüfung oder explizite Transaktion. **Nachteil:** Idempotenz verlangt gespeicherten Zustand und Ablaufregeln. Ohne sie kann ein Timeout zwischen Ausführung und Antwort zu doppelter Zahlung, doppeltem Ticket oder mehrfacher Benachrichtigung führen. Vor einer schreibenden Aktion kann ein `dry_run` oder Plan-Endpoint die konkrete Änderung liefern. Die Bestätigung bezieht sich auf diesen Plan und eine kurze Gültigkeit; weichen Zielzustand oder Parameter danach ab, ist neue Freigabe erforderlich. **Preis:** Read-before-write verdoppelt manche Aufrufe und kann Rennen zwischen Plan und Wirkung nicht allein verhindern. Das Zielsystem braucht weiterhin atomare Vorbedingungen oder Versionsnummern. ### Braucht es überhaupt ein Modell in der Schleife? Ein **Agent** ist ein System, das in einer Schleife selbst entscheidet, welches Werkzeug als nächstes dran ist. Das ist mächtig, wenn der Weg zum Ziel im Voraus unbekannt ist. Es ist Verschwendung, wenn der Ablauf feststeht. Die Prüffrage lautet: **Steht die Schrittfolge vorher fest?** Wenn ja, gehört sie in einen deterministischen Ablauf — dort ist sie testbar, reproduzierbar und billiger. Ein Modell kann darin einzelne unscharfe Teilschritte übernehmen, ohne die Ablaufsteuerung zu bekommen. **Kurzcheck:** Ein Prozess lautet immer: Rechnung empfangen, Felder auslesen, gegen Bestellung prüfen, bei Abweichung Mail an den Einkauf. Was baust du? - [x] Einen festen Ablauf, in dem nur das Auslesen ein Modellaufruf ist - [ ] Einen Agenten mit Werkzeugen für Auslesen, Prüfen und Mailversand - [ ] Einen Agenten ohne Werkzeuge, der den Ablauf beschreibt und ein Mensch führt ihn aus > Richtig. Die Schrittfolge steht fest — nur der Extraktionsschritt ist unscharf. Alles andere ist testbarer, billiger Code. Wie man Agenten dann tatsächlich auslegt — Schleifenbegrenzung, Zustandsführung, Wiederanlauf, Beobachtbarkeit — behandelt der Agentic-AI-Pfad. Hier geht es nur um die Vorentscheidungen: wer ausführt, wie Werkzeuge zugeschnitten sind und ob eine Schleife überhaupt gerechtfertigt ist. Ein Modell gehört nur dann in die Steuerung, wenn der Pfad sprachlich oder situativ offen ist. Ist die Reihenfolge bekannt und sind Bedingungen explizit, ist ein deterministischer Workflow leichter zu testen und zu betreiben. Ein LLM kann innerhalb eines festen Schritts trotzdem Text klassifizieren oder formulieren. Diese **begrenzte Nichtdeterministik** ist oft der bessere Ausgangspunkt als ein vollständiger Agent. | | | | --- | --- | | Feste Reihenfolge, bekannte Bedingungen | Workflow oder State Machine | | Offene Recherche mit variabler Zahl lesender Schritte | Agentischer Loop mit Budget und Abbruch | | Schreibende Wirkung mit hohem Schaden | Fester Freigabepfad; Modell höchstens als Vorschlagsgeber | > **Trade-off:** Ein fester Flow verliert Flexibilität bei unbekannten Pfaden. Ein Agent kauft Flexibilität mit größerem Zustands-, Test- und Sicherheitsraum. Ein Entscheidungsbaum vor dem Agenten spart Sicherheitsarbeit: Kann der Pfad als endliche State Machine beschrieben werden, implementiere ihn explizit. Braucht nur ein Schritt Sprachverständnis, kapsle dort den Modellaufruf. Erst wenn Zahl und Art der nächsten Schritte wirklich offen sind, rechtfertigt sich ein Loop. **Nachteil:** Der feste Flow muss bei neuen Fällen per Code erweitert werden; er bietet dafür bekannte Zustände und Testpfade. ### Tool-Schemas sind Sicherheits- und Qualitätsgrenzen Ein Tool-Schema beschreibt nicht nur Syntax. Namen, Beschreibungen, Pflichtfelder und Enums beeinflussen, wann und wie das Modell ein Werkzeug auswählt. Der Host validiert Argumente trotzdem unabhängig. Freitextfelder sollten nicht mehr Ausdrucksmacht besitzen als fachlich nötig; eine Aktion mit drei erlaubten Zuständen bekommt ein Enum statt eines Shell- oder SQL-Fragments. MCP definiert für Tools unter anderem `name`, `description`, `inputSchema` und optional `outputSchema`. Annotationen wie `readOnlyHint` sind laut Spezifikation Hinweise und dürfen von Clients nicht als vertrauenswürdige Policy behandelt werden. **Preis eines engen Schemas:** Neue Fälle brauchen eine Schema- oder Tool-Version. Der Gewinn ist, dass ungültige Wirkung vor dem Zielsystem sichtbar wird. Schema-Versionen werden mit Client und Server ausgehandelt oder fest gekoppelt. Ein Tool darf nicht still ein Pflichtfeld umdeuten, weil alte Agententraces sonst anders wirken. Backward-Kompatibilität, Deprecation und Contract-Tests sind klassische API-Arbeit und bleiben auch bei modellgesteuerter Auswahl notwendig. **Nachteil:** Versionierung verlangsamt spontane Tooländerungen; sie verhindert unbemerkte semantische Brüche. ### Budgets und Abbruchbedingungen Jeder Loop braucht Grenzen für Schritte, Laufzeit, Token, Kosten und wiederholte Fehler. Eine Abbruchbedingung ist fachlich: Ziel erreicht, keine neue Information, unveränderter Fehler, fehlende Berechtigung oder menschliche Entscheidung erforderlich. Ein bloßes Maximum verhindert Endlosschleifen, erklärt aber nicht, welches Ergebnis dem Nutzer zurückgegeben wird. - `max_steps` begrenzt die Zahl der Modell- und Tool-Runden. - Per-Tool-Timeouts verhindern, dass ein hängender Dienst den ganzen Loop blockiert. - Ein Wiederholungszähler stoppt identische Aufrufe ohne Zustandsfortschritt. - Ein Kostenbudget bricht vor einer unvertretbaren Rechnung ab. - Eine Eskalation übergibt Trace, bisherigen Zustand und offenen Entscheidungsgrund. > **Preis:** Harte Budgets können lösbare lange Aufgaben abbrechen. Ohne Budgets ist der Ressourcen- und Wirkungsraum jedoch nicht beherrschbar. Budgets sollten verschachtelt sein: pro Schritt, pro Aufgabe, pro Nutzer und pro Zeitraum. Ein einzelner Request kann innerhalb seines Limits liegen und durch tausend parallele Sessions trotzdem unvertretbare Kosten oder Last erzeugen. Rate Limits, Concurrency-Limits und Quoten liegen außerhalb des Modellkontexts. **Nachteil:** Harte Quoten können legitime Spitzen blockieren; sie schaffen jedoch einen planbaren Blast Radius und einen expliziten Eskalationsweg. ### Beobachtbarkeit und Wiederaufnahme Ein agentischer Trace braucht mehr als Chattext: Modell- und Promptversion, Schritt, ausgewähltes Tool, validierte Argumente, Autorisierungsentscheidung, Zielantwort, Dauer, Retry-Grund und resultierende Zustandsänderung. Geheimnisse und unnötige personenbezogene Daten gehören nicht in dieses Log. Mit dieser Struktur lässt sich unterscheiden, ob das Modell falsch plante, die Policy ablehnte oder das Zielsystem fehlschlug. Für Wiederaufnahme speichert die Anwendung einen expliziten Workflowzustand. Eine vollständige Chat-Historie ist kein verlässlicher Transaktionslog. Nach einem Prozessabbruch wird zuerst der reale Zielzustand gelesen, bevor eine schreibende Aktion wiederholt wird. **Nachteil:** Persistenter Zustand und Korrelation-IDs erhöhen Plattformaufwand; sie sind der Preis für nachvollziehbare Wirkung. ### Vom lesenden Assistenten zur begrenzten Aktion ### Ticket-Assistent in vier Reifestufen Ein System soll Incidents zusammenfassen, Labels setzen und bei Bedarf einen Dienstneustart anstoßen. **Anforderungen** - Lesen und Schreiben brauchen getrennte Rechte. - Jeder Seiteneffekt muss einem Nutzer und Fall zugeordnet sein. - Fehler dürfen keine unkontrollierten Wiederholungen auslösen. **Schritte** - Mit rein lesender Zusammenfassung und Eval-Set starten. - Label als enges idempotentes Tool mit erlaubten Werten ergänzen. - Neustart nur als Vorschlag mit konkreter menschlicher Bestätigung modellieren. - Erst nach gemessener Zuverlässigkeit einen begrenzten automatischen Pfad für reversible Fälle erwägen. **Merksatz:** Funktionalität, Berechtigung und Autonomie werden unabhängig erweitert — nie als ein einziger Agentenschalter. Gleich im Check entscheidest du acht Achsen: Wer wirklich ausführt, wann ein fester Flow reicht, wie untrusted Tool-Ergebnisse behandelt werden, welche Rechte ein schreibendes Werkzeug bekommt und wie Schema, Idempotenz, Budget und Eskalation zusammenspielen. Bei einem Crash gilt die reale Welt als Quelle der Wahrheit. Der gespeicherte Agentenplan kann veraltet sein, weil ein Tool die Wirkung ausgeführt hat, bevor die Antwort verloren ging. Lies den Zielzustand, gleiche Idempotency-Key und erwartete Version ab und entscheide erst dann über Wiederholung. **Preis:** Kompensations- und Wiederaufnahmelogik nähert sich klassischem Workflow-Engineering. Genau das ist der Punkt: Sobald ein Agent wirkt, gelten die alten Regeln verteilter Systeme weiterhin. ### Was der Check prüft - Die Ausführungsverantwortung korrekt verorten — Anwendung, nicht Modell. - Erkennen, wann ein deterministischer Ablauf statt einer Modellschleife die Antwort ist. - Schreibende Werkzeuge mit Bestätigung, Idempotenz und engem Zuschnitt versehen. - Werkzeugausgaben als potenziell fremdbestimmte Eingabe behandeln. Vor der Freigabe wird der gesamte Trace mit absichtlichen Fehlern getestet: Timeout nach ausgeführtem Write, manipuliertes Tool-Ergebnis, fehlende Berechtigung, unbekanntes Schemafeld und ausgeschöpftes Budget. Der erwartete Ausgang ist jeweils eindeutig und sicher. **Nachteil:** Sequenztests sind teurer als einzelne Promptfälle; sie prüfen den realen agentischen Risikoraum. Nach jedem Test wird nicht nur Erfolg oder Fehler gespeichert, sondern der letzte sichere Zustand. Damit kann der Betrieb erklären, welche Wirkung bereits eingetreten ist und welcher Schritt offen bleibt. Ein Agent, der nur einen flüssigen Abschlussbericht liefert, aber keinen autoritativen Zustandsnachweis besitzt, ist nicht wiederaufnehmbar. **Nachteil:** Zustandsmodelle und Korrelation-IDs kosten Entwicklungszeit; sie sind der Preis dafür, dass ein Tool-Loop wie ein Produktionsworkflow statt wie ein Chat behandelt werden kann. Gleich im Check wird daher nicht das sprachlich klügste Agentenverhalten belohnt, sondern die kleinste verteidigbare Ausführungsgrenze mit sichtbarem Nachteil. Der sichere Ausgang, der autoritative Zielzustand und die verantwortliche Identität müssen nach jedem Schritt ohne Interpretation durch das Modell feststehen. Damit bleibt auch nach einem Abbruch eindeutig, wer welche reale Wirkung ausgelöst oder verhindert hat. ## Quellen - Schick et al. — Toolformer: Language Models Can Teach Themselves to Use Tools, NeurIPS 2023 - Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023 - Model Context Protocol — Specification, Abschnitt Tools - OWASP Top 10 for Large Language Model Applications - Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023 — https://openreview.net/forum?id=WE_vluYUL-X - Model Context Protocol — Tools Specification — https://modelcontextprotocol.io/specification/2025-06-18/server/tools - Model Context Protocol — Architecture — https://modelcontextprotocol.io/specification/2025-06-18/architecture - OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ - NIST SP 800-53 Rev. 5 — Access Control — https://doi.org/10.6028/NIST.SP.800-53r5 - OWASP Top 10 for Large Language Model Applications — Excessive Agency - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Automation - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Handling Overload - Greshake et al. — Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, ACM AISec 2023 - OWASP Top 10 for Large Language Model Applications — Prompt Injection - Greshake et al. — Not What You've Signed Up For, AISec 2023 — https://doi.org/10.1145/3605764.3623985