Was ist ein AI Agent?
Ein AI Agent ist ein Anwendungsmuster, bei dem die Ausgabe eines Modells genutzt wird, um Aktionen auszuwählen und auszulösen, oft über mehrere Schritte. Die Anwendung gibt dem Modell eine Aufgabe, relevanten Kontext und eine Beschreibung verfügbarer Fähigkeiten, interpretiert seine strukturierte Ausgabe als vorgeschlagene Aktionen, führt einige davon aus und speist die Ergebnisse zurück.
"Agent" ist keine magische Modellfähigkeit und kein universell standardisiertes Grundelement. Produkte bezeichnen damit alles von einem einzelnen Tool-Aufruf bis zu lang laufenden mehrstufigen Systemen. Gemeinsam ist ihnen der Schritt, um den es hier geht: Modellausgabe wird von Text zu Handlung.
Der Artikel baut auf System Prompts und Vertrauensgrenzen und Modellkontext auf: Der für das Modell sichtbare Kontext kann die Ausgabe beeinflussen, doch Vertrauen, Autorität und sicherheitsrelevante Fakten werden durch anwendungsseitigen Zustand festgelegt; die Modellausgabe bleibt ein variabler Vorschlag.
Was ist Tool Calling oder Function Calling?
Tool Calling (auch Function Calling) bedeutet, dass das Modell strukturierte Daten erzeugt, etwa einen Tool-Namen und Argumente, die die Anwendung als Anfrage zum Aufruf einer Fähigkeit interpretieren kann. Das Modell führt das Tool nicht selbst aus. Anwendungscode entscheidet, ob, wie und mit welchen Zugangsdaten gehandelt wird.
Der Agenten-Kreislauf
| Stufe | Was sie ist | Vertrauenscharakter |
|---|---|---|
| Aufgabe oder Anfrage | Nutzeranfrage ist variable Eingabe; Identität, Scope und Aufgabenrahmen sind anwendungseigene Metadaten | Gemischt: Nutzeranfrage ist variable Eingabe; Aufgabenmetadaten sind anwendungseigen |
| Kontextaufbau | Anweisungen, Gesprächsverlauf, abgerufene Inhalte, frühere Ergebnisse, Tool-Beschreibungen | Modellsichtbare variable Inhalte plus vertrauenswürdige Anwendungsmetadaten außerhalb des Modells |
| Vorschlag | Text oder strukturierter Tool-Aufruf des Modells | Modellausgabe, variable Daten |
| Schema-Validierung | Prüft Form und Typen des vorgeschlagenen Aufrufs | Nur struktureller Vertrag |
| Autorisierung und Policy | Entscheidet, ob dieser Principal genau diese Aktion jetzt ausführen darf | Deterministische Anwendungsentscheidung |
| Freigabe, falls erforderlich | Authentifizierte menschliche Entscheidung über genau diese Aktion | Externer Nachweis, gebunden an eine Aktionsversion |
| Ausführung | Die Anwendung ruft die Fähigkeit mit begrenzten Zugangsdaten auf | Aufruf der Fähigkeit |
| Ergebnis | Beobachteter Ausführungszustand plus vom Tool zurückgegebener Inhalt | Zustand ist beobachtet; zurückgegebener Inhalt sind variable Daten |
| Rückkehr in den Kontext | Das Ergebnis wird für den nächsten Schritt in den Kontext gelegt | Provenienz bleibt erhalten |
| Nächster Vorschlag | Das Modell schlägt einen weiteren Schritt oder eine Antwort vor | Wieder variable Daten |
Jeder Übergang in diesem Kreislauf wird von der Anwendung kontrolliert. Sicherheitsentscheidungen gehören an diese Übergänge, nicht in das Modell.
Modellvorschlag und Anwendungsentscheidung
Drei Dinge sind zu trennen: was der auslösende Nutzer angefragt hat, was das Modell vorgeschlagen hat und was die Anwendung auszuführen entschieden hat. "Das Modell wollte es" heißt nicht "der Nutzer hat es angefragt". Ein Vorschlag kann von jedem modellsichtbaren Inhalt beeinflusst sein, auch von Text Dritter, wie AI-Agent-Prompt-Injection beschreibt.
Vom Modell verfasste Behauptungen in einem Vorschlag, etwa "der Nutzer hat bereits zugestimmt" oder "dieser Empfänger ist intern", sind zu prüfende Inhalte, niemals Fakten für die Erlaubnisentscheidung. Das ist die Kernregel der Agentenautorisierung.
Verfügbarkeit eines Tools ist keine Berechtigung
Wird dem Modell ein Tool oder Schema gezeigt, kann es dessen Nutzung vorschlagen. Das heißt nicht, dass jeder Aufrufer, jede Sitzung oder jede Aufgabe jede Aktion, Ressource oder jeden Parameter dieses Tools nutzen darf. Verfügbarkeit beschreibt, was angefragt werden kann; die Berechtigung wird pro Aufruf entschieden.
Die Menge der für eine Aufgabe sichtbaren Tools zu verkleinern, bleibt sinnvoll: Es begrenzt, was das Modell vorschlagen kann, und verringert Verwechslungen. Es ergänzt die Autorisierung, ersetzt sie aber nicht.
Tool-Schemas: was sie prüfen und was nicht
| Ein Schema kann prüfen | Ein Schema stellt nicht fest |
|---|---|
| Pflichtfelder sind vorhanden | Dass der Aufrufer die Aktion ausführen darf |
| Typen, Formate und erlaubte Werte | Woher die Argumentwerte stammen |
| Wertebereiche und Längen | Einhaltung von Geschäftsregeln |
| Eine wohlgeformte Aufrufstruktur | Mandantentrennung oder Eigentum an der Ressource |
| Ablehnung unbekannter Felder | Die inhaltliche Unbedenklichkeit der Anfrage |
Schema-Validierung ist Teil der Ausgabevalidierung: Sie prüft Form und Vertrag. Senkenspezifische Kodierung, Escaping oder Parametrisierung für das System, das die Werte verarbeitet, bleibt ein getrennter Schritt. Auch nach der Validierung bleiben vom Modell verfasste Argumente variable Daten.
Identität: Nutzer, Agent und Connector
Authentifizierung und Autorisierung sind verschieden. Ein gültiger, authentifizierter Connector oder Zugangsdatensatz belegt, wer aufruft; er macht beliebige vom Modell vorgeschlagene Aktionen nicht autorisiert.
Auch die Identität des Agenten und die des auslösenden Nutzers sind verschieden. Verbreitete Muster sind:
- Handeln als Nutzer: Aufrufe laufen mit den delegierten Rechten des Nutzers, der Agent erreicht also nicht mehr als dieser.
- Dienstidentität: Der Agent läuft unter eigener Identität; die Anwendung muss dann weiterhin prüfen, wozu der auslösende Nutzer berechtigt ist.
- Delegierte, eingeschränkte Fähigkeit: Der Agent erhält eine engere, aufgabenbezogene Berechtigung, die aus den Rechten des Nutzers abgeleitet ist.
Keines davon ist ein universelles Design. Jedes verlangt, dass die Anwendung festhält, wer eine Aufgabe ausgelöst hat und unter welcher Identität jeder Aufruf läuft.
Autorisierung zur Laufzeit und Policy-Eingaben
Eine Autorisierungsentscheidung zur Laufzeit sollte binden:
Was die Entscheidung bindet
- Principal und Sitzung: auslösender Nutzer und ausführende Identität.
- Aktion oder Tool: genau der angefragte Vorgang.
- Ressource: der konkrete Datensatz, die Datei, das Konto oder System.
- Parameter und Ziel: Werte, Empfänger, Beträge, Ziele.
- Aktueller Zustand: Status von Ressource und Aufgabe zum Entscheidungszeitpunkt.
- Freigabe oder Delegation, wo die Policy sie verlangt.
Diese Fakten stammen aus anwendungsseitigen Aufzeichnungen, nicht aus Modelltext. Ziele und Datenbewegungen regelt zusätzlich die Informationsflusskontrolle.
Least Privilege und Begrenzung von Fähigkeiten
Least Privilege begrenzt den möglichen Schaden, wenn das Modellverhalten fehlgeht. Zugangsdaten auf die Aufgabe beschränken, wo möglich nur lesend arbeiten, erreichbare Ressourcen und Ziele einschränken und Berechtigungen kurzlebig halten. Dann erreicht selbst ein vollständig beeinflusster Vorschlag nur, was der Umfang erlaubt.
Menschliche Freigabe und Step-up-Kontrollen
Für ausgewählte folgenreiche Aktionen kann die Policy eine menschliche Freigabe verlangen. Eine Freigabe ist ein authentifizierter Nachweis und eine Zustimmung, gebunden an eine konkrete Aktionsversion; sie ist ein zusätzliches Gate, kein Ersatz für Autorisierung. Sie hebt nie eine deterministische Ablehnung auf und erweitert nie Zugangsdaten.
Eine veraltete Freigabe für eine frühere Version, eine allgemeine Bestätigung "dieses Tool erlauben" oder vom Modell verfasster Text, der eine Freigabe behauptet, genügt nicht. Keine Antwort oder ein Timeout bei einer folgenreichen Aktion heißt: keine Ausführung. Siehe Human-in-the-Loop.
Tool-Ausgaben kehren als variable Daten zurück
Ein Tool-Ergebnis gelangt zurück in den Modellkontext. Sofern ein Feld nicht unabhängig von der Anwendung festgestellt wird, etwa ein Statuscode der Ausführung, sind die zurückgegebenen Inhalte variable Daten. Ein vertrauenswürdiges Tool macht nicht jedes zurückgegebene Feld vertrauenswürdig oder anweisungsbefugt: Eine vertrauenswürdige API kann getreu Text zurückgeben, den irgendwer geschrieben hat.
Von Tools zurückgegebene Inhalte können daher spätere Vorschläge beeinflussen. Dieses eigene Risiko beschreibt Tool-Output-Injection. Die Provenienz sollte erhalten bleiben, wenn Ergebnisse in den Kontext zurückkehren, damit die Anwendung und nicht das Modell entscheidet, wie jeder Wert genutzt werden darf.
Mehrstufige Pläne, Plan Drift und Tool-Chain-Risiken
Eine Kette einzeln erlaubter Schritte kann ein Ergebnis erzeugen, das kein einzelner Schritt erkennen lässt, etwa sensible Daten in einem Schritt lesen und in einem anderen bewegen. Plan Drift beschreibt einen Vorschlag, der sich von der vom Nutzer begonnenen Aufgabe entfernt; die Tool-Chain-Analyse betrachtet Daten und Wirkungen über eine Folge von Aufrufen.
Beides sind Konzepte für Überwachung und Erkennung, unterstützt durch Erkennung von Prompt Injection. Sie liefern Hinweise für die Prüfung, sind aber keine Berechtigungssysteme. Über jeden Aufruf entscheiden weiterhin Autorisierung und Flusskontrolle. In Multi-Agent-Systemen wird die Ausgabe eines Agenten zur Eingabe eines anderen und braucht dieselbe Behandlung.
Wiederholungen, Idempotenz und unsicherer Ausführungszustand
Ein Aufruf kann in ein Timeout laufen oder kein beobachtbares Ergebnis liefern. Ein unbekanntes Ergebnis ist nicht dasselbe wie ein Fehlschlag. Bei folgenreichen Vorgängen kann blindes Wiederholen die Aktion doppelt ausführen.
Vor einer Wiederholung den Vorgangsstatus prüfen, Idempotenzschlüssel nutzen, wo das Ziel sie unterstützt, und festhalten, dass das Ergebnis unsicher war. Ob eine Wiederholung sicher ist, entscheidet die Anwendung, nicht das Modell.
Vorgeschlagen, autorisiert, ausgeführt, erfolgreich
| Zustand | Bedeutung | Was er nicht bedeutet |
|---|---|---|
| Vorgeschlagen | Das Modell hat einen Aufruf erzeugt | Dass irgendwer ihn ausführen darf oder wird |
| Autorisiert | Die Policy hat genau diesen Aufruf erlaubt | Dass er lief oder erfolgreich sein wird |
| Ausgeführt | Die Anwendung hat die Fähigkeit aufgerufen | Dass der Vorgang abgeschlossen ist |
| Erfolgreich | Der Abschluss des Vorgangs wurde beobachtet | Dass der zurückgegebene Inhalt vertrauenswürdig ist |
Synthetische Beispiele
In einer Support-Sitzung für Kunde C-100 wird nach dem Bestellstatus gefragt. Das Modell schlägt lookup_order für eine Bestellung von C-100 vor.
Die Schema-Validierung besteht; die Autorisierung bestätigt, dass die Bestellung zum Kunden der Sitzung gehört; der Lesezugriff läuft und der Status wird zusammengefasst. Ein sauberer Erlaubnisweg.
In derselben Sitzung schlägt das Modell lookup_order für eine Bestellung von Kunde C-200 vor.
Der Aufruf ist wohlgeformt und das Tool verfügbar, doch die Autorisierung lehnt ab, weil die Ressource nicht zum Kunden der Sitzung gehört. Die Ablehnung wird protokolliert.
Ein abgerufenes Dokument nennt reports@partner.example.test. Das Modell schlägt send_email mit einer Zusammenfassung an diese Adresse vor.
Die Zielrichtlinie prüft den Empfänger gegen die erlaubten Ziele der Anwendung. Die Adresse stammt aus Inhalten, nicht vom Nutzer oder einer freigegebenen Liste, daher wird der Versand abgelehnt, sofern er nicht unabhängig erlaubt ist.
Eine fiktive Erstattung von 20 Credits für Bestellung O-7 läuft ohne beobachtetes Ergebnis in ein Timeout.
Die Anwendung fragt vor jeder Wiederholung den Vorgangsstatus über den Idempotenzschlüssel ab. Die Erstattung war abgeschlossen, daher wird keine zweite ausgelöst.
Ein Ticket-Tool liefert ein Beschreibungsfeld mit [synthetischer anweisungsähnlicher Text].
Das Feld bleibt Ticketinhalt mit festgehaltener Quelle. Es erhält keine Anweisungsbefugnis, und jeder Folgevorschlag wird für sich autorisiert.
Protokollierung, Telemetrie und Audit Trail
Für folgenreiche Aktionen sollten prüfbare Aufzeichnungen außerhalb des Modells geführt werden:
Pro Aufruf festhalten
- Auslösender Principal und ausführende Identität.
- Aufgaben- oder Anfragekennung und Korrelations-ID.
- Genauer vorgeschlagener Aufruf und Parameter.
- Autorisierungsentscheidung und die Policy, die sie getroffen hat.
- Freigabeereignis, falls vorhanden, mit prüfender Person und Aktionsversion.
- Ausführungszustand und Ergebnis.
- Provenienz der Eingaben, die den Vorschlag geprägt haben.
- Zeitstempel für jeden Zustandsübergang.
Protokolle unterstützen Prüfung und Reaktion. Sie sind Nachweise, keine Durchsetzung.
Häufige Missverständnisse
Aussagen, die nicht zutreffen
- Wenn das Modell das Tool aufgerufen hat, wollte der Nutzer es.
- Ein dem Modell gezeigtes Tool darf für jede Ressource genutzt werden.
- Schema-Validierung macht einen Aufruf sicher.
- Ein authentifizierter Connector autorisiert jede Aktion, die er technisch ausführen kann.
- Ergebnisse eines vertrauenswürdigen Tools sind vertrauenswürdige Anweisungen.
- Ein Timeout bedeutet, dass die Aktion nicht stattgefunden hat.
- Eine einmalige Freigabe eines Tools deckt spätere Aufrufe ab.
Üben
Die Labs trainieren jeden Übergang mit fiktiven Szenarien: Agentenautorisierung für die Erlaubnisentscheidung, Tool-Output-Injection für Ergebnisse, die in den Kontext zurückkehren, Plan-Drift-Erkennung und Tool-Chain-Analyse für mehrstufige Risiken sowie Menschliche Freigabe für die Gültigkeit von Freigaben.
Standards und Quellen
Wie dieser Artikel Quellen nutzt
- OWASP
- LLM03:2026 Excessive Agency - übermäßige Funktionalität, Berechtigungen und Autonomie, Top 10 for Agentic Applications 2026 - agentenspezifische Risikoeinordnung, GenAI LLM Top 10 2026 - Prompt Injection als benanntes Risiko
- NIST
- AI 100-2e2025 - Begriffe zu Prompt Injection einschließlich indirekter Injection
- Microsoft
- Least Privilege für AI Agents und das Shared-Responsibility-Modell für AI Agents, Leitlinie zu indirekter Prompt Injection - mehrschichtige Gegenmaßnahmen
Genaue Bindung der Autorisierung, die vier Ausführungszustände, idempotente Wiederholungen und der Audit-Datensatz sind Architekturempfehlungen, keine aus einem Standard zitierten Anforderungen.
Häufige Fragen
Führt das Modell Tools selbst aus?
Ist ein gültiger Tool-Aufruf ein autorisierter Tool-Aufruf?
Soll der Agent die Identität des Nutzers oder eine eigene nutzen?
Kann menschliche Freigabe die Autorisierung ersetzen?
Darf man Tool-Ergebnissen folgen?
Was sollte nach einem Timeout passieren?
Blockiert Plan-Drift-Erkennung Aktionen?
Quellen
- LLM03:2026 Excessive AgencyOWASP GenAI Security Project · GuidanceGeprüft 2026-09-26
- OWASP Top 10 for Agentic Applications 2026OWASP GenAI Security Project · GuidanceGeprüft 2026-09-26
- Least privilege for AI agentsMicrosoft Learn · GuidanceGeprüft 2026-09-26
- AI agent shared responsibility modelMicrosoft Learn · GuidanceGeprüft 2026-09-26
- OWASP GenAI LLM Top 10 2026OWASP GenAI Security Project · GuidanceGeprüft 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Geprüft 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceGeprüft 2026-09-26