Tools

Kapitel 08 nennt drei Wege, auf denen Neues in ein Gespräch kommt. Der dritte heißt dort „die Anwendung schlägt nach“. Hier steht, wie die Anwendung das macht.

Sie haben längst einen gesehen

Wenn Sie in einem Chat eine Frage nach etwas Aktuellem stellen und darüber kurz „Suche im Web“ aufblinkt, haben Sie einen Tool Call beobachtet. Das gilt auch für den kleinen Rechenschritt, der plötzlich als Code erscheint, für das Auslesen einer hochgeladenen Tabelle und für den Verweis auf eine Fundstelle, die in der Antwort verlinkt ist.

Dafür muss niemand einen Agenten gebaut haben. Tools stecken in den Anwendungen, die Millionen Menschen täglich benutzen, und sie sind der Grund, warum diese Anwendungen so viel mehr können als das Modell in ihrem Inneren.

In eng­lisch­spra­chigen Anleitungen heißt so etwas tool, der Vorgang tool use oder function calling. Gemeint ist dasselbe.

Das Modell fragt, es macht nicht

Es klingt zunächst nach Haarspalterei: Das Modell führt nichts aus.

Was es tut, ist eng begrenzt. Es erzeugt Text. Bei einem Tool Call erzeugt es einen Text, der nach einer Bitte aussieht: „rufe die Wetterauskunft für München auf“. Ob daraus etwas wird, entscheidet das Programm ringsherum. Anthropic beschreibt das in der Dokumentation zu den Tools (externe Seite, platform.claude.com) genau so: Das Modell gibt einen Aufruf in fester Form zurück, und ausgeführt wird er entweder von Ihrer Anwendung (bei Tools im eigenen Programm) oder von Anthropic selbst (bei Tools, die beim Anbieter laufen).

Bitte und Ausführung liegen damit an zwei verschiedenen Stellen.

Die Schleife

Daraus wird ein Ablauf mit vier Schritten, der sich wiederholt, bis die Aufgabe erledigt ist.

1. Vorher wird beschrieben, was es gibt. Zusammen mit Ihrer Frage bekommt das Modell eine Liste: Diese Tools existieren, so heißen sie, dafür sind sie da, diese Angaben brauchen sie.
2. Das Modell wählt und bittet. Es nennt ein Tool und die Angaben dazu. Mehr passiert an dieser Stelle nicht.
3. Ein Programm führt aus. Es ruft die Wetterauskunft, die Suchmaschine, den Taschenrechner. Das Ergebnis kommt von dort, aus der Welt außerhalb des Modells.
4. Das Ergebnis geht zurück ins Gespräch. Von da an steht es im Kontext, als hätten Sie es selbst hineingeschrieben, und das Modell formuliert damit weiter.

seitlich verschiebbar

eigene Darstellung, Stand 31.07.2026

Schritt 3 ist der interessante. Dort verlässt die Sache zum ersten Mal die Welt der Wahr­schein­lich­keiten und trifft auf ein Programm, das entweder etwas zurückgibt oder scheitert. Wer damit baut, rechnet meist mit diesen beiden Ausgängen. Der häufigste ist ein dritter, und Tiefe 3 nimmt ihn auseinander.

Warum der Unterschied im Alltag zählt

Er erklärt drei Dinge, über die Anwender regelmäßig stolpern.

Warum dieselbe Frage mal nachgeschlagen wird und mal nicht. In der Voreinstellung entscheidet das Modell in jeder Runde neu, ob ein Tool passt. Bei „Wie wird das Wetter?“ greift es zu, bei „Erkläre mir Hochdruckgebiete“ antwortet es aus sich heraus, und das ist auch richtig so. Wer selbst baut, kann ihm diese Wahl bei vielen Modellen abnehmen; dazu Tiefe 2.

Warum ein Ergebnis falsch sein kann, obwohl nachgeschlagen wurde. Das Tool liefert, was es findet. Findet es Falsches, formuliert ein einwandfrei arbeitendes Modell daraus eine falsche Auskunft.

Warum es Geld kostet. Jedes Ergebnis wird Teil des Gesprächs und von da an bei jeder weiteren Frage mitgeschickt. Das steht ausführlicher in Kapitel 08.

Angebunden heißt nicht benutzt

Der häufigste Irrtum bei diesem Thema: Wer ein Tool bereitstellt, glaubt, es werde nun auch verwendet. Das Modell muss es aber jedes Mal auswählen, und diese Wahl trifft es anhand dessen, was daneben steht: Name, Beschreibung und die Angaben, die das Tool verlangt.

Passt die Beschreibung schlecht oder gibt es ein zweites Tool, das allgemeiner formuliert ist und deshalb auch irgendwie passt, gewinnt oft das andere. Bemerkt wird das selten, denn eine Antwort kommt ja.

Wo die Grenze liegt

Ein Tool erweitert, was möglich ist, und ändert nichts daran, wie das Modell arbeitet. Es sagt weiterhin Text voraus. Es kann ein Tool aufrufen, das nicht passt, die Angaben falsch füllen, oder eines vergessen, das gepasst hätte. Für die Fälle, in denen es den Aufruf gar nicht absetzt und das Ergebnis trotzdem berichtet, siehe Kapitel 07.

Was ein Tool Call mitbringt, ist ein Berührungspunkt mit der Wirklichkeit. Was er nicht mitbringt, ist eine Garantie, dass er stattgefunden hat.

Ein Tool Call sieht im Gespräch aus wie eine Handlung. In der Anfrage, die tatsächlich hin und her geht, ist er eine Textstelle mit fester Form.

Was das Modell überhaupt zu sehen bekommt

Zusammen mit Ihrer Frage wird eine Liste mitgeschickt. Je Tool stehen darin drei Dinge: ein Name, eine Beschreibung in Prosa, und ein Schema für die Angaben, die es braucht. Eine Wetterauskunft heißt dann get_weather, wird beschrieben als „Get the current weather for a given location“, und verlangt ein Feld location vom Typ Text.

Die Beschreibung ist die ausführlichste Stelle, an der steht, wofür das Tool gut ist. Die Dokumentation zu den Tools (externe Seite, platform.claude.com) nennt sie neben der Frage des Anwenders als das, woran das Modell festmacht, wann es ein Tool aufruft.

Der Name und das Schema reden mit. Ein Tool namens suche gegen eines namens suche_im_internen_bestand ist schon eine halbe Entscheidung, und die Beschreibung eines einzelnen Feldes ist eine weitere. Den größten Hebel hat trotzdem die Beschreibung, und warum, steht in Tiefe 3.

Der Rundlauf

Zwei Anfragen ergeben einen Tool Call, nicht eine. Das gilt für Tools, die in Ihrem eigenen Programm laufen; für die des Anbieters steht die Ausnahme im nächsten Abschnitt.

Erste Anfrage. Frage und Tool-Liste gehen hin. Die Antwort enthält diesmal einen Block mit Tool-Name und Angaben, bei mehreren Aufrufen auch mehrere. Davor steht nach der Anleitung zum Definieren von Tools (externe Seite, platform.claude.com) oft ein kurzer Satz, in dem das Modell sagt, was es vorhat, oder dem Anwender einfach antwortet.

Der Abbruchgrund lautet tool_use, und daran erkennt Ihr Programm, dass es jetzt an der Reihe ist.

Dazwischen. Ihr Programm liest den Block, prüft ihn und führt aus.

Zweite Anfrage. Die ganze bisherige Unterhaltung geht erneut hin, jetzt ergänzt um das Ergebnis. Erst daraus entsteht der Satz, den Sie am Bildschirm lesen. Ausgeführt hat die Sache nach der Dokumentation (externe Seite, platform.claude.com) Ihr eigener Code, und er schickt das Ergebnis als Block vom Typ tool_result zurück.

Dass zweimal gefragt wird, erklärt zwei Beobachtungen aus dem Alltag. Eine Antwort mit Tool dauert länger, weil zwei vollständige Durchläufe stattfinden. Und sie kostet mehr, weil beim zweiten Mal die ganze bisherige Unterhaltung erneut mitgeht.

Wie viel mehr, hängt am Cache. Wiedererkannte Teile der Eingabe werden günstiger abgerechnet, und bei den meisten Modellen zählen sie für den Durchsatz gar nicht mit; beides steht in Kapitel 11. Am Platz, den die Unterhaltung im Fenster belegt, ändert das nichts.

Wo der Code läuft

Der Unterschied, der in der Praxis am meisten verwirrt, liegt beim Ort der Ausführung. Anthropic ordnet die Tools danach.

Websuche und Seitenabruf laufen beim Anbieter, eine Anbindung an Ihre Warenwirtschaft läuft bei Ihnen. Dazwischen steht eine dritte Gruppe: Für Shell, Texteditor und Bild­schirm­steue­rung gibt der Anbieter das Schema vor (externe Seite, platform.claude.com), und ausgeführt wird trotzdem in Ihrem Programm. Für das Modell ist das alles derselbe Vorgang. Für Ihre Rechnung und Ihren Datenschutz macht der Ort einen großen Unterschied: Was beim Anbieter ausgeführt wird, kommt auch dort vorbei.

Und der Rundlauf von oben sieht anders aus. Ein Tool beim Anbieter braucht in der Regel keine zweite Anfrage von Ihnen. Am Beispiel der Websuche beschreibt die Dokumentation (externe Seite, platform.claude.com), dass die Suche auf der Infrastruktur von Anthropic läuft und die Ergebnisse samt Fundstellen in derselben Antwort zurückkommen.

Die Dokumentation führt den Rundlauf mit den zwei Anfragen ausdrücklich für ein Tool im eigenen Programm vor. Bei der Websuche läuft die Schleife beim Anbieter, und zwei Fälle geben sie an Sie zurück. Ruft das Modell im selben Zug auch eines Ihrer Tools auf, wartet die Suche auf Ihr Ergebnis. Und die Schleife beim Anbieter hat eine Obergrenze an Durchgängen. Ist sie erreicht, kommt die Antwort mit dem Abbruchgrund pause_turn zurück. Die Beschreibung des Ablaufs (externe Seite, platform.claude.com) sagt dazu, dass die Arbeit dann nicht fertig ist: Man schickt die Unterhaltung samt der pausierten Antwort erneut, und das Modell macht dort weiter, wo es aufgehört hat.

Wer diesen Abbruchgrund nicht behandelt, hält eine halbe Antwort für die ganze.

Was die Tool-Liste kostet

Tools kosten Platz im Kontextfenster, bevor irgendetwas benutzt wird. Drei Posten kommen zusammen.

Ein Sockel, also ein Betrag, der unabhängig von Ihrer Frage anfällt. Sobald überhaupt Tools mitgeschickt werden, setzt der Anbieter eine eigene Systemanweisung davor, die dem Modell das Verfahren erklärt. Für Claude Opus 5.5 sind das nach der Dokumentation 286 Token (externe Seite, platform.claude.com). Ältere Fassungen derselben Reihe liegen teils deutlich darüber, Claude Opus 4.7 bei 675.

Die Beschreibungen selbst. Namen, Prosatexte und Schemas aller angebundenen Tools, unabhängig davon, ob eines davon zum Einsatz kommt. Zwanzig Tools mit je zehn Zeilen sind ein beachtlicher Vorbau.

Jeder Aufruf und jedes Ergebnis. Beide werden Teil der Unterhaltung und wandern von da an in jeder weiteren Runde mit.

seitlich verschiebbar

eigene Darstellung, Stand 31.07.2026

Das ist der Grund, warum die Anbieter inzwischen Verfahren anbieten, die Tools erst bei Bedarf nachladen (externe Seite, platform.claude.com), statt alle dauerhaft aufzulisten. Was ein Kontextfenster ist und warum es knapp wird, steht in Kapitel 03.

Wonach ausgewählt wird

In der Voreinstellung, in der das Modell selbst wählt (tool_choice auf auto), nennt die Dokumentation (externe Seite, platform.claude.com) zwei Bedingungen für einen Aufruf, und die zweite wird gern übersehen: Die Anfrage muss zu dem passen, was die Beschreibung des Tools verspricht, und die Antwort darf nicht schon im Kontext stehen.

Steht die Antwort schon im Gespräch, wird nicht erneut gesucht. Das ist sinnvoll und führt zu der Beobachtung, dass dieselbe Frage beim zweiten Mal ohne Nachschlagen beantwortet wird, mit einem Ergebnis von vorhin, das inzwischen veraltet sein kann.

Die Neigung, überhaupt zu Tools zu greifen, lässt sich nach der Dokumentation (externe Seite, platform.claude.com) über die Systemanweisung verschieben.

Ein Satz wie „Nutze die Tools zur Recherche, bevor du antwortest“ erhöht die Bereitschaft, ein schärferer Satz erhöht sie weiter. Beides bleibt eine Neigung.

Für Gewissheit gibt es bei vielen Modellen einen eigenen Schalter. Die Schnittstelle kennt eine Einstellung, mit der ein Tool Call verlangt wird: Das Modell muss dann ein Tool nennen und darf vorher keinen Satz schreiben. In der Dokumentation heißt das forced tool use, und es kostet ein paar Token mehr als die freie Wahl, weil die Zusatzanweisung länger ausfällt. Wo der Schalter greift, wirkt er eine Schicht unter dem Prompt. Eine Bitte im Prompt kann das Modell übergehen, diese Einstellung setzt die Schnittstelle selbst durch.

Ausgerechnet die neuesten Modelle nehmen ihn gar nicht an. Die Anleitung zum Definieren von Tools (externe Seite, platform.claude.com) sagt vorweg, dass nicht jedes Modell und nicht jede Einstellung den erzwungenen Aufruf unterstützt, und führt die Ausnahmen als Liste. Claude Opus 5.5, Claude Sonnet 5.5, Claude Fable 5.1 und Claude Mythos 5.1 beantworten den Schalter mit einer Fehlermeldung, ebenso jede Anfrage mit von Hand eingeschaltetem Extended Thinking (Stand 09.10.2026). Dort bleibt die freie Wahl. Die Form der Angaben sichert eine andere Einstellung zu, und was sie leistet, steht im nächsten Abschnitt.

Wenn Angaben fehlen

Ein Tool verlangt bestimmte Felder. Fehlt in Ihrer Frage die Angabe dazu, gibt es zwei Möglichkeiten: nachfragen oder einen plausiblen Wert einsetzen. Beides kommt vor, und welches, hängt vom Modell ab. Die Dokumentation (externe Seite, platform.claude.com) nennt dabei eine Richtung: Claude Opus erkennt deutlich eher, dass eine Angabe fehlt, und fragt danach.

Als Beispiel führt sie eine Frage nach dem Wetter ohne Ortsangabe an und zeigt einen Aufruf, in dem New York steht. Ausdrücklich klargestellt ist, dass dieses Verhalten nicht zugesichert ist, und zwar besonders bei mehrdeutigen Eingaben und schwächeren Modellen.

Ein eingesetzter Wert sieht im Aufruf genauso aus wie ein mitgeteilter. Wer fragt „Wie ist das Wetter?“ und eine Auskunft über New York bekommt, sieht der Antwort nicht an, dass der Ort geraten war.

Die naheliegende Gegenmaßnahme hilft dabei nur halb. Die Schnittstelle kennt eine Einstellung, mit der die Form eines Aufrufs zugesichert wird: Wer nach der Dokumentation (externe Seite, platform.claude.com) strict: true in die Definition eines eigenen Tools schreibt, bekommt Aufrufe, die immer genau dem Schema entsprechen.

Zugesichert ist damit, dass location ein Text ist und dass das Feld dasteht. Woher der Text kommt, steht in keinem Schema. Die Frage, ob ein Wert aus Ihrer Frage stammt oder geraten wurde, bleibt beim Programm.

Ein Standard statt vieler Anbindungen

Wie ein Modell einen Aufruf formuliert, war Ende 2024 längst geregelt; für jedes Programm gibt es das Verfahren seit Juni 2023 (externe Seite, openai.com). Ungeregelt war die andere Seite, die Anbindung an jede einzelne Datenquelle. Anthropic beschrieb das Problem bei der Vorstellung des Model Context Protocol (externe Seite, anthropic.com): Jede neue Datenquelle braucht ihre eigene Umsetzung, und deshalb lassen sich wirklich verbundene Systeme schwer in die Breite bringen.

Der Vorschlag dagegen ist ein gemeinsames Protokoll, das verstreute Einzelanbindungen ersetzt (externe Seite, anthropic.com). Ein Tool wird einmal bereitgestellt und ist danach für jedes Programm nutzbar, das den Standard spricht. Für dieses Kapitel ändert das nichts an der Mechanik: Auch über ein Protokoll bleibt es dabei, dass das Modell einen Aufruf nennt und etwas anderes ihn ausführt. Was ein solcher Server mitbringt, was er im Fenster kostet und wem man ihn erlaubt, steht in Agenten und Harness, Kapitel 02.

Dieselbe Frage stellt sich für Geräte im Labor und in der Werkstatt, und seit August 2026 gibt es auch dafür einen Vorschlag. Er steht in KI jenseits der Sprachmodelle, Kapitel 14.

Wenn der Bildschirm das Tool ist

Die weitestgehende Bauform verzichtet auf eine eigens gebaute Schnittstelle. Seit Oktober 2024 gibt es Modelle, die Rechner so bedienen wie Menschen es tun, durch das Ansehen eines Bildschirms, das Bewegen eines Zeigers, Klicken und Tippen (externe Seite, anthropic.com). Damit lässt sich auch Software anbinden, die nie für Maschinen gedacht war. Software-Roboter bedienen solche Programme schon länger, nach einem festen Skript, wie Automatisierung mit KI, Kapitel 04 beschreibt.

Der Anbieter selbst nannte das bei der Vorstellung noch experimentell (externe Seite, anthropic.com) und wies darauf hin, dass Scrollen, Ziehen und Zoomen Schwierigkeiten machen. Was ein Mensch nebenbei tut, ist hier der schwierige Teil.

Heute führt die Dokumentation die Bild­schirm­steue­rung als festes Paket aus 17 Tools, eines davon nur zum Zoomen. Auf der Schnittstelle von Anthropic braucht es keinen Beta-Schalter mehr. Ausgeführt wird es im eigenen Programm, genau wie die Wetterauskunft oben: Nach der Doku zur Bild­schirm­steue­rung (externe Seite, platform.claude.com) läuft jeder Aufruf in Ihrer Anwendung, in einer Umgebung, die Sie selbst kontrollieren.

Wer Tools anbindet, rechnet mit zwei Ausgängen: Der Aufruf klappt, oder er wirft einen Fehler. Der praktisch häufigste Ausgang ist ein dritter, und er sieht von außen aus wie der erste.

Der Aufruf, der nicht stattfindet

Ein Tool, das nicht aufgerufen wird, erzeugt eine plausible Antwort und keinen Fehler. Es gibt mehrere Wege dorthin, und sie liegen in ganz verschiedenen Schichten:

• Das Tool steht gar nicht zur Verfügung, weil eine Allowlist es aussortiert hat oder eine Einstellung nicht griff. Das Modell bekommt trotzdem eine Frage und beantwortet sie.
• Das Tool steht bereit, verliert aber die Auswahl gegen ein anderes, das allgemeiner beschrieben ist.
• Das Modell antwortet mit der Auskunft, es könne das hier nicht ausführen, und setzt den Aufruf gar nicht erst ab. Bei kleineren Modellen kommt das unregelmäßig vor, also nicht reproduzierbar.
• Das Modell formuliert den Aufruf aus und erfindet die Ausgabe gleich mit. Dieser Fall steht mit einem eigenen Vorfall in Kapitel 07.

Der gemeinsame Nenner dieser Fälle ist die Unsichtbarkeit des Fehlers: Der Vorgang läuft durch, es kommt Text heraus, und im Protokoll steht kein Ausrufezeichen. Wer nur auf Abbrüche prüft, misst an all diesen Fällen vorbei.

Was hilft, ist eine Prüfung auf der anderen Seite: Liegt die Wirkung vor. Eine geschriebene Datei, ein Rückgabewert, ein Eintrag in einer Datenbank. Die Umgebung kann das bezeugen, der Ausführende nicht.

Wo die Auswahl wirklich entschieden wird

Die naheliegende Antwort auf eine falsche Tool-Wahl ist eine Anweisung: „Für Fragen dieser Art immer dieses Tool benutzen.“ Sie steht dann in der Systemanweisung oder in einer Datei, die das Modell lesen soll.

Wirksamer ist die Beschreibung im Tool-Schema selbst. Sie ist Teil jeder Anfrage (externe Seite, platform.claude.com) und steht damit unmittelbar neben der Wahl, die getroffen wird. Eine Regel in einer Projektanweisung muss dagegen erst gefunden, dann gedeutet und dann gegen ein Tool durchgesetzt werden, dessen eigene Beschreibung direkt danebensteht. Zwei Schichten Übersetzung mehr, an jeder kann etwas verloren gehen.

Die Dokumentation gewichtet genauso. Ausführliche Beschreibungen nennt die Anleitung zum Definieren von Tools (externe Seite, platform.claude.com) den mit Abstand wichtigsten Faktor dafür, wie gut ein Tool gewählt und benutzt wird.

Praktisch heißt das: Ein Spezialwerkzeug beschreibt seinen Ort, seinen Zweck und seine Abgrenzung selbst. Ein Tool für interne Bestandsdaten sagt in seiner eigenen Beschreibung, dass dafür nicht im Netz gesucht werden soll. Die Abgrenzung gehört dorthin, wo die Wahl getroffen wird.

Der Grundbetrag wandert mit dem Modell

Sobald Tools mitgeschickt werden, stellt der Anbieter eine eigene Systemanweisung davor, die dem Modell das Verfahren erklärt. Dieser Sockel fällt an, bevor Sie ein Wort geschrieben haben, und sein Umfang steht in der Dokumentation je Modell. Die zweite Spalte gilt für den Fall, dass die Schnittstelle einen Tool Call verlangt, statt ihn dem Modell zu überlassen; die Zusatzanweisung fällt dann etwas länger aus.

Stand der Dokumentation am 09.10.2026, Angaben in Token. Für Claude Opus 5.5 führt sie keinen zweiten Wert, denn das Modell weist den erzwungenen Aufruf ab (siehe Tiefe 2). Zwischen zwei auf­ein­an­der­fol­genden Fassungen derselben Reihe liegt einmal der Faktor 2,3, und die Richtung wechselt. Wer den Verbrauch einer Anwendung über einen Modellwechsel hinweg vergleicht, vergleicht damit auch diesen Posten mit, ohne ihn im eigenen Code zu sehen.

Dazu kommen die Beschreibungen aller angebundenen Tools, und die zahlen Sie bei jeder Anfrage, auch bei denen, die kein Tool brauchen. Deshalb gibt es inzwischen Verfahren, die Tools erst bei Bedarf nachladen, statt die gesamte Liste dauerhaft mitzuführen. Wie sich das im Fenster verteilt, zeigt die Zeichnung in Tiefe 2.

Fehler multiplizieren sich

Eine Tool-Schleife über mehrere Schritte hat eine Erfolgsquote, die sich ausrechnen lässt. Bei zehn Schritten mit je 99 Prozent Zuverlässigkeit steht am Ende:

0,99 ^ 10 = 0,904

Gut 90 Prozent, aus lauter Schritten, die einzeln kaum je danebengehen. Bei 95 Prozent je Schritt sind es 60. Dahinter steckt die Kettenregel, und sie erklärt, warum Aufbauten mit vielen Schritten in der Vorführung überzeugen und im Dauerbetrieb enttäuschen.

Die Rechnung setzt dabei mehr voraus, als sie zeigt: dass jeder Schritt für das Ergebnis nötig ist, dass keiner wiederholt wird, und dass die Schritte einander unbeeinflusst lassen. Das letzte trifft in einer Agentenschleife am wenigsten zu. Ein schlecht gelesener erster Befund macht die drei folgenden Schritte gleichzeitig schlechter, und dann rechnet die Formel zu freundlich.

Zwei Folgerungen daraus, beide unbequem:

Ein kürzerer Weg schlägt bessere Glieder, aber erst ab einer Schwelle. Wie groß der Hebel ist, lässt sich ausrechnen. Vier Schritte müssen je 97,6 Prozent erreichen, um mit zehn Schritten zu 99 gleichzuziehen. Bei 97 Prozent liegen sie mit 88,5 darunter, bei 98 mit 92,2 darüber. Sechs Glieder einzusparen ist damit ungefähr anderthalb Prozentpunkte je verbleibendem Glied wert, und wer eine Kette kürzt, sollte diese Rechnung für seinen Fall aufstellen, statt sie zu erwarten.

Der Fehler muss in die Schleife zurück. Ein Tool, das scheitert, sollte das Scheitern als Ergebnis zurückgeben, statt den Vorgang abzubrechen. Dann kann das Modell einen zweiten Versuch machen, und der Fall ist im Verlauf sichtbar.

Bei einem Tool, das etwas ändert, ist dieser zweite Versuch allerdings teuer. Eine ausgebliebene Antwort heißt noch lange nicht, dass nichts passiert ist: Hinter einer Zeit­über­schrei­tung kann eine Buchung stehen, eine verschickte Mail, eine Zeile in einer Datenbank. Wer hier wiederholt, ohne vorher den Zustand abzufragen, macht die Sache zweimal.

Entscheiden und Dürfen sind zwei Schichten

Die wichtigste Bauregel dieses Kapitels ist eine Trennung. Das Modell entscheidet, was versucht wird. Was erlaubt ist, entscheidet das Programm, das den Aufruf entgegennimmt.

Beides in den Prompt zu legen, ist bequem und sichert nichts zu. Die Dokumentation sagt es an einer Stelle selbst: Wer einen Aufruf erzwingen will, statt sich auf Formulierungen zu verlassen, stellt das in der Schnittstelle ein (externe Seite, platform.claude.com), soweit das Modell den Schalter annimmt. Für das Verbieten gilt dasselbe eine Schicht tiefer, und dort gilt es für jedes Modell. Eine Allowlist, die im ausführenden Programm sitzt, wirkt unabhängig davon, was das Modell für eine gute Idee hält.

seitlich verschiebbar

eigene Darstellung, Stand 31.07.2026

Wo die Grenze dieser Trennung liegt, ist inzwischen öffentlich nachlesbar, und zwar aus der Sicht des Angegriffenen. Hugging Face wurde im Juli 2026 selbst zum Ziel und hat den Hergang danach in voller Länge veröffentlicht. Nach diesem Bericht über den Einbruch (externe Seite, huggingface.co) hat ein autonomer Agent, gesteuert von einer Kombination aus OpenAI-Modellen, einen Einbruch in die Plattform von Anfang bis Ende selbst durchgeführt.

Der Angriff kam also von außen, und er kam aus einer Messung mit abgeschalteten Schutzschichten. Der Agent lief in der Aus­wer­tungs­um­ge­bung eines anderen Unternehmens, brach von dort aus und arbeitete sich anschließend über rund 17.600 Aktionen durch eine fremde Plattform, mit erbeuteten Zugangsdaten, Kubernetes-Tokens und Cloud-Schlüsseln. Für diese Auswertung waren laut demselben Bericht (externe Seite, huggingface.co) die Sicher­heits­klas­si­fi­ka­toren, die OpenAI im Betrieb einsetzt, absichtlich abgeschaltet und die Weigerungen bei Cyberaufgaben zurückgenommen, um die rohe Fähigkeit des zugrunde liegenden Modells zu messen.

Ein alltäglicher Werkzeugagent sieht anders aus. Gemessen wurde hier, wozu ein Modell ohne die üblichen Schutzschichten fähig ist. Warum der Agent überhaupt loszog, steht in der Meldung Ein Agent bricht aus der Sandbox aus, und es ist die unheimlichere Hälfte der Geschichte.

Der Punkt, den der Bericht (externe Seite, huggingface.co) daran betont, ist die Menge statt der Raffinesse: Erst die schiere Zahl der Aktionen verändert die Aufgabe für die Verteidigung.

Der zweite Fall zeigt dieselbe Grenze eine Ebene tiefer. Ein Sicher­heits­for­scher legt Schritt für Schritt offen (externe Seite, accomplish.ai), wie ein Agent aus seiner virtuellen Maschine auf einem Mac ausbricht, und stellt fest, dass der dafür ausgenutzte Fehler der austauschbare Teil der Kette ist. Er arbeitet an einem konkurrierenden Entwurf und schreibt das in seinem Schlussabschnitt dazu. Die Schritte sind einzeln belegt, die Folgerung fällt zugunsten seiner eigenen Bauform aus, und beides gehört beim Lesen nebeneinander.

Daraus folgt eine nüchterne Einordnung: Eine enge Tool-Liste sortiert nur. Wo ein Agent fremde Eingaben verarbeitet, schützt erst die Isolierung der Umgebung, und die Tool-Liste kommt obendrauf. Wie sich diese Grenze verschiebt, sobald niemand mehr jeden einzelnen Aufruf bestätigt, steht in Agenten und Harness, Kapitel 01.

Was beim Anbieter ausgeführt wird, war beim Anbieter

Der Unterschied zwischen Tools, die im eigenen Programm laufen, und solchen, die beim Anbieter laufen, betrifft auch die Daten. Bei Websuche und Seitenabruf geht der Aufruf zwangsläufig an eine dritte Stelle, an die Suchmaschine oder an die abgerufene Seite, und zwar einschließlich dessen, was das Modell in die Angaben geschrieben hat. Wer einen Suchbegriff aus einem Kundendatensatz zusammensetzt, hat diesen Datensatz anteilig übergeben, auch wenn im eigenen Code keine Zeile danach aussieht.

Beim eigenen Tool bleibt die Ausführung im Haus, und die Angaben darin waren trotzdem schon draußen: Formuliert hat sie das Modell, und das läuft beim Anbieter. Im Haus bleibt erst beides, wenn auch das Modell dort läuft.

Nachweisen lässt sich das am Protokoll der tatsächlich abgesetzten Aufrufe. Was das Modell in ein Feld schreibt, entscheidet es selbst, und im eigenen Code steht davon nichts.