Was Inference Hooks tatsächlich tut
Der Mechanismus, wie Anthropic ihn selbst beschreibt: Ein Nutzer stellt eine Anfrage auf einer „governierten“ Oberfläche – Claude im Browser, Claude Code, Cowork. Bevor das Modell zu arbeiten beginnt, schickt Anthropic den Gesprächsverlauf per signiertem HTTPS-POST an den vom Unternehmen konfigurierten Sicherheitsserver. Dieser antwortet innerhalb eines konfigurierbaren Zeitlimits (standardmäßig fünf Sekunden) mit einem einfachen JSON-Objekt: „allow“ oder „deny“ mit Begründung. Bei „deny“ sieht der Nutzer eine Ablehnungsmeldung samt Begründung, das Modell wird nie aufgerufen, der Vorgang landet im Aktivitätsprotokoll des Unternehmens.
Wichtig für die Einordnung: Der Sicherheitsserver läuft auf Infrastruktur des Unternehmens oder eines Sicherheitsanbieters, nicht bei Anthropic – die Kontrolle bleibt formal beim Kunden. Der Kontrollpunkt selbst sitzt aber auf Anthropics eigenen Servern, nach dem Verlassen des Nutzergeräts und vor dem eigentlichen Modellaufruf. Das erlaubt eine einheitliche Durchsetzung über alle Oberflächen hinweg, ohne dass auf jedem Endgerät etwas installiert werden müsste – ein reales, unbestreitbares Plus gegenüber klassischen, netzwerkbasierten DLP-Lösungen, die verschlüsselten, verteilten KI-Verkehr oft nur schwer erfassen.
Die Lücke, die genau zu unserer MCP-Analyse von letzter Woche passt
Letzte Woche haben wir an dieser Stelle beschrieben, warum Tool-Poisoning die eine wirklich neue Angriffsart bei MCP-Servern ist: Die Beschreibung eines Werkzeugs ist Fließtext, den das Sprachmodell als Anweisung liest. Klassische Sicherheits-Scanner prüfen Code, nicht diesen Text – die Schwachstelle liegt in der Bedeutung, nicht in der Syntax.
Die technische Dokumentation zu Inference Hooks beantwortet eine Frage, die in keiner der bisherigen Presseartikel gestellt wurde: Sieht die neue Kontrollstelle diese Werkzeug-Beschreibungen überhaupt? Die Antwort steht dort wörtlich und unmissverständlich: „System-Prompts und Tool-Definitionen sind niemals in dem enthalten, was gesendet wird.“ Der Sicherheitsserver sieht laut Dokumentation, was der Nutzer sieht – Transkript-Text, Werkzeugaufrufe und deren Ergebnisse, aus Anhängen extrahierten Text. Die Definition eines Werkzeugs selbst – also genau die Stelle, an der eine manipulierte Beschreibung eine versteckte Anweisung platzieren würde – gehört ausdrücklich nicht dazu.
Das bedeutet praktisch: Ein kompromittiertes MCP-Werkzeug mit einer präparierten Beschreibung – genau das Angriffsmuster, das Sicherheitsforscher als Tool-Poisoning dokumentiert haben – bleibt für Inference Hooks unsichtbar, und zwar unabhängig davon, wie sorgfältig der Sicherheitsserver konfiguriert ist. Das ist keine Kritik an der Umsetzung, sondern eine bewusste Grenze des Ansatzes: Inference Hooks prüft, was durch die Leitung fließt, nicht, was das Modell aus seinen eigenen Werkzeugdefinitionen liest. Wer die Funktion einführt, weil er nach den MCP-Meldungen der letzten Wochen ein ungutes Gefühl hat, sollte genau diesen Unterschied kennen – die Meldung wurde in Teilen der Berichterstattung als Antwort auf „Agenten-Sicherheitslücken“ im Allgemeinen dargestellt, was diese Präzisierung leicht überdeckt.
Eine zweite, feinere Lücke: nur ein einziges Ereignis, und das vor dem Denken, nicht danach
Ein zweites Detail aus der Dokumentation ist ebenso präzise wie wenig beachtet: „Heute ist das einzige Hook-Ereignis prompt … Antwortseitige Durchsetzung ist als späteres Ereignis geplant.“ Das heißt: Die Prüfung greift beim Absenden einer neuen Anfrage – nicht in dem Moment, in dem ein Werkzeug innerhalb derselben Gesprächsrunde eine Antwort liefert und das Modell direkt darauf reagiert. Frühere Werkzeugaufrufe und ihre Ergebnisse werden zwar als Teil des Gesprächsverlaufs mitgeschickt, sobald die nächste Anfrage geprüft wird – aber es gibt aktuell kein Echtzeit-Tor unmittelbar nach einer einzelnen Werkzeug-Antwort, bevor das Modell in derselben Runde darauf reagiert.
Für einen mehrstufigen Agenten-Ablauf – ruft Werkzeug A auf, verarbeitet das Ergebnis, ruft Werkzeug B auf, handelt – bedeutet das: Wenn eine kompromittierte Werkzeug-Antwort das Modell innerhalb einer einzigen Runde zu einer unerwünschten Handlung bewegt, sieht die aktuelle Beta-Version das erst rückblickend, wenn der Nutzer die nächste eigene Anfrage stellt – nicht in dem Moment, in dem es zählt. Auch das steht so in der Dokumentation, nicht in der Ankündigung selbst. Es ist keine grobe Schwäche, aber eine Nuance, die den Unterschied macht zwischen „diese Funktion schützt uns vor kompromittierten Agenten-Ketten“ und der genaueren, zutreffenden Aussage: „diese Funktion schützt uns vor problematischen Nutzeranfragen, mit eingeschränkter, nachträglicher Sicht auf das, was Werkzeuge dazwischen getan haben“.
Eine Entscheidung, die Anthropic bewusst dem Kunden überlässt
Ein drittes Detail betrifft nicht die Funktion selbst, sondern eine Weiche, die jedes einführende Unternehmen selbst stellen muss: Was passiert, wenn der eigene Sicherheitsserver nicht erreichbar ist, einen Fehler zurückgibt oder das Zeitlimit überschreitet? Laut Dokumentation entscheidet dann eine vom Unternehmen selbst konfigurierte Einstellung – entweder blockieren (fail-closed) oder ungeprüft durchlassen (fail-open). Es gibt keine Anthropic-Voreinstellung, die diese Frage für einen entscheidet.
Diese Wahl klingt technisch, ist aber eine echte Geschäftsentscheidung mit spürbaren Folgen in beide Richtungen. Fail-closed bedeutet: Fällt der Sicherheitsserver aus – etwa bei einem eigenen Infrastruktur-Wartungsfenster –, steht die komplette Claude-Nutzung im Unternehmen still, bis er wieder erreichbar ist. Fail-open bedeutet: Genau in dem Moment, in dem die eigene Sicherheitsprüfung ausfällt, laufen alle Anfragen ungeprüft durch – ausgerechnet dann, wenn ohnehin schon etwas an der eigenen Infrastruktur nicht rund läuft. Es gibt keine Antwort, die für jedes Unternehmen richtig ist; es gibt nur die Notwendigkeit, sie bewusst zu treffen, bevor der erste reale Ausfall diese Entscheidung ungeplant für einen trifft.
Was daraus praktisch folgt
Nichts an diesen drei Punkten spricht gegen die Einführung von Inference Hooks – im Gegenteil, eine einheitliche, geräteunabhängige Kontrollstelle für alle Claude-Oberflächen ist ein echter Fortschritt gegenüber dem bisherigen Flickenteppich aus clientseitigen Hooks und Netzwerk-DLP. Der Punkt ist, die Funktion für das einzusetzen, was sie laut eigener Dokumentation tatsächlich leistet, und die Erwartung nicht größer zu machen, als Anthropic sie selbst formuliert.
- Nicht als MCP-Schutz verkaufen: Wer intern kommuniziert, Inference Hooks löse die MCP-Sicherheitsfragen der letzten Wochen, sollte das korrigieren – Tool-Definitionen sind laut Dokumentation ausdrücklich ausgeschlossen. Die MCP-Absicherung aus unserer letzten Analyse (klassische Härtung der Server selbst, Werkzeug-Beschreibungen wie Code behandeln) bleibt unabhängig davon nötig.
- Fail-open oder fail-closed bewusst festlegen, nicht der Werkseinstellung überlassen: Diese Entscheidung gehört ins eigene Sicherheitskonzept, mit einer klaren Begründung, warum die eine oder andere Richtung für den jeweiligen Anwendungsfall die richtige ist.
- Vor der Einführung prüfen, über welchen Weg Claude im eigenen Haus läuft: Die Funktion ist nicht verfügbar über Amazon Bedrock oder Google Cloud, nicht für reinen API-Zugriff. Wer Claude über einen dieser Kanäle bezieht, kann Inference Hooks aktuell nicht nutzen, unabhängig vom eigenen Bedarf.
- Den stufenweisen Rollout (Schattenmodus, dann ein wachsender Prozentsatz) tatsächlich nutzen, statt direkt scharf zu schalten – Anthropics eigene Empfehlung, weil eine harte Durchsetzung ab Tag eins in der Praxis Betriebsabläufe blockiert, bevor die Policy überhaupt kalibriert ist.
Ein letzter Punkt, der über diese eine Funktion hinausweist: Inference Hooks ist exklusiv an Anthropics eigene Infrastruktur gebunden. Für ein Unternehmen, das – wie in einer früheren Analyse an dieser Stelle beschrieben – bewusst Wechselfähigkeit zwischen KI-Anbietern aufbaut, ist das ein Kostenfaktor, der in keiner Preisliste auftaucht: Eine hier aufgebaute Sicherheits-Policy wandert nicht automatisch mit, wenn man aus Kapazitäts- oder Preisgründen zu einem anderen Anbieter wechselt oder ergänzt. Das ist kein Grund, die Funktion nicht zu nutzen – aber ein Grund, die eigene Policy-Logik so zu dokumentieren, dass sie sich bei Bedarf auch auf einem anderen System nachbauen lässt, statt implizit im Konfigurations-Dashboard eines einzelnen Anbieters zu verschwinden.