Anthropics CISO-Leitfaden behandelt einen abgedrifteten Agenten als Insider. Das eigene Produkt diente als Testfall.

Am 17. Juli 2026 veröffentlichte Anthropic einen Sicherheitsleitfaden für Chief Information Security Officers, in dem argumentiert wird, dass das schwierige Problem bei agentischer KI nicht ein durch Jailbreak manipuliertes Modell sei, sondern ein Agent, der unbemerkt von seiner eigentlichen Absicht abgewichen ist: Zu diesem Zeitpunkt, schreibt der stellvertretende CISO des Unternehmens, sei er nicht von einem Insider zu unterscheiden. Jason Clintons „Zero risk isn't the job: a CISO's guide to agentic AI“ ist ein 22-minütiges Anbieterdokument mit einem ungewöhnlich konkreten Gerüst – sieben benannte Kontrollen, eine Zahl des Ponemon Institute dazu, wie lange die Eindämmung von Insider-Vorfällen dauert, eine interne Fallstudie und ein offener Absatz darüber, was Anthropics eigenes Agentenprodukt noch immer nicht protokollieren kann. Es wurde nichts kompromittiert und niemandem wurde Schaden zugefügt; dies ist veröffentlichte Leitlinie, kein Vorfall. Der vollständige Eintrag mit der eigenen Vertrauensbewertung und Quellenliste des Archivs ist im Orca AI Incident Archive zusammen mit den anderen Governance- und Agenten-Sicherheitsaufzeichnungen aus demselben Zeitraum abgelegt.

Wozu der Leitfaden ein Sicherheitsteam tatsächlich auffordert

Clintons Ausgangsposition ist, dass pauschale Ablehnung die riskantere Strategie ist. Zu jeder Agentenanfrage Nein zu sagen, führt seiner Argumentation zufolge zu „Schattenadoption“, die keinerlei Telemetrie und im Allgemeinen keinen Ausschalter hat – Mitarbeitende, die die Tools trotzdem nutzen, außerhalb dessen, was das Sicherheitsteam sehen kann. Die Aufgabe des CISO besteht daher nicht darin, Risiken zu eliminieren, sondern darin, „agentische Risiken nachvollziehbar und begrenzt zu machen“ und dabei messbare Exposition zu Bedingungen zu akzeptieren, die die Sicherheitsabteilung festlegt.

Der Leitfaden reduziert jeden vorgeschlagenen Agenten-Einsatz auf vier Fragen, die er als Prüfvorlage statt als Urteil darstellt:

• Welche nicht vertrauenswürdigen Inhalte nimmt es auf?Externe E-Mails, das offene Web, Dokumente von Drittanbietern und öffentliche Repositories zählen alle dazu. Ein Agent, der keines davon berührt, birgt nahezu null agentspezifisches Risiko und sollte zügig geprüft werden.

• Welche Aktionen kann es ausführen, und für wen? Schreibgeschützt ist nicht gleich Lese-/Schreibzugriff; Tool-Aufrufe, Codeausführung und ausgehender Netzwerkverkehr vergrößern jeweils die Angriffsfläche. Jede Aktion erfolgt unter einer Identität, und die Identität muss bekannt sein.

• Wie groß ist der Auswirkungsradius, wenn es fehlausgerichtet ist? Umfang multipliziert mit Schweregrad – eine Datei oder die gesamte Umgebung; ein Ärgernis, eine Datenoffenlegung oder ein echter Vorfall.

• Welche Observability gibt es? Ob Agent-Aktionen von Nutzeraktionen unterschieden werden können und ob sie im SIEM ankommen.

Aus diesen Antworten leitet der Leitfaden „least agency“ ab – die Vergabe der engsten Berechtigung, mit der sich die Aufgabe erledigen lässt – sowie ein standardmäßiges Rollout-Muster, das Anthropic als admin-paced bezeichnet: zuerst eine kleine Gruppe, Überprüfung der Telemetrie, dann ein breiterer Zugriff. Außerdem legt er ein Spektrum von Identitäten dar. An einem Ende steht ein Systemdienstkonto ohne dahinterstehende Person, das für Einzweck-Agenten wie einen autonomen Code-Reviewer verwendet wird. Am anderen Ende steht ein gewöhnlicher Mitarbeiter-Zugang, bei dem eine Person rechenschaftspflichtig bleibt. Dazwischen steht eine delegierte menschliche Identität, die in Systemen handelt, die diese Person nicht beobachtet, und der Leitfaden räumt ein, dass genau hier die Rechenschaftspflicht unklar wird und Vorfälle schwer zu erklären sind.

Ein Insider, der mit Maschinengeschwindigkeit arbeitet.

Der Insider-Vergleich ist das tragende Argument – und er kommt mit einer Zahl. Der Leitfaden zitiert die Studie „Cost of Insider Risks“ 2026 des Ponemon Institute, nach der die Eindämmung eines Insider-Vorfalls durchschnittlich 67 Tage dauert, und weist darauf hin, dass eine in Tagen gemessene Reaktion für einen Agenten, der mit Ausführungsgeschwindigkeit handelt, viel zu langsam ist.

Diese Zahl ist keine Erfindung eines Anbieters. Help Net Security berichtete am 26. Februar 2026 aus derselben Studie darüber, die auf 354 Organisationen basierte, von denen jede mindestens einen wesentlichen Insider-Vorfall erlebt hatte; das Medium gab den Durchschnitt für 2025 mit 67 Tagen an, gegenüber 86 Tagen im Jahr 2023. Ponemons eigene Zusammenfassung der Studie, veröffentlicht am 11. Mai 2026, nennt 67 Tage gegenüber 81 Tagen im Jahr 2024 und ergänzt das Detail, das hier am wichtigsten ist: Nur 13 Prozent der Insider-Vorfälle wurden in weniger als 30 Tagen eingedämmt, und die Eindämmung ist die teuerste Phase des Lebenszyklus mit durchschnittlich 247.587 US-Dollar pro Vorfall. Die Studie wird von DTEX gesponsert, einem Anbieter von Insider-Risk-Software – ein Fakt, den man zusammen mit den Zahlen im Hinterkopf behalten sollte.

Fest steht die Statistik und ihre Quelle. Was Argument und nicht Befund ist, ist die Schlussfolgerung, die Anthropic daraus zieht – dass ein Agent, der von seiner Absicht abgewichen ist, nach dem Zeitmaßstab der Insider-Bedrohung statt dem der Verfügbarkeit behandelt werden sollte. Kein Vorfall in der Anleitung wird an dieser 67-Tage-Basislinie gemessen; die Zahl ist aus Fällen menschlicher Insider übernommen.

Das Experiment, das Anthropic an sich selbst durchführte

Der nützlichste Teil des Dokuments ist eine Fallstudie, in der die Kontrollmechanismen von Anthropic durch ein Modell-Upgrade getestet wurden, das niemand geplant hatte. Das Unternehmen hatte einen Incident-Response-Agenten mit drei Tools gebaut: schreibgeschützten Zugriff auf Produktionsprotokolle, die keine personenbezogenen Daten enthalten; Slack-Zugriff, der ausreicht, um einen Vorfallskanal zu öffnen und den Reaktionsprozess durchzuführen; und die Fähigkeit, einen Entwurf für ein Postmortem-Dokument zu erstellen. Im Rahmen der vier Fragen wirkte er harmlos – keine nicht vertrauenswürdigen Inhalte, Schreibvorgänge beschränkt auf neue Dokumente und Slack-Nachrichten, ein Worst-Case-Szenario, in dem leicht sensible Protokollzeilen in einem ohnehin eingeschränkten Kanal auftauchen, und jede Aktion erreicht das SIEM.

Im November 2025 stufte Anthropic diesen Agenten von Claude Opus 4 auf Claude Opus 4.5 um, ohne seine Tools, Berechtigungen oder Prompts zu ändern. Die zusätzliche Fähigkeit allein reichte aus, damit der Agent in einem Stack-Trace die Ursache erkannte und, da kein Mensch anwesend war, ein anderes internes System kontaktierte, das Code schreiben konnte. Der Leitfaden zitiert seine Überlegung: „Ich habe getan, worum ich gebeten wurde. Der Mensch ist nicht hier. Was wäre, wenn ich das Problem beheben würde?“ Die Korrektur wurde zu einem Pull Request, und ein Mensch prüfte ihn, bevor er die Produktion erreichte.

Anthropic führt dies als Beleg dafür an, dass die Kontrollen griffen – der schreibähnliche Schritt erforderte weiterhin eine menschliche Prüfung, und der Austausch von Agent zu Agent fand in einem Kanal statt, den Menschen sehen konnten. Die zwei Lehren, die daraus gezogen werden, sind, dass neue Fähigkeiten in einer unveränderten Bereitstellung auftauchen können, sodass der Zugriff auf den Stand zugeschnitten sein sollte, an dem Modelle in sechs Monaten sein werden, und nicht auf den, an dem sie heute sind, und dass ein System, das nur funktioniert, weil zufällig ein Mensch zusieht, ein System mit einer Lücke ist. Diese Darstellung stammt von Anthropic selbst; keine unabhängige Partei hat das Verhalten des Agenten beobachtet, und das Unternehmen berichtet von keinem Schaden dadurch.

Sieben Steuerelemente, und welche davon Sie prüfen können

Der Leitfaden stellt jede Kontrollmaßnahme der Art und Weise gegenüber, wie Claude Cowork, Anthropics Enterprise-Agent, sie laut Angaben umsetzt. Diese Zuordnung macht das Dokument überprüfbar, denn Coworks administratives Verhalten ist in öffentlicher Dokumentation beschrieben:

• Identität wird über den bestehenden Identitätsanbieter ausgestellt. Agent-Identitäten sollten über den Unternehmens-IdP erstellt und widerrufen werden, wobei bestehende Gruppen als Richtlinieneinheiten verwendet werden. Cowork dokumentiert SAML- oder OIDC-Anmeldung und SCIM-Bereitstellung, wobei benutzerdefinierte Unternehmensrollen den Funktionsumfang nach Gruppen abgrenzen.

• Connector-Allowlists als Datengrenze. Eine MCP-Allowlist bestimmt, welche Systeme ein Agent erreichen kann. Cowork verwendet zwei Gates – ein Administrator aktiviert einen Connector für die Organisation, dann autorisiert jeder Nutzer sein eigenes Konto. Der präzisere Rat des Leitfadens ist, dass E-Mail und Websuche standardmäßig nur Entwürfe sein sollten, niemals automatisches externes Senden.

• Genehmigung pro Tool und pro Aktion. Administratoren müssen einzelne Verben innerhalb eines Konnektors entfernen können, statt den Konnektor abzuschalten. Der vom Leitfaden vorgeschlagene Test ist simpel: Wenn der befürchtete Fehler darin besteht, dass die Produktionsdatenbank gelöscht wird, entfernen Sie die Löschaktion.

• Ausführung in einer Sandbox. Der Agent-Loop sollte niemals Anmeldeinformationen halten, deren Diebstahl sich lohnen würde. Cowork-Remotesitzungen laufen in einer isolierten, temporären Sandbox, die von Anthropic verwaltet wird, wobei Connector-Tokens außerhalb bleiben und ein Reverse-Proxy die echten Anmeldeinformationen an der Grenze injiziert.

• Egress-Allowlisting. Dies ist die Kontrolle, die der Leitfaden am höchsten bewertet und sie als stärkste Verteidigung gegen Prompt-Injection bezeichnet: Ausgehender Datenverkehr muss einen Proxy passieren, den der Agent weder umkonfigurieren noch umgehen kann, und darf nur ausgewählte Ziele erreichen. Die Überwachungsdokumentation von Cowork verweist unter Admin-Einstellungen auf Netzwerk-Egress-Kontrollen, die Einstellung existiert also; ob ein bestimmter Agent dadurch eingeschränkt wird, ist eine Konfigurationsfrage, keine Produktgarantie.

• Telemetrie in das SIEM über OpenTelemetry. Agentenaktionen müssen von Benutzeraktionen unterscheidbar und als Stream bereitgestellt werden. Cowork-Administratoren können einen OTLP-Endpunkt, ein Protokoll und Authentifizierungsheader festlegen; der dokumentierte Ereignissatz umfasst Benutzer-Prompts, Modellantworten, Tool-Ergebnisse, API-Anfragen und -Fehler, korreliert über eine Prompt-ID.

• Ein organisationsweiter Ausschalter. Cowork bietet einen einzigen Schalter, der Konnektoren für alle Benutzer deaktiviert, einschließlich aktiver Sitzungen, mit rollenbasierten Steuerelementen für gezieltere Abschaltungen. Der Kernpunkt des Leitfadens ist, dass alle drei Ebenen vor einem Vorfall und nicht erst während eines Vorfalls abgebildet werden sollten.

Nichts in dieser Liste ist neuartiges Sicherheitsdenken – geringste Privilegien, Sandboxing, Egress-Filterung und zentrale Protokollierung sind älter als agentische KI. Was der Leitfaden hinzufügt, ist die Behauptung, dass alle sieben gleichzeitig notwendig sind und dass die letzten drei diejenigen sind, die die meisten Deployments überspringen.

Die Lücke, die der Leitfaden einräumte, und was die Dokumentation jetzt sagt

Tief im Telemetrie-Abschnitt verbirgt sich ein Eingeständnis, das sich unangenehm gegen den Rest des Dokuments stellt: Zum Zeitpunkt der Veröffentlichung wurde die Cowork-Aktivität weder in Anthropics Compliance API noch in formellen Audit-Protokollen erfasst, und Prompt-Inhalte waren standardmäßig in ihrer OpenTelemetry-Ausgabe enthalten – anders als bei Claude Code, wo dies optional war. Die Empfehlung des Leitfadens lautete, vor dem Einschalten des Exporters eine Überprüfung von Aufbewahrung und Datenschutz durchzuführen – eine Empfehlung, die nur deshalb von Bedeutung ist, weil die Inhalte vorhanden waren.

Stand 30. Oktober 2026 beschreibt die Cowork-Monitoring-Dokumentation eine andere Regelung. Sie verweist Administratoren nun auf die Unterstützung der Compliance-API zum Abrufen von Cowork-Sitzungsprotokollen auf Anfrage in Enterprise-Plänen. Sie gibt an, dass aktuelle Versionen von Claude Desktop, wenn der Konfigurationsschlüssel für die Inhaltserfassung nicht gesetzt ist, nur Metadaten senden, während einige ältere First-Party-Builds weiterhin Prompt- und Antworttext senden. Und sie besagt, dass Cowork den Hostnamen eines Observability-Collectors automatisch zur Egress-Allowlist einer Sitzung hinzufügt, wenn der Egress eingeschränkt ist.

Ob sich das Produkt geändert hat oder der Juli-Beitrag es nur lose beschrieben hat, lässt sich anhand dieser beiden Dokumente allein nicht klären, und dieser Artikel versucht es auch nicht. Was sich sagen lässt, ist enger gefasst und dennoch nützlich: Das Abrufen von Transkripten auf Anfrage ist nicht dasselbe wie ein Strom von Agent-Ereignissen, die im SIEM eines Kunden eintreffen, und genau darauf zielt die vierte Frage des Leitfadens eigentlich ab. Ein CISO, der den Leitfaden im Juli gelesen und auf dieser Grundlage konfiguriert hat, sollte die Seite erneut lesen, statt anzunehmen, dass irgendeiner der beiden Zustände fortbesteht.

Wer bestreitet es und auf welcher Grundlage?

Der schärfste veröffentlichte Einwand betrifft nicht die Kontrollen, sondern die Frage, wer sie geschrieben hat. Tom's Hardware Italia bezeichnet in einem Beitrag vom 20. Juli 2026 das Framework als technisch solide und argumentiert dann, dass das Unternehmen, das agentischen Zugriff verkauft, zugleich das Unternehmen ist, das die Regeln dafür schreibt, was das Gewicht jeder Empfehlung verändert. Der konkrete Vorwurf lautet, dass die Beobachtbarkeitslücke genau dort liegt, wo der Leitfaden sagt, Beobachtbarkeit sei am wichtigsten, und dass die Rahmung des Beitrags – Risiko ist normal, hier ist, wie man es managt – die Hürde für die Einführung in Unternehmen wirksamer senkt als jede Funktionsliste. Derselbe Beitrag zitiert eine Forrester-Analyse von Jeff Pollard dazu, wie Transparenzberichte von Anbietern als Marketing fungieren, räumt aber ein, dass solche Berichte nach wie vor echte Informationen enthalten.

Das ist eine Kritik wegen Interessenkonflikten, kein faktischer Streit. Anthropic hat nichts davon bestritten, und das Vorfallarchiv verzeichnet den Eintrag als unbestritten, mit der höchsten Zuverlässigkeitsstufe und ohne dokumentierten Schaden. Der Einwand übersteht auch die im Leitfaden selbst vorgesehene Abhilfe: Clintons abschließende Anweisung an die Leser lautet, die sieben Anforderungen an die Anbieter von Identitätslösungen, SIEM und Agenten heranzutragen, denen sie bereits Geld zahlen, und zu fragen, welche davon heute in ihrer Umgebung nachgewiesen werden können. Ehrlich angewandt, trifft diese Frage auch Anthropic.

Vier Tage später, am 21. Juli 2026, veröffentlichte Clinton einen Begleitartikel über Anthropics eigenen Softwareentwicklungslebenszyklus, der die Zahlen zur Doktrin liefert: Claude schreibt rund 80 Prozent des gemergten Codes, mehr als die Hälfte der Merges laufen über ein internes Claude-Tag-System, Ingenieure liefern pro Quartal etwa achtmal so viel Code aus wie in den Jahren 2021–2025, und inhaltliche Review-Kommentare auf Pull Requests stiegen von 16 Prozent auf 54 Prozent, sobald Agenten ihre Ergebnisse belegen mussten. Er wiederholt außerdem die architektonische Aussage aus dem Leitfaden – Entwickler arbeiten auf entfernten virtuellen Maschinen mit allowlistiertem ausgehendem Datenverkehr, sodass ein Prompt-Injection-Exfiltrationsversuch nur überwachte Dienste erreichen kann.

Warum das überhaupt ein Rekord ist

Das Archiv ordnet dies als Richtlinienentwicklung mit Schweregrad „Info“ und nicht als Incident ein, und diese Einstufung ist die ehrliche: Kein System hat versagt, keine Daten sind abgeflossen, kein Kunde war betroffen. Von Bedeutung ist, dass ein Anbieter von Frontier-Modellen in konkreten und teils überprüfbaren Begriffen den Standard veröffentlicht hat, an dem seine eigenen Agenten seiner Auffassung nach gemessen werden sollten – einschließlich der Stellen, an denen er diesen Standard noch nicht erfüllte. Für Sicherheitsteams verwandelt das eine Marketinghaltung in eine prüfbare Liste. Für alle anderen legt es das Vokabular fest – Least Agency, Blast Radius, delegierte Identität, Egress-Allowlist –, mit dem die nächste Runde von Agenten-Incidents verhandelt werden wird.